6 ms·

Using Emacs as $EDITOR

109 points by signa11 3y ago

soraminazuki 3y ago
Zsh's line editor is so flexible that it renders most uses of edit-command-line unnecessary. It does more than just let you rebind keys. It also lets you create your own text editing operations called widgets. The stock widgets covers almost all the text editing operations necessary for CLI editing, which even includes things like Vim's text objects and surround bindings. But I also define my own widgets where it falls short.
- aidenn0 3y ago
  There's a long-tail of editor shortcuts I use. I find it a bit wasteful to try and re-implement them in every single program I use that takes text input. Now, if someone else has implemented it already, then I'm happy to use it, but 99% of the time they will have implemented at most the 100 most common shortcuts that they use, which is unlikely to make me happy. I should point out that there is exactly one case of someone implemented enough of vim to make me happy, and that's evil-mode. Even there I had to tweak some settings because the defaults were too different from vim (specifically the + and * registers behave completely wrong by default).
  - soraminazuki 3y ago
    But this is the shell we're talking about, one of the primary interface for development work, so I think the effort is worth it. By relying heavily on edit-command-line, you have to choose between coping with suboptimal keybindings and opening a text editor every time you want to run a command. Also, zsh's vi bindings are surprisingly good. Obviously, it won't be useful as a full-fledged text editor. But it's more than good enough for command line editing. It even has visual mode and registers, which you rarely see implemented in an interpreter. It's true that it requires some configuration though. At least around 20 lines. Zsh's vi mode inherits vi's quirks that are normally disabled in Vim, including the weird backspace behavior in insert mode. Those have to be overridden individually. Text objects and surround bindings need to be explicitly bound too.
- cmrdporcupine 3y ago
  I mean, pure emacs nerds just use eshell or similar. Then the keybindings match 100% and things like "more" get turned into "open this in a buffer" etc. Though you give up full bash compatibility. but there's "shell" if you want bash (or zsh for that matter) inside emacs itself, without the fancy stuff eshell gives you. I've never fully made this transition, but have at times played with it, when I've been feeling extra-emacs-excited. https://www.masteringemacs.org/article/running-shells-in-emacs-overview https://www.masteringemacs.org/article/running-shells-in-ema...
  - soraminazuki 3y ago
    Eshell is neat, and I especially like the TRAMP integration. But I've yet to see anyone completely replace their terminal with it though. There are some usability problems like company mode hanging Emacs on every key input when used with Eshell on remote directories. Also, Emacs in general can't replace tabbed terminals because there are so many blocking operations that make it unresponsive for a while.
    - cmrdporcupine 3y ago
      Yeah, makes sense. And the blocking unresponsive thing, I guess I'm just flabbergasted we're still here after all these years. I know every few months there's a new "I'm rewriting emacs/something-like-emacs" and it's, yeah, a nogo. But I'd actually just really like it if someone really really tried and addressed some of the architecture things :-(
dingosity 3y ago
This is fine and all, but in the old days we used to have a "simple" editor bound to $EDITOR and a more advanced editor bound to $VISUAL. But hey, it's YOUR system, so who am I to tell you what to do. Just a reminder that you might find people using $VISUAL instead of $EDITOR. I think common practice for a bazillion years has been setting BOTH $VISUAL and $EDITOR to the full path of your favorite screen editor since hardly anyone needs to worry about editing something on a feature-poor terminal. And since we're all talking about our favorite uses of $VISUAL and/or $EDITOR, this is mine: tcv() { if [ "$#" -ge 1 ]; then touch $@ chmod 755 $@ ${VISUAL:-`which emacs` --color=never} $@ fi } I use this when I want to write a shell script that's instantaneously executable. I'm much too busy to issue the chmod command after editing the file for the first time.
notnmeyer 3y ago
emacs: where even the simplest of things is complicated enough that you wrote a blog post about it
- dmvdoug 3y ago
  That thereupon spawns 47 comments: 45 are from other users of emacs and provide 45 different ways of doing the same thing; 1 is from a vim user; and 1 is a comment about how meta the emacs community is.
  - aodonnell2536 3y ago
    This is so meta
