2

I'm trying to switch to a workflow of mainly using less when I just want to read code and then using v to switch into an editor when I want to edit the document. This is GNU less on OS X, but I think it generalizes to other systems.

If I set VISUAL to vim -u NONE so that vim doesn't read any of its initialization files, or use another editor that starts instantly like nano or joe or ne, then there's no perceptible pause between pressing v and having the file appear in the editor.

For instance, this works fine:

$ previous-command > foo.txt
$ VISUAL='vim -u NONE' less foo.txt

view file in less, scroll to interesting line and press v, file is instantly visible inside vim.

Just to illustrate the point, here's what happens if we set VISUAL to sleep 1; vim .

$ another-previous-command > foo.txt
$ VISUAL='sleep 1; vim -u NONE' less foo.txt

we're now viewing the file, then we press v to edit it.

The shell session is now visible again for one second and so we see:

$ another-previous-command > foo.txt
$ VISUAL='sleep 1; vim -u NONE' less foo.txt

After the second has passed we see the contents of foo.txt inside vim.

Just using vim by itself, without additional command line arguments, reads files and does some initialization work. This takes a fraction of a second, but long enough that the underlying shell session is visible, as in the case with sleep 1; <VIM COMMAND>.

Is there a way to transfer control from less to vim in such a way that the underlying shell session is not visible, even partially?

Greg Nisbet
  • 3,076
  • if I'm understanding you correctly, does VISUAL=clear; vim -u NONE do it? – Jeff Schaller Dec 22 '18 at 02:43
  • @JeffSchaller, I do that (VISUAL=clear; vim -u NONE), then the original terminal session is not visible at all, even briefly. It is still visible if I use VISUAL=clear; vim . – Greg Nisbet Dec 22 '18 at 02:49
  • less -X or LESS=X appears to do the trick. – Greg Nisbet Dec 22 '18 at 02:57
  • “I'm trying to switch to a workflow…” makes me wonder why‽. (Same with vim -u NONE, although that's getting closer to "what the—"). I'm wondering if maybe vim is taking forever to launch for you, and you're trying to get rid of the waiting. If so... are you aware of the various file browsing inside vim? And also of vimserver? – derobert Dec 22 '18 at 04:57
  • @derobert Basically, this is something I tried on a whim and the split-second where the terminal behind less was visible was something I didn't expect. vim takes a tiny fraction of a second to launch, whether I suppress the custom stuff or not. I guess the main thing I'm after is a better understanding of mitigation strategies when console applications "flicker" and I'm using this as an example because it's reproducible. – Greg Nisbet Dec 22 '18 at 05:31
  • @GregoryNisbet ah, OK. You seem to have found a solution, is your question answered? If so, please go ahead and post that as an answer (answering your own question is fine). If not answered, what more are you looking for? – derobert Dec 22 '18 at 05:38
  • 1
    less -X appears to work, but I don't really understand why. What exactly happens when less transfers control to an editor (other than passing a +43-style argument to indicate the line number) is still a bit mysterious. – Greg Nisbet Dec 22 '18 at 05:46

1 Answers1

4

Less's -X option turns off initializing & deinitializing the terminal, so that's what's causing the flash. Very likely less is using the alternate screen feature of your terminal emulator. If that's Mac OS X's Terminal.app, you can apparently manually switch back and forth between the alternate screen. (XTerm lets you manually switch too).

Now, what is the alternate screen and why does less use it? Historical reasons, really. Terminal emulators pretend to be terminals — actual hardware display devices that were used from the early days of computing (but now quite rare). A program talks to a terminal emulator almost entirely by outputting characters; certain special characters are designated control characters and do things like move the cursor, clear the screen, change the colors, etc. Unlike a modern framebuffer, it's hard or impossible for a program to find out what the terminal is currently displaying. (Indeed, if it were possible, it'd have to be done by sending a control sequence which would have the terminal send the answer back as if the user had typed it; there is really no other way for data to go from the terminal to the program).

So if you want to restore the screen (for example, see the commands you typed) after displaying something else, you need the terminal to do it. Most terminal emulators let you save at least one screen by switching to the alternate screen. You'll notice when you (for example) run echo hello | less that after you close less, you're back at your bash screen, unchanged. That's because less switched to the alternate screen and displayed "hello" there; then when you quit it, it switched back. If you run echo hello | less -X the behavior will be much different (it also skips the clear-screen part of init, so you wind up with your file starting after your prompt — try control-L to force a clear screen & redraw). And when you quit less, your shell history won't be displayed anymore.

Random side note, less -FX is a useful combination.

Anyway, so the flash you're seeing is this: when less starts up the editor, it first has to return the terminal to a "normal" state — part of that is switching out of the alternate screen. That's what you're seeing. (Once vim starts up, it of course switches right back to the alternate screen — but less has no way of knowing that.)

See also: How to configure screen-restore in a terminal?

derobert
  • 109,670