19 Jul
2025
19 Jul
'25
3:24 p.m.
On Jul 19, 2025, at 3:55 AM, Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu> wrote:
If an editor is stopped, it needs to at least pay heed to the SIGCONT
so as to restore its terminal state. It need not have a command to
stop itself. But I think you are asking why not just use a different
window. I do a lot of work logged in via ssh and have remote screen(1)
sessions that persist for a long time. Remote X window apps that open
on my laptop disconnect if I put the lid down on my macbookpro. Most
of my work is in remote text windows and I end up using ^Z a lot.
Ideally I want all my computers (& VMs) to collaborate and present a
single virtual computer (VC) and all the 2D windows be truly /windows/
on that VC, where I can interact with the same programs from any window.
Apple sort of does a bit of this with their apps (e.g. you can pickup
a call on your laptop, watch, etc. Access photos, music, browser windows
etc.) but ideally one should not have to rely on a third party shared
storage such as iCloud for one's own data. plan9 style cpu commands don't
quite meet that ideal (not to mention plan9 itself never took off).
But this is quite a tangent so I will stop now :-)
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.