kruhft 3y ago
Title should be "Using Emacs as $EDITOR" (all caps).
- kruhft 3y ago
  I prefer to use something more lightweight as $EDITOR, such as 'mg'. Almost all the same keybindings, unfortunately no syntax highlighting, but very fast startup.
  - reddit_clone 3y ago
    Thats what I was doing until now. Just today, from this thread, I learned about 'emacsclient -t'. This was exactly what I didn't know I needed. It opens a frame in the terminal (very quickly..) still have everything that my running GUI emacs has. Perfect.
lavventura 3y ago
I am using Emacs since 10 years, hence I feel like it is now impossible for me to switch back to any other editor.
rurban 3y ago
This is my emacsclient starter, which accepts error lines, and jumps to them. https://github.com/rurban/home-bin/blob/master/myedit https://github.com/rurban/home-bin/blob/master/myedit
eptcyka 3y ago
Why not pass an extra argument to emacs and then check for that in the config? Pardon my vimgnorance.
- gumby 3y ago
  > Pardon my vimgnorance. Why are you short-circuiting the opportunity to start a vim/emacs flamewar? The authorities should revoke your ability to use either editor. And perhaps block you from using rust and c++ as well.
  - wredue 3y ago
    Helix helix helix helix segfault helix helix helix panic index out of bounds helix segfualt
    - gumby 3y ago
      ha ha when you get into this mode you don't know how to exit!
- dbalatero 3y ago
  Will emacs exit with error if you pass random arguments it doesn't understand?
  - eptcyka 3y ago
    No. And plugins/elisp has access to yet-unprocessed arguments.
  - kreetx 3y ago
    With `emacs --eval '(setq some-var "some arg")'` one could inject any lisp variable to emacs and then react to that.
andylynch 3y ago
I’m curious about whether the writer considered using emacsclient - it’s well suited for this application but I don’t see mention of it.
- uxp8u61q 3y ago
  That's definitely the way. When I used to use Emacs, it was always running, and my $EDITOR was set to emacsclient. I had two monitors, one fully dedicated to Emacs, the other to the rest.
  - ataylor284_ 3y ago
    Yeah, it's a seamless experience to run a program in shell-mode that invokes $EDITOR and it just pops into a new buffer. Edit, hit C-x #, and you're back at the shell.
    - earthscienceman 3y ago
      Wait, I'm confused, because you might have found a solution to something that's bothered me for a long time. I use emacsclient -t as $EDITOR and editor is invoked at a normal emulator, it opens a new buffer in the terminal. Great. But if I'm using vterm inside emacs anything that invokes editor then tries to open a buffer inside vterm and I'm now in a weird recursive state that locks up. Having some lisp that checks if I'm in vterm when editor is invoked and instead opens it in my current client session would be great. I searched for this at some point but gave up.
      - chaorace 3y ago
        Have you considered overriding the Emacs process EDITOR variable via setenv? i.e.: (setenv "EDITOR" "/usr/bin/emacsclient -c") If you do that, it should cause any child processes (e.g.: vterm) to inherit the replaced EDITOR variable and properly open new editor frames instead of trying to do a terminal takeover.
        3y ago
deleted 3y ago
[deleted]
the_mitsuhiko 3y ago
Plenty of tools do not support arguments in `$EDITOR`. Might in some cases be better to make a small shell script wrapper.
craftkiller 3y ago
Personally I set my $EDITOR to a "plainmacs" script that passes its minimal config to emacs as an --eval instead of requiring a separate --init-directory: https://code.fizz.buzz/talexander/machine_setup/src/branch/main/ansible/roles/emacs/files/plainmacs https://code.fizz.buzz/talexander/machine_setup/src/branch/m...
mickeyp 3y ago
There are many interesting use cases for `emacsclient' if you use it. Here's a quick shell script that turns your Emacs into the CLI tool `fzf'. Instead of fzf, you can use Emacs's advanced completion tools to do the filtering, and then return the selected matches to the shell. Around 20 lines of bash or so, plus a smattering of elisp: https://www.masteringemacs.org/article/fuzzy-finding-emacs-instead-of-fzf https://www.masteringemacs.org/article/fuzzy-finding-emacs-i...
rbanffy 3y ago
I wonder how practical (or not) would be to set it as your shell. Not that much, as it is rather limited on the terminal.
- Y_Y 3y ago
  This is definitely bait.
  - rbanffy 3y ago
    I thought it’d be polarising, but when you think Lisp Machines essentially had Emacs and a REPL for their shell, it’s not completely absurd.
