In my experience, for the sake of mental organization and not sending the
wrong command to the wrong place, there's a case to be made for
"namespacing" all activity around a certain task/environment in a singular
shell, which makes job handling with fore- and backgrounding relevant. For
example, I'll be iterating on a script targeting a new deployment
environment that requires certain env vars and a history of related
commands, then running it to see if it works, and reflexively I'm more
likely to open & edit the script, then ctrl+z the editor and run the script
than to open the editor in a separate window in my experience. That said, I
certainly have sometimes thought "you know, you could just edit the script
in another window."
I did only just learn about ":stop" with this message, though. For me, the
surprising thing is implementing in vim what users can do by hitting ctrl+z
(and which I do daily in vim with ctrl+z). Even before getting to the
window system, the shell's already got this covered by giving you the
ability to background the application: why add lines of code to your
application to do it again? But perhaps there is a scripting utility to
having it within vim itself.
Cheers,
Marshall
On Sat, Jul 19, 2025 at 7:02 AM Douglas McIlroy <
douglas.mcilroy(a)dartmouth.edu> wrote:
I opened them
all in vim instances running in the background at login
time,
and then I read email until they were all loaded.
I then put the process
with the file I needed into the foreground, examined it, and returned to
the shell with :stop (which all command line editors should have) when I
was done. Worked like a charm.
A curious mix of present and past tenses. Haven't window systems made
foreground/background distinctions irrelevant to most applications,
including editors? To my mind :stop is none of an editor's business.
Doug