Using Emacs as $EDITOR

https://magnus.therning.org/2023-09-30-using-emacs-as-$editor.html

by signa11 • 3 years ago

109 75 3 years ago

magnus.therning.org

eptcyka2• 3 years ago

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

dbalatero• 3 years ago

Will emacs exit with error if you pass random arguments it doesn't understand?

eptcyka2• 3 years ago

No. And plugins/elisp has access to yet-unprocessed arguments.

kreetx• 3 years ago

With `emacs --eval '(setq some-var "some arg")'` one could inject any lisp variable to emacs and then react to that.

gumby8• 3 years 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• 3 years ago

Helix helix helix helix segfault helix helix helix panic index out of bounds helix segfualt

andylynch• 3 years 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• 3 years 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.

wiktor-k• 3 years ago

Yep, likewise. I'm using emacsclient as $EDITOR too and it works well.

ataylor284_• 3 years 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.

cmrdporcupine4• 3 years ago

I used emacsclient for many years but these days, TBH emacs with the right knobs twiddled starts up at usually an entirely reasonable speed.

But definitely out of the box with a stock emacs install it seems too interested in doing a bunch of stuff that gets in the way.

My EDITOR has been just regular "emacs" for years now.

mbork_pl3• 3 years ago

Speed is not the only thing `emacsclient` addresses. When your $EDITOR is `emacsclient`, the newly spawned frame will share state (kill ring, buffer list etc.) with your Emacs server. This might be helpful e.g. when you (like me) are a heavy user of `dabbrev-expand`, and also with numerous other little things.

oefrha• 3 years ago

Depends on what you mean by entirely reasonable.

I’m by no means a package maniac, and I lazyload with use-package almost entirely, but a cold start still takes a second or two. To me, a choice between a second or two and instantly is a no brainer.

globular-toast2• 3 years ago

I like to use `emacsclient -t` as my $EDITOR (actually I have this in a small wrapper script in ~/bin/editor) so it runs a terminal-based frame rather than opening a new GUI frame. Also, setting alternate editor helps which will just run emacs if an emacs server isn't already running.

I run emacs as a daemon, but it doesn't have to be. You can also run `(server-mode)` from any emacs process. A nice snippet for the init.el is: `(or (server-running-p) (server-mode))` which works whether you run the daemon or not.

gray_-_wolf• 3 years ago

`(require 'server) (or (server-running-p) (server-mode))` :)

Scarbutt2• 3 years ago

What's the difference between daemon and server-mode?

gglitch• 3 years ago

emacsclient is addressed in another post: https://magnus.therning.org/2023-10-01-how-i-use-emacs.html

pama• 3 years ago

Of course it is their right, however I don’t understand their argument in this text. They can start Emacs in daemon mode and issue emacsclient -c to have their main graphical session. I not sure I see the added complexity.. if they need multiple different setups that’s also fine. I wonder if perhaps the perceived complexity comes because the author has not experienced the simplicity of Emacs working in combined terminal/shell/graphical modes through the invocation of emacsclient. There is almost no drawback in being able to share buffers if ever needed, and then they are not needed they are out of the way.

karmajunkie2• 3 years ago

yeah, this is what i use, along with a specific instance of the emacs server session to avoid cluttering up my actual editor. i think the invocation is something like `emacsclient -A “cli” -nw `

bruh22• 3 years ago

Oh that's a great idea, this is the way. I don't use emacsclient because it has weird interaction with Doom's workspaces, but your way might solve this problem. Thanks!

the_mitsuhiko• 3 years ago

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

craftkiller• 3 years 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/m...

mickeyp• 3 years 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-i...

rbanffy2• 3 years 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• 3 years ago

This is definitely bait.

rbanffy2• 3 years 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.

gumby8• 3 years 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• 3 years 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/Se...>

gumby8• 3 years 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.

m4632• 3 years 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.

earthscienceman4• 3 years ago

FYI, I use vterm with a few custom keys so that it operates exactly as if it were just a standard terminal emulator.

gumby8• 3 years ago

You can use m-p/n as you mention, same as, say, in regular bash, or search. Or c-c c-p, c-c c-o etc.

But TBH I mostly just use the ordinary ! syntax (e.g. `!!` or `!bla:*` or !200 etc) because it’s even faster and works fine even when no editing is available at all.

So if I used find to search for an executable it’s just so effortless to type ./`!!|head -1` rather than searching up, selecting and copying a region, going back to the end, editing it, blah blah. Or even worse, reaching for the mouse.

soraminazuki3• 3 years 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• 3 years 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).

soraminazuki3• 3 years 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.

cmrdporcupine4• 3 years 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-ema...

soraminazuki3• 3 years 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.

dingosity• 3 years 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• 3 years ago

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

dmvdoug• 3 years 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• 3 years ago

This is so meta

kruhft2• 3 years ago

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

kruhft2• 3 years 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• 3 years 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• 3 years 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• 3 years ago

This is my emacsclient starter, which accepts error lines, and jumps to them.

https://github.com/rurban/home-bin/blob/master/myedit

Using Emacs as $EDITOR

Related Stories