gumby 3y ago
I don't know why the author doesn't simply open a shell buffer in emacs, but that's their business. Piece of fun trivia: EMACS used to have a mode for use on a printing terminal. It worked, as long as you had an idea of what your file looked like, same as any other non-visual editor (like ed before a display mode was grafted onto it to form vi). Of course this was as crazy as using vi on a printing terminal, since EMACS started out as an easier way to use TECO after a visual mode had been added to that. I guess the printing mode was worth it for EMACS users who never learned TECO. More usefully it had a "slow terminal" mode. Printing terminals were slow, but many people connected to computers at 300 baud or even slower! So in slow terminal mode you could use the full display power of EMACS but it was very selective about how it updated your display. Back then most terminals had very limited cursor control, and you couldn't always change an arbitrary character. Still, avoiding a full screen repaint at 110 baud was a win. I doubt either of these modes survived the relatively recent (1980s) ports of emacs (as it is now known) to C/Lisp. But a special line for single-line editing through an emacsclient could be a win in this case.
- teddyh 3y ago
  From the Emacs manual: Searching incrementally on slow terminals, such as displays connected to remote machines over slow connection, could be annoying due to the need to redraw large portions of the display as the search proceeds. Emacs provides a special display mode for slow terminals, whereby search pops up a separate small window and displays the text surrounding the match in that window. — <https://www.gnu.org/software/emacs/manual/html_node/emacs/Search-Customizations.html#index-search-display-on-slow-terminals https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...>
  - gumby 3y ago
    Nice! That a bit more advanced: old school EMACS used the line below the mode line because some old terminals supported update only there and not always elsewhere.
- m463 3y ago
  personally I don't use shell buffer because it doesn't do command line recall like I expect. In a normal terminal control-r <characters> recalls the last command with those keys, and control-p/n will go back/forward in the history. with the shell buffer I move upwards in the buffer to recall a command. (is there a way to configure this differently?) EDIT: ok it seems like meta-r and meta-p/n do the same thing - kind of. hmmm, but meta-r doesn't seem to recall from the shell history? It is either a different history or truncated.

109 points by signa11 3y ago

Zsh's line editor is so flexible that it renders most uses of edit-command-line unnecessary. It does more than just let you rebind keys. It also lets you create your own text editing operations called widgets. The stock widgets covers almost all the text editing operations necessary for CLI editing, which even includes things like Vim's text objects and surround bindings. But I also define my own widgets where it falls short.

aidenn0 3y ago
There's a long-tail of editor shortcuts I use. I find it a bit wasteful to try and re-implement them in every single program I use that takes text input. Now, if someone else has implemented it already, then I'm happy to use it, but 99% of the time they will have implemented at most the 100 most common shortcuts that they use, which is unlikely to make me happy. I should point out that there is exactly one case of someone implemented enough of vim to make me happy, and that's evil-mode. Even there I had to tweak some settings because the defaults were too different from vim (specifically the + and * registers behave completely wrong by default).
- soraminazuki 3y ago
  But this is the shell we're talking about, one of the primary interface for development work, so I think the effort is worth it. By relying heavily on edit-command-line, you have to choose between coping with suboptimal keybindings and opening a text editor every time you want to run a command. Also, zsh's vi bindings are surprisingly good. Obviously, it won't be useful as a full-fledged text editor. But it's more than good enough for command line editing. It even has visual mode and registers, which you rarely see implemented in an interpreter. It's true that it requires some configuration though. At least around 20 lines. Zsh's vi mode inherits vi's quirks that are normally disabled in Vim, including the weird backspace behavior in insert mode. Those have to be overridden individually. Text objects and surround bindings need to be explicitly bound too.
