`less` open editor without immediately triggering a redraw in the terminal
Clash Royale CLAN TAG#URR8PPP
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?
less terminal-emulator
|
show 2 more comments
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?
less terminal-emulator
if I'm understanding you correctly, doesVISUAL=clear; vim -u NONE
do it?
– Jeff Schaller
Dec 22 '18 at 2: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 useVISUAL=clear; vim
.
– Gregory Nisbet
Dec 22 '18 at 2:49
less -X
orLESS=X
appears to do the trick.
– Gregory Nisbet
Dec 22 '18 at 2:57
“I'm trying to switch to a workflow…” makes me wonder why‽. (Same withvim -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 4:57
1
less -X
appears to work, but I don't really understand why. What exactly happens whenless
transfers control to an editor (other than passing a+43
-style argument to indicate the line number) is still a bit mysterious.
– Gregory Nisbet
Dec 22 '18 at 5:46
|
show 2 more comments
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?
less terminal-emulator
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?
less terminal-emulator
less terminal-emulator
edited Dec 22 '18 at 2:50
asked Dec 22 '18 at 2:40
Gregory Nisbet
1,3621019
1,3621019
if I'm understanding you correctly, doesVISUAL=clear; vim -u NONE
do it?
– Jeff Schaller
Dec 22 '18 at 2: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 useVISUAL=clear; vim
.
– Gregory Nisbet
Dec 22 '18 at 2:49
less -X
orLESS=X
appears to do the trick.
– Gregory Nisbet
Dec 22 '18 at 2:57
“I'm trying to switch to a workflow…” makes me wonder why‽. (Same withvim -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 4:57
1
less -X
appears to work, but I don't really understand why. What exactly happens whenless
transfers control to an editor (other than passing a+43
-style argument to indicate the line number) is still a bit mysterious.
– Gregory Nisbet
Dec 22 '18 at 5:46
|
show 2 more comments
if I'm understanding you correctly, doesVISUAL=clear; vim -u NONE
do it?
– Jeff Schaller
Dec 22 '18 at 2: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 useVISUAL=clear; vim
.
– Gregory Nisbet
Dec 22 '18 at 2:49
less -X
orLESS=X
appears to do the trick.
– Gregory Nisbet
Dec 22 '18 at 2:57
“I'm trying to switch to a workflow…” makes me wonder why‽. (Same withvim -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 4:57
1
less -X
appears to work, but I don't really understand why. What exactly happens whenless
transfers control to an editor (other than passing a+43
-style argument to indicate the line number) is still a bit mysterious.
– Gregory Nisbet
Dec 22 '18 at 5:46
if I'm understanding you correctly, does
VISUAL=clear; vim -u NONE
do it?– Jeff Schaller
Dec 22 '18 at 2:43
if I'm understanding you correctly, does
VISUAL=clear; vim -u NONE
do it?– Jeff Schaller
Dec 22 '18 at 2: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
.– Gregory Nisbet
Dec 22 '18 at 2:49
@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
.– Gregory Nisbet
Dec 22 '18 at 2:49
less -X
or LESS=X
appears to do the trick.– Gregory Nisbet
Dec 22 '18 at 2:57
less -X
or LESS=X
appears to do the trick.– Gregory Nisbet
Dec 22 '18 at 2: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 4: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 4:57
1
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.– Gregory Nisbet
Dec 22 '18 at 5:46
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.– Gregory Nisbet
Dec 22 '18 at 5:46
|
show 2 more comments
1 Answer
1
active
oldest
votes
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?
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f490431%2fless-open-editor-without-immediately-triggering-a-redraw-in-the-terminal%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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?
add a comment |
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?
add a comment |
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?
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?
edited Dec 22 '18 at 11:46
answered Dec 22 '18 at 11:40
derobert
72.1k8152210
72.1k8152210
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f490431%2fless-open-editor-without-immediately-triggering-a-redraw-in-the-terminal%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
if I'm understanding you correctly, does
VISUAL=clear; vim -u NONE
do it?– Jeff Schaller
Dec 22 '18 at 2: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 useVISUAL=clear; vim
.– Gregory Nisbet
Dec 22 '18 at 2:49
less -X
orLESS=X
appears to do the trick.– Gregory Nisbet
Dec 22 '18 at 2: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 4:57
1
less -X
appears to work, but I don't really understand why. What exactly happens whenless
transfers control to an editor (other than passing a+43
-style argument to indicate the line number) is still a bit mysterious.– Gregory Nisbet
Dec 22 '18 at 5:46