[TUHS] Re: xvi

[TUHS] Re: xvi

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

I was involved in some work about five years ago where I had to keep a
small number of files (about 5) open all the time for examination as
needed. Each was 100-500 GB.

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.

On Fri, Jul 18, 2025, 7:46 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Fri, Jul 18, 2025 at 06:57:03PM -0400, Jeff Johnson wrote:
> > Actually, Xvi is now maintained at https://codeberg.org/martinwguy/xvi.
> >
> > I'll bow out of the editor discussion now, since I think we're pretty
> > far from the original topic.
>
> I can pull it back to something potentially useful.  As I mentioned, years
> and years ago, on small memory machines, I used to vi $BIG_ASS_LOGFILE
> and because editors tend to malloc each line, the vi session got really
> slow (started swapping) when the file was bigger than roughly 1/2 of mem.
> My changes were to teach the string library, and whatever else operated
> on a line of the file, to treat \n the same way you would treat \0.
> Then you change the code that read in the file to just mmap() it.
>
> I don't think I went so far as to make changes to the file work, not
> sure, it may have just worked but I was looking at log files, I don't
> think I modified them.
>
> I'm pretty sure the answer is no, the laptop I'm typing on has 64GB and
> I suspect everyone else is the same.  But can anyone imagine a use case
> where having a vi that could read really large files (and quickly, no
> parsing/mallocing each line) would be useful?
>
> I'm pretty done with programming but if someone said "here is an important
> use case where that would help" I'd go find those changes and see if I can
> port them forward.
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

[-- Attachment #2: Type: text/html, Size: 2702 bytes --]

[TUHS] Re: xvi

[Marshall Conover]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

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@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
>

[-- Attachment #2: Type: text/html, Size: 2378 bytes --]

[TUHS] Re: xvi

[Bakul Shah via TUHS]

On Jul 19, 2025, at 3:55 AM, Douglas McIlroy <douglas.mcilroy@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.

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 :-)

[TUHS] Re: foreground/background vs. Windowing

[Warner Losh]

On Sat, Jul 19, 2025 at 10:29 AM Harald Arnesen via TUHS <tuhs@tuhs.org> wrote:
>
> Clem Cole [2025-07-19 16:46:18]:
>
> > On Sat, Jul 19, 2025 at 6:55 AM Douglas McIlroy
> > <douglas.mcilroy@dartmouth.edu <mailto:douglas.mcilroy@dartmouth.edu>>
> > wrote:
> >
> >     Haven't window systems madeforeground/background distinctions
> >     irrelevant to most applications,including editors?
> >
> > An interesting observation.  It's true that I have not used
> > ^Zor :stop,since I've had a window system.  I keep lots of terminal
> > windows open and switch back and forth.  One of the "features" of MacVIM
> > is that when I type: vito the command prompt, it's forked in its own
> > (separate) window from the terminal/shell window, so the desire/need of
> > something like ^Z for the editor that I used to need to do in my
> > 4.XBSD days are unnecessary.
>
> I still like to use ^Z to suspend a running program, even when I use
> X11. That's really the reason I haven't changed my login shell to rc,
> because it lacks job control.

Yea, I use both. It all depends on what I'm doing. But my brain is tainted
by emacs, so that could be the answer :) There have been no good gui
adaptations of emacs that make me want to use.

Warner

[TUHS] Not really Emacs wars (was: foreground/background vs. Windowing)

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

[Somewhat off-topic for TUHS; please follow up at COFF]

On Saturday, 19 July 2025 at 17:37:34 -0600, Warner Losh wrote:
>
> Also, there are no GUI emacs versions I like..

You have me curious.  How many do you know?  And what don't you like
about them, when you clearly use Emacs?

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: [COFF] Re: Re: Not really Emacs wars (was: foreground/background vs. Windowing)

[Theodore Ts'o]

On Mon, Jul 21, 2025 at 02:03:38PM +1000, Greg 'groggy' Lehey wrote:
> > With multiple terminals, I can have multiple editors with different
> > contexts. With the GUI, it all gets dumped together.
> 
> Not in my experience (GNU Emacs 29.4 (build 1,
> amd64-portbld-freebsd13.3, GTK+ Version 3.24.43, cairo version
> 1.17.4).  I have four displays on my server 0, and also 4 instances of
> Emacs: one on :0.1 and three on :0.2.

Yeah, it doesn't work that way for me using GNU emacs on Debian
either.

Many decades ago I did force the behaviour that you describe; it
involved setting EDITOR to emacsclient, and then running
(server-start) in my ~/.emacs.el.  This was a feature back when I was
running emacs on BSD 4.3 with a Vaxstation II/RC with 2 MiB of memory
(Digital had put epoxy into the backplane so you couldn't add more
memory to their memory-starved inexpensive model), but now that I buy
my own desktops with 64 GiB of memory, I really don't care that emacs
is "eight megabytes and constantly swapping" (well, not swapping; I
don't configure swap any more :-) and emacsclient is more annoying
than it's worth.

     	     		    	 	       - Ted