cmrdporcupine 3y ago
I mean, pure emacs nerds just use eshell or similar. Then the keybindings match 100% and things like "more" get turned into "open this in a buffer" etc. Though you give up full bash compatibility. but there's "shell" if you want bash (or zsh for that matter) inside emacs itself, without the fancy stuff eshell gives you. I've never fully made this transition, but have at times played with it, when I've been feeling extra-emacs-excited. https://www.masteringemacs.org/article/running-shells-in-emacs-overview https://www.masteringemacs.org/article/running-shells-in-ema...
- soraminazuki 3y ago
  Eshell is neat, and I especially like the TRAMP integration. But I've yet to see anyone completely replace their terminal with it though. There are some usability problems like company mode hanging Emacs on every key input when used with Eshell on remote directories. Also, Emacs in general can't replace tabbed terminals because there are so many blocking operations that make it unresponsive for a while.
  - cmrdporcupine 3y ago
    Yeah, makes sense. And the blocking unresponsive thing, I guess I'm just flabbergasted we're still here after all these years. I know every few months there's a new "I'm rewriting emacs/something-like-emacs" and it's, yeah, a nogo. But I'd actually just really like it if someone really really tried and addressed some of the architecture things :-(

dingosity 3y ago

This is fine and all, but in the old days we used to have a "simple" editor bound to $EDITOR and a more advanced editor bound to $VISUAL. But hey, it's YOUR system, so who am I to tell you what to do. Just a reminder that you might find people using $VISUAL instead of $EDITOR. I think common practice for a bazillion years has been setting BOTH $VISUAL and $EDITOR to the full path of your favorite screen editor since hardly anyone needs to worry about editing something on a feature-poor terminal. And since we're all talking about our favorite uses of $VISUAL and/or $EDITOR, this is mine: tcv() { if [ "$#" -ge 1 ]; then touch $@ chmod 755 $@ ${VISUAL:-`which emacs` --color=never} $@ fi } I use this when I want to write a shell script that's instantaneously executable. I'm much too busy to issue the chmod command after editing the file for the first time.

notnmeyer 3y ago

emacs: where even the simplest of things is complicated enough that you wrote a blog post about it

dmvdoug 3y ago
That thereupon spawns 47 comments: 45 are from other users of emacs and provide 45 different ways of doing the same thing; 1 is from a vim user; and 1 is a comment about how meta the emacs community is.
- aodonnell2536 3y ago
  This is so meta

kruhft 3y ago

Title should be "Using Emacs as $EDITOR" (all caps).

kruhft 3y ago
I prefer to use something more lightweight as $EDITOR, such as 'mg'. Almost all the same keybindings, unfortunately no syntax highlighting, but very fast startup.
- reddit_clone 3y ago
  Thats what I was doing until now. Just today, from this thread, I learned about 'emacsclient -t'. This was exactly what I didn't know I needed. It opens a frame in the terminal (very quickly..) still have everything that my running GUI emacs has. Perfect.

lavventura 3y ago

I am using Emacs since 10 years, hence I feel like it is now impossible for me to switch back to any other editor.

rurban 3y ago

This is my emacsclient starter, which accepts error lines, and jumps to them. https://github.com/rurban/home-bin/blob/master/myedit https://github.com/rurban/home-bin/blob/master/myedit

eptcyka 3y ago

Why not pass an extra argument to emacs and then check for that in the config? Pardon my vimgnorance.

gumby 3y ago
> Pardon my vimgnorance. Why are you short-circuiting the opportunity to start a vim/emacs flamewar? The authorities should revoke your ability to use either editor. And perhaps block you from using rust and c++ as well.
- wredue 3y ago
  Helix helix helix helix segfault helix helix helix panic index out of bounds helix segfualt
  - gumby 3y ago
    ha ha when you get into this mode you don't know how to exit!
dbalatero 3y ago
Will emacs exit with error if you pass random arguments it doesn't understand?
- eptcyka 3y ago
  No. And plugins/elisp has access to yet-unprocessed arguments.
- kreetx 3y ago
  With `emacs --eval '(setq some-var "some arg")'` one could inject any lisp variable to emacs and then react to that.

andylynch 3y ago

I’m curious about whether the writer considered using emacsclient - it’s well suited for this application but I don’t see mention of it.

uxp8u61q 3y ago
That's definitely the way. When I used to use Emacs, it was always running, and my $EDITOR was set to emacsclient. I had two monitors, one fully dedicated to Emacs, the other to the rest.
- ataylor284_ 3y ago
  Yeah, it's a seamless experience to run a program in shell-mode that invokes $EDITOR and it just pops into a new buffer. Edit, hit C-x #, and you're back at the shell.
  - earthscienceman 3y ago
    Wait, I'm confused, because you might have found a solution to something that's bothered me for a long time. I use emacsclient -t as $EDITOR and editor is invoked at a normal emulator, it opens a new buffer in the terminal. Great. But if I'm using vterm inside emacs anything that invokes editor then tries to open a buffer inside vterm and I'm now in a weird recursive state that locks up. Having some lisp that checks if I'm in vterm when editor is invoked and instead opens it in my current client session would be great. I searched for this at some point but gave up.
    - chaorace 3y ago
      Have you considered overriding the Emacs process EDITOR variable via setenv? i.e.: (setenv "EDITOR" "/usr/bin/emacsclient -c") If you do that, it should cause any child processes (e.g.: vterm) to inherit the replaced EDITOR variable and properly open new editor frames instead of trying to do a terminal takeover.
      - 3y ago

deleted 3y ago

[deleted]

the_mitsuhiko 3y ago

Plenty of tools do not support arguments in `$EDITOR`. Might in some cases be better to make a small shell script wrapper.

craftkiller 3y ago

Personally I set my $EDITOR to a "plainmacs" script that passes its minimal config to emacs as an --eval instead of requiring a separate --init-directory: https://code.fizz.buzz/talexander/machine_setup/src/branch/main/ansible/roles/emacs/files/plainmacs https://code.fizz.buzz/talexander/machine_setup/src/branch/m...

mickeyp 3y ago

There are many interesting use cases for `emacsclient' if you use it. Here's a quick shell script that turns your Emacs into the CLI tool `fzf'. Instead of fzf, you can use Emacs's advanced completion tools to do the filtering, and then return the selected matches to the shell. Around 20 lines of bash or so, plus a smattering of elisp: https://www.masteringemacs.org/article/fuzzy-finding-emacs-instead-of-fzf https://www.masteringemacs.org/article/fuzzy-finding-emacs-i...

rbanffy 3y ago

I wonder how practical (or not) would be to set it as your shell. Not that much, as it is rather limited on the terminal.

Y_Y 3y ago
This is definitely bait.
- rbanffy 3y ago
  I thought it’d be polarising, but when you think Lisp Machines essentially had Emacs and a REPL for their shell, it’s not completely absurd.

gumby 3y ago

I don't know why the author doesn't simply open a shell buffer in emacs, but that's their business. Piece of fun trivia: EMACS used to have a mode for use on a printing terminal. It worked, as long as you had an idea of what your file looked like, same as any other non-visual editor (like ed before a display mode was grafted onto it to form vi). Of course this was as crazy as using vi on a printing terminal, since EMACS started out as an easier way to use TECO after a visual mode had been added to that. I guess the printing mode was worth it for EMACS users who never learned TECO. More usefully it had a "slow terminal" mode. Printing terminals were slow, but many people connected to computers at 300 baud or even slower! So in slow terminal mode you could use the full display power of EMACS but it was very selective about how it updated your display. Back then most terminals had very limited cursor control, and you couldn't always change an arbitrary character. Still, avoiding a full screen repaint at 110 baud was a win. I doubt either of these modes survived the relatively recent (1980s) ports of emacs (as it is now known) to C/Lisp. But a special line for single-line editing through an emacsclient could be a win in this case.

teddyh 3y ago
From the Emacs manual: Searching incrementally on slow terminals, such as displays connected to remote machines over slow connection, could be annoying due to the need to redraw large portions of the display as the search proceeds. Emacs provides a special display mode for slow terminals, whereby search pops up a separate small window and displays the text surrounding the match in that window. — <https://www.gnu.org/software/emacs/manual/html_node/emacs/Search-Customizations.html#index-search-display-on-slow-terminals https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...>
- gumby 3y ago
  Nice! That a bit more advanced: old school EMACS used the line below the mode line because some old terminals supported update only there and not always elsewhere.
m463 3y ago
personally I don't use shell buffer because it doesn't do command line recall like I expect. In a normal terminal control-r <characters> recalls the last command with those keys, and control-p/n will go back/forward in the history. with the shell buffer I move upwards in the buffer to recall a command. (is there a way to configure this differently?) EDIT: ok it seems like meta-r and meta-p/n do the same thing - kind of. hmmm, but meta-r doesn't seem to recall from the shell history? It is either a different history or truncated.