916 Days of Emacs(sqrtminusone.xyz)
sqrtminusone.xyz
916 Days of Emacs
https://sqrtminusone.xyz/posts/2023-04-13-emacs/
308 comments
I've been a hardcore vi user pretty much my entire life, but I decided to force myself to spend a year using emacs a while back just to see what all the fuss was about. When the year was over and I "allowed" myself to return to vi, it was like a huge weight lifted off my shoulders... to this day I still don't see what the hype was about. On the plus side, though, I memorized the emacs cursor movement commands, which are (for some reason) the default cursor movement commands in most command line environments like the Postgres CLI.
I had a similar experience, but came to the opposite conclusion. I walked away replacing vim with emacs as my daily driver. Elisp is far more extensible than vimscript and evil-mode is pretty much at 1-1 feature parity with the real vim. I don't care much for the emacs movement keybindings except for the readline movement commands.
> to this day I still don't see what the hype was about.
Most of vim is written in C with some interfaces exposed for scripting. Emacs is mostly written in elisp with some C code where necessary. The latter lends itself better to 'hackability' imo
For my own machines, I build emacs and import my saved init.el
On other machines, there is usually a standard vi/vim install that I can use if I am ssh'd in somewhere where I don't have my personalized copy of emacs. If I remember, I'll try to put these five lines[1] in the .vimrc for some saner defaults
[1] https://news.ycombinator.com/item?id=25410390
> to this day I still don't see what the hype was about.
Most of vim is written in C with some interfaces exposed for scripting. Emacs is mostly written in elisp with some C code where necessary. The latter lends itself better to 'hackability' imo
For my own machines, I build emacs and import my saved init.el
On other machines, there is usually a standard vi/vim install that I can use if I am ssh'd in somewhere where I don't have my personalized copy of emacs. If I remember, I'll try to put these five lines[1] in the .vimrc for some saner defaults
[1] https://news.ycombinator.com/item?id=25410390
Why don't you SSH _from_ Emacs?
If you are editing a remote file there's usually no need to SSH and then invoke an editor.
https://willschenk.com/howto/2020/tramp_tricks/
If you are editing a remote file there's usually no need to SSH and then invoke an editor.
https://willschenk.com/howto/2020/tramp_tricks/
I used to, and I probably would if I had to work with remote files more often. But in my experience I found it faster to just build emacs on the remote server and run it as a daemon there, since all the machines I was working on remotely had /home on an NFS mount. TRAMP took just a little too long to load remote directories for my liking.
But in case I am plopped in front of an unknown terminal/have to do something on someone else's machine ... at least I can rely on using the default vim to do basic editing.
But in case I am plopped in front of an unknown terminal/have to do something on someone else's machine ... at least I can rely on using the default vim to do basic editing.
Does that mean you have a nice setup for running emacs as a server on a remote machine and connecting via a local client? I've tried this a couple of times but it seems to be prohibitively awkward and I'm stuck with the idiosyncrasies of Tramp or even just saying in a vterm. I'd be very grateful if you (or anyone else) can explain how to do this.
I just run emacs on the remote server (inside tmux), emacs works great on the terminal, in fact, I don't use GUI emacs. code, orgmode, magit are just text.
Yeah, this is how I do it. If it's a reasonably modern remote image you even get color highlighting. And in a way, it lets me segregate, "on this host, I'm working on this project, on this host I'm on this project, all the state/context is there when I re-activate my tmux ready to see what's up.
If I'm writing a lot of code or doing a refactor needing more thought, I'll do it locally, to be sure.
If I'm writing a lot of code or doing a refactor needing more thought, I'll do it locally, to be sure.
I even started baking emacs into docker images we use for running debugging tools in kubernetes environments. Can quickly edit and run little scripts to do admin and operations and debugging tasks.
You can also use docker-tramp to enter locally running containers and do quick edits without worrying about installing an editor. It can be suprisingly useful.
Remember when there was an embedded web browser in emacs? https://www.emacswiki.org/emacs?action=browse;oldid=EmacsWeb...
Is there a preferred way to do the equivalent of xref_find_definitions when using tramp?
[deleted]
Vimscript is a pain but these days you can use Neovim which supports Lua as a replacement. I’d recommend checking out what Neovim has to offer. ThePrimeagen has a great video on setting up Neovim as an IDE from scratch.
https://m.youtube.com/watch?v=w7i4amO_zaE
https://m.youtube.com/watch?v=w7i4amO_zaE
I mean it's a matter of preference, I personally find vimscript a lot more readable for vim configuration. Maybe not for more advanced stuff, I don't know, but how is the following:
vim.keymap.set("n", "K", vim.lsp.buf.hover, { buffer = buffnr, desc = "vim.lsp.buf.hover" })
vim.api.nvim_buf_set_keymap(bufnr, "n", "K", "<cmd>lua vim.lsp.buf.hover()<CR>")
better than
nmap K :lua vim.lsp.buf.hover()<CR>
It's like the javafication of vim configuration.
vim.keymap.set("n", "K", vim.lsp.buf.hover, { buffer = buffnr, desc = "vim.lsp.buf.hover" })
vim.api.nvim_buf_set_keymap(bufnr, "n", "K", "<cmd>lua vim.lsp.buf.hover()<CR>")
better than
nmap K :lua vim.lsp.buf.hover()<CR>
It's like the javafication of vim configuration.
While I wholeheartedly agree, you don't have to sprinkle Lua everywhere, you can use both. As a matter of fact, I do[0]. And when I want to enable a setting on the fly in the editor, I still use the vimscript version. But Lua is way nicer to work with the moment you do something non trivial. For example, I've never been able to make sense out of vimscript string interpolation.
0: https://github.com/RMPR/dotfiles/blob/master/.config/nvim/in...
0: https://github.com/RMPR/dotfiles/blob/master/.config/nvim/in...
Thank you. Been a vi (not vim, vi) user for decades for editing files in /etc.
Tried using vim, neovim, Emacs, mg, etc a month ago and quickly went back to pycharm which hogs resources on my ancient computer.
Have been looking for a "how-to" on various editors. This video seems to be it for neovim.
Offtopic: I'll pay you in blood for configs for fvwm
Tried using vim, neovim, Emacs, mg, etc a month ago and quickly went back to pycharm which hogs resources on my ancient computer.
Have been looking for a "how-to" on various editors. This video seems to be it for neovim.
Offtopic: I'll pay you in blood for configs for fvwm
Neovim supports Lua and Fennel (a Lisp atop Lua) https://fennel-lang.org/ https://github.com/Olical/aniseed
When I was at the university and started programming on UNIX, the professor said we should try both emacs and vi and see which we like better, and provided links to some tutorials.
I tried them both and liked vi. Emacs seemed slower. In my undergraduate wisdom, I deemed emacs to be "stupid" and went on with my life using vi.
After I had been programming professionally for about ten years, I decided that my harsh judgement as an undergraduate was often incorrect. (I had also deemed Voltaire, Spanish, sociology, microeconomics and many other things as "stupid", and came to understand as an adult that they weren't.) So, I decided to give emacs another chance.
My conclusion was this: vi is better for touch typists. Your fingers are almost always on the home row. Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist. It's much harder than hitting shift. Vi makes you hit escape, but that only happens when you switch modes and it's not that hard to hit.
I noticed that lots of skilled and professional engineers never learned to touch type. That discovery itself was odd to me: why would a professional programmer not want to invest the time to learn to type properly: typing fast boosts your productivity significantly. But they do. And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.
I tried them both and liked vi. Emacs seemed slower. In my undergraduate wisdom, I deemed emacs to be "stupid" and went on with my life using vi.
After I had been programming professionally for about ten years, I decided that my harsh judgement as an undergraduate was often incorrect. (I had also deemed Voltaire, Spanish, sociology, microeconomics and many other things as "stupid", and came to understand as an adult that they weren't.) So, I decided to give emacs another chance.
My conclusion was this: vi is better for touch typists. Your fingers are almost always on the home row. Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist. It's much harder than hitting shift. Vi makes you hit escape, but that only happens when you switch modes and it's not that hard to hit.
I noticed that lots of skilled and professional engineers never learned to touch type. That discovery itself was odd to me: why would a professional programmer not want to invest the time to learn to type properly: typing fast boosts your productivity significantly. But they do. And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.
> why would a professional programmer not want to invest the time to learn to type properly: typing fast boosts your productivity significantly.
I have not found typing speed to correlate well with productivity. I spend quite a lot of time thinking while coding.
I have not found typing speed to correlate well with productivity. I spend quite a lot of time thinking while coding.
This is true, but from what I've seen, not being able to touch type may also be a serious impediment to written communication. Maybe not so much for email, but very much so for anything ~real time like slack/chat.
I once worked (mostly remotely) with a guy who I'm pretty sure couldn't touch type. He wrote pretty dense code and used very abbreviated class/variable/method names. But the real clue came from communicating with him via slack. It often felt like talking to someone much less intelligent than I knew him to be. His messages were so terse that I was constantly having to make a lot of guesses about what he was trying to say. Needless to say, it was not a great working relationship.
I once worked (mostly remotely) with a guy who I'm pretty sure couldn't touch type. He wrote pretty dense code and used very abbreviated class/variable/method names. But the real clue came from communicating with him via slack. It often felt like talking to someone much less intelligent than I knew him to be. His messages were so terse that I was constantly having to make a lot of guesses about what he was trying to say. Needless to say, it was not a great working relationship.
wait a second, is this why i typically send 10 messages per 1 coherent thought? i learned how to type too well?
It certainly helps to reduce latency of being able to test out your thoughts, which can be very useful for staying in a good flow state.
Of course it doesn’t help at all if you have a long build or deploy process before you can see the outcome of your changes.
Of course it doesn’t help at all if you have a long build or deploy process before you can see the outcome of your changes.
> In my undergraduate wisdom, I deemed emacs to be "stupid" and went on with my life using vi.
That’s what we do when we’re younger. Judge things on the wrong basis. Or come up with weird theories on how people who prefer different things do so because they’re deficient in some way—
> Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist.
wait what…
> And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.
You see that the there are Alt and Control keys on both sides of the (American[1]) keyboard. Right? Touch typing is no harder with Control and Alt than it is with Shift.
> And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.
One Year of Experience Ten Times Over: The Comment.
[1] The keyboard (ish) that these silly programs were kind of made for. The “European” keyboard has AltGr on the right side.
That’s what we do when we’re younger. Judge things on the wrong basis. Or come up with weird theories on how people who prefer different things do so because they’re deficient in some way—
> Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist.
wait what…
> And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.
You see that the there are Alt and Control keys on both sides of the (American[1]) keyboard. Right? Touch typing is no harder with Control and Alt than it is with Shift.
> And my conclusion was that emacs was for them, because hitting the control/alt key isn't as much of a penalty when you're a hunt-and-peck typist.
One Year of Experience Ten Times Over: The Comment.
[1] The keyboard (ish) that these silly programs were kind of made for. The “European” keyboard has AltGr on the right side.
"My conclusion was this: vi is better for touch typists. Your fingers are almost on the home row. Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist. It's much harder than hitting shift. Vi makes you hit escape, but that only happens when you switch modes and it's not that hard to hit."
In emacs you can type exactly the same as in vi/vim if you use something like evil, doom, or spacemacs.
In emacs you can type exactly the same as in vi/vim if you use something like evil, doom, or spacemacs.
Many people who use Emacs a lot make CapsLock an additional Ctrl. Using your left-hand little finger makes it trivial to use C-p, C-n, C-f, C-b as cursor keys.
Lots of vim users do that too, in fact the ADM-3A terminal vi was written on had ctrl where caps-lock is now and escape where tab is.
ADM-3A also has
- the : key to the right of the 0 on the number row, no Shift needed.
- the Enter key to the right of the P.
I've made both changes to my keyboard layout and, not surprisingly, it's quite convenient.
Downside is, you'll have to move the original keys somewhere else. But since I already intended to totally reshuffle all the non-alpha keys for RSI reasons, it wasn't an issue for me.
- the : key to the right of the 0 on the number row, no Shift needed.
- the Enter key to the right of the P.
I've made both changes to my keyboard layout and, not surprisingly, it's quite convenient.
Downside is, you'll have to move the original keys somewhere else. But since I already intended to totally reshuffle all the non-alpha keys for RSI reasons, it wasn't an issue for me.
I'm in the process of rearranging my keyboard due to occasional mild pain. Mind if I ask what layout you ended up with for the other keys? Any experience with the more esoteric arrangements like triggering modifiers when holding down the home row keys?
Here is my current keyd configuration (on US QWERTY hardware): https://dpaste.org/aGp3o/slim
(I'm not entirely happy with it, though.)
The one thing I wanted the most was to avoid any long presses. Everything that requires holding a modifier, even if I do it touch-typing style, with the opposite hand, is unpleasant (to me). So, besides moving most of the punctuation characters to lowercase positions, I also switched to sticky modifiers. (keyd might have some flaws wrt sticky modifiers, and they... get stuck. Not when I want them to be. I might try to go back to XKB.)
Regarding the home-row modifiers, I've only tried moving Control there. I always ended up triggering it by mistake when typing, because when you are typing fast, there is an almost unavoidable overlap in certain sequences, you press the next key before fully releasing the previous key. Some people advice practicing, other software provides various options with timeouts, it's a rabbit hole of work-arounds. So I settled with sticky modifiers.
The one thing I wanted the most was to avoid any long presses. Everything that requires holding a modifier, even if I do it touch-typing style, with the opposite hand, is unpleasant (to me). So, besides moving most of the punctuation characters to lowercase positions, I also switched to sticky modifiers. (keyd might have some flaws wrt sticky modifiers, and they... get stuck. Not when I want them to be. I might try to go back to XKB.)
Regarding the home-row modifiers, I've only tried moving Control there. I always ended up triggering it by mistake when typing, because when you are typing fast, there is an almost unavoidable overlap in certain sequences, you press the next key before fully releasing the previous key. Some people advice practicing, other software provides various options with timeouts, it's a rabbit hole of work-arounds. So I settled with sticky modifiers.
I never thought of making tab be alt/escape. Hmm.
I've always just used the palm of my hand. You can work a keyboard with more surfaces than just your fingertips.
> I noticed that lots of skilled and professional engineers never learned to touch type. That discovery itself was odd to me: why would a professional programmer not want to invest the time to learn to type properly: typing fast boosts your productivity significantly. But they do.
This is a false dilemma. Plenty of us type quickly without hunting and pecking, or looking at the keyboard, without home-row touch typing. This comment was typed as such.
There isn't anything "proper" about home row style touch typing, it is merely one of multiple ways to type fast.
This is a false dilemma. Plenty of us type quickly without hunting and pecking, or looking at the keyboard, without home-row touch typing. This comment was typed as such.
There isn't anything "proper" about home row style touch typing, it is merely one of multiple ways to type fast.
I’m a touch typist and don’t find that argument valid either for vi or emacs. And I’ve used emacs for over 30 years now and still do use vi occasionally on production servers where I’m not going to load my full emacs config just for sys admin work.
That's weird, I'm a Dvorak touch typist and I find the Alt keys to be much easier to reach than Escape. To reach Escape I basically have to leave the home row, while to reach one of the Alts I simply have to bend my ring finger.
After years of vim, I started using emacs with an ergonomic keyboard on my tower. Then I tried emacs with my mbp, and it was so much worse (ergonomically) than vim. I think emacs without ergonomic keyboard is just really painful.
Not saying your choice is wrong for you, but I always map caps lock to control and that makes Emacs far more ergonomic.
Just a comment on the last point and purely opinion. Touch typing is fast and worth it if your typing like a word document. I've tried to get into touch typing, and it can be worth it, but for everyday programming, it doesn't really help me type faster. I type a few lines, stop and think about the code I've written. Programming also makes you hit a series of weird symbols most people don't. Think turbofish operator. The, probably, milliseconds touch typing saves me between writing a few lines to then contemplate just isn't a big enough speed benefit.
With that being said, I consider how I type a combination. I sort of touch type, but Im not completely glued to it. I don't worry if my hands cross as times. However, at the end of the day, if people enjoy touch typing and feel it helps them, they should! No one should swear it off just because I don't feel its that much of a performance boast for me personally.
With that being said, I consider how I type a combination. I sort of touch type, but Im not completely glued to it. I don't worry if my hands cross as times. However, at the end of the day, if people enjoy touch typing and feel it helps them, they should! No one should swear it off just because I don't feel its that much of a performance boast for me personally.
That's an interesting guess but I wouldn't necessarily agree.
I've been a touch typist as long as I can remember and have been an avid emacs user for the last 15 years. I used vim for about 2 years before switching. I do have my caps lock bound to CTRL and have ALT+(jkl;) as movement keys in emacs so that might be a sign that there is some truth to what you say.
I would guess the reason that I used vim instead of emacs at the start was the learning curve - I simply couldn't bother to learn all the emacs combinations and program in elisp whereas in vim, I could be somewhat productive without much to learn.
Once I learned emacs, it was hard to go back to anything else but I still use vim on other machines when emacs isn't available.
I've been a touch typist as long as I can remember and have been an avid emacs user for the last 15 years. I used vim for about 2 years before switching. I do have my caps lock bound to CTRL and have ALT+(jkl;) as movement keys in emacs so that might be a sign that there is some truth to what you say.
I would guess the reason that I used vim instead of emacs at the start was the learning curve - I simply couldn't bother to learn all the emacs combinations and program in elisp whereas in vim, I could be somewhat productive without much to learn.
Once I learned emacs, it was hard to go back to anything else but I still use vim on other machines when emacs isn't available.
> My conclusion was this: vi is better for touch typists. Your fingers are almost on the home row. Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist. It's much harder than hitting shift. Vi makes you hit escape, but that only happens when you switch modes and it's not that hard to hit.
I had been playing rogue and nethack for a bit when I started programming. The keys hjkl for doing movement was a natural transition to a vt-100 terminal for writing code in vi.
I had also been coding in LPMuds for a bit and the ed command set was firmly engrained in my mind. With vi being both "move using rogue keys" and "do the fancy stuff with the ed commands" there wasn't even a second thought spent on considering emacs.
I had been playing rogue and nethack for a bit when I started programming. The keys hjkl for doing movement was a natural transition to a vt-100 terminal for writing code in vi.
I had also been coding in LPMuds for a bit and the ed command set was firmly engrained in my mind. With vi being both "move using rogue keys" and "do the fancy stuff with the ed commands" there wasn't even a second thought spent on considering emacs.
Unless you use a keyboard like a Dactyl Manuform that provides your thumbs with better access to such modifier keys https://github.com/abstracthat/dactyl-manuform
> Emacs wants you to hit the meta/alt key a lot, which is difficult for a touch typist.
hmm.... I wonder if this is the reason Mac OS uses the option key for things like 'kill word' (ctrl+backspace on other OSes or ctrl+w in vi). I have a hard time typing quickly using option/command instead of ctrl.
I also prefer vi-like keybindings.
hmm.... I wonder if this is the reason Mac OS uses the option key for things like 'kill word' (ctrl+backspace on other OSes or ctrl+w in vi). I have a hard time typing quickly using option/command instead of ctrl.
I also prefer vi-like keybindings.
Original Macs didn’t have a control key.
in the same way vi users swap escape with capslock, some emacs users swap left alt with capslock
I simply rebound the keys.
What all the hype is about depends on how you use emacs, what you add to it and how you configure it.
I used vi and vim for 25 years before switching to emacs, and I spent a ton of time making it very vim like.
Now my emacs can do way more than vim ever did. Things like:
- browse the web through emacs - read my email through emacs - use org-mode to take notes in outline format, with hyperlinks, tables, executable source blocks, etc - use magit, which is a great interface to git
All of these things and more are tightly integrated, so moving text/data between them and editing that data is seamless.
It's all programmed and configured in elisp, and is part of a gigantic elisp ecosystem. Though I much prefer Scheme to elisp, I like elisp far more than vimscript, python, lua, or pretty much any other non-lisp language.
Emacs has some shortcomings (like handling long lines and large files, and certain types of regex handling that vim can do better), and while I do occasionally still fire up vim, I've felt no yearning to go back to it permanently.
For me emacs does everything vim did and far, far more.
I used vi and vim for 25 years before switching to emacs, and I spent a ton of time making it very vim like.
Now my emacs can do way more than vim ever did. Things like:
- browse the web through emacs - read my email through emacs - use org-mode to take notes in outline format, with hyperlinks, tables, executable source blocks, etc - use magit, which is a great interface to git
All of these things and more are tightly integrated, so moving text/data between them and editing that data is seamless.
It's all programmed and configured in elisp, and is part of a gigantic elisp ecosystem. Though I much prefer Scheme to elisp, I like elisp far more than vimscript, python, lua, or pretty much any other non-lisp language.
Emacs has some shortcomings (like handling long lines and large files, and certain types of regex handling that vim can do better), and while I do occasionally still fire up vim, I've felt no yearning to go back to it permanently.
For me emacs does everything vim did and far, far more.
magit and org-mode are the two items that made me try emacs a few times now. Never been able to make it stick though.
> and certain types of regex handling that vim can do better
Hi, emacs user here, can you elaborate please.
Hi, emacs user here, can you elaborate please.
See the \zs and \ze patterns in vim.
I've asked for them to be implemented in evil, but have been told it's not possible because evil just uses emacs' regex engine, which can't do this.
I've asked for them to be implemented in evil, but have been told it's not possible because evil just uses emacs' regex engine, which can't do this.
I think these are lookahead's in some parlance, Emacs doesn't support them. On the rare occasions I need something like that I just use capture brackets. Suppose I want to delete a contiguous string of 'a' but only if it's followed by the letter 'b', then
Good luck vimming!
a+\(b\) → \1
aaaab
aa
b
aa <-- unchanged cos no trailing b
Good luck vimming!
A need I've had on multiple occasions is to, for example, search for the next occurance of "abcdef" but have my cursor land on the "d".
In vim that's a simple abc\zsdef
It also highlights just the "def", which is nice.
To highlight just the "de", you could use abc\zsde\zef
Yes, you could probably use some lisp magic to do the same in emacs, but it's not nearly as easy or convenient.
In vim that's a simple abc\zsdef
It also highlights just the "def", which is nice.
To highlight just the "de", you could use abc\zsde\zef
Yes, you could probably use some lisp magic to do the same in emacs, but it's not nearly as easy or convenient.
I guess in the next eight hours somebody will post you a snippet of elisp which will do what you want. Emacs people are very accommodating. Let's see anyway
Emacs is an operating system, not an editor; I'm really not sure why Stallman constantly promoted the "emacs vs. vi" meme.
You might as well try to switch from Notepad to Linux. It's just a type error, and you'll have a bad time.
You might as well try to switch from Notepad to Linux. It's just a type error, and you'll have a bad time.
> Emacs is an operating system, not an editor
what does it take for this tired and false meme to die?
what does it take for this tired and false meme to die?
Why do you think it's false?
Emacs is an interactive lisp environment with at text-oriented interface. Text editing is simply another lisp program that manipulates the interface to work well for this specific task.
Emacs also has a built in email client, RSS reader, IRC client, calculator, file browser, web browser, markup language, regex DSL, Vim emulator, terminal emulator, custom elisp based shell, interactive REPL that works for several programming languages, and probably at least 200 more things that I don't even realize exist yet.
I think this makes it much more than just a text editor for sure. I don't know what you want to call it but operating system doesn't seem too far off the mark even if it's a little hyperbolic.
Emacs is an interactive lisp environment with at text-oriented interface. Text editing is simply another lisp program that manipulates the interface to work well for this specific task.
Emacs also has a built in email client, RSS reader, IRC client, calculator, file browser, web browser, markup language, regex DSL, Vim emulator, terminal emulator, custom elisp based shell, interactive REPL that works for several programming languages, and probably at least 200 more things that I don't even realize exist yet.
I think this makes it much more than just a text editor for sure. I don't know what you want to call it but operating system doesn't seem too far off the mark even if it's a little hyperbolic.
> Emacs also has a built in email client, RSS reader, IRC client, calculator, file browser, web browser, markup language, regex DSL, Vim emulator, terminal emulator, custom elisp based shell, interactive REPL that works for several programming languages, and probably at least 200 more things that I don't even realize exist yet.
Chrome and Firefox also have all this stuff, but I don't see people trying to conflate a web browser with an OS. See the difference between ChromeOS[0] and Chrome[1].
[0]: https://en.m.wikipedia.org/wiki/ChromeOS
[1]: https://en.m.wikipedia.org/wiki/Google_Chrome
Chrome and Firefox also have all this stuff, but I don't see people trying to conflate a web browser with an OS. See the difference between ChromeOS[0] and Chrome[1].
[0]: https://en.m.wikipedia.org/wiki/ChromeOS
[1]: https://en.m.wikipedia.org/wiki/Google_Chrome
Chrome has an elisp interpreter? Details?
Sure here's one https://www.programiz.com/python-programming/online-compiler... and I'm sure you could find hundreds of others :)
That's not In chrome friend.
> Emacs also has a built in email client, RSS reader, IRC client, calculator, file browser, web browser, markup language, regex DSL, Vim emulator, terminal emulator, custom elisp based shell, interactive REPL that works for several programming languages...
Then most of these things are not in "emacs" since most of them are packages and not builtin. That was my point. Emacs is insanely customizable through packages, and can essentially run anything. Chrome and Firefox and any other web browser are also insanely customizable through "packages" which you just so happen to download as soon as you enter the URL to the "package" you want, which we really refer to as a web app. But, that doesn't make the browser an OS, and it doesn't make emacs an OS either.
Then most of these things are not in "emacs" since most of them are packages and not builtin. That was my point. Emacs is insanely customizable through packages, and can essentially run anything. Chrome and Firefox and any other web browser are also insanely customizable through "packages" which you just so happen to download as soon as you enter the URL to the "package" you want, which we really refer to as a web app. But, that doesn't make the browser an OS, and it doesn't make emacs an OS either.
One you run in emacs, the other you run on someone else's computer, I guess my expectations were mismatched.
Emacs is neither an OS nor an editor, but it’s closer to the former than the latter. It’s probably most accurate to describe it as a framework (and bundled programming language) for building custom IDEs.
Ok, it doesnt have a kernel full of hardware drivers or an implementation that runs on bare metal. That said, it covers a lot of userland and things otherwise covered by a Desktop Environment (which are often conflated with OSes). In terms of application hosting, window management, low-level system control, etc. and the fact that some brave souls have had success with running emacs as PID 1 means that it's not a million miles away from being an OS.
(And that's without the inevitable implementation of some basic OS functions in elisp by various wizards)
(And that's without the inevitable implementation of some basic OS functions in elisp by various wizards)
> or an implementation that runs on bare metal
There's https://github.com/whily/yalo apparently
There's https://github.com/whily/yalo apparently
(global-set-key (kbd "M-<tab>") #'completion-at-point-using-chatgpt)I am an emacs user, but sometimes I do feel like it isn't a meme. If you could give me a linux kernel that just boots and interfaces with emacs, I am pretty sure it would cover 90-95% of my computer usage cases. Essentially emacs is an OS that just lacks a kernel. And in a way it is a compliment, Emacs is so much more capable than just as a text editor.
Making a new account to post a pithy pedantic negative reply is usually a indicator of irl issues that need to be addressed. The parent is not wrong in his point that comparing vi to emacs is the proverbial apples to oranges. They are different types of tools
> Emacs is an operating system
Reminds me of an old joke: "Emacs would be a great OS, if only it came with a decent text editor..."
Reminds me of an old joke: "Emacs would be a great OS, if only it came with a decent text editor..."
Not an operating system, more like a desktop environment.
A single threaded OS. I remember that sometimes I launched a slow process in emacs, and then can do nothing but wait.
I am surprised you didn’t use evil-mode to emulate the vim keybindings. Or was this a an attempt to use “pure” Emacs without packages and customization?
It sounds like they're not even aware that it was an option.
Many people don't realize that emacs' default keybindings can be changed to be modal in exactly the same as vim, by using evil.
Many people don't realize that emacs' default keybindings can be changed to be modal in exactly the same as vim, by using evil.
Sorry for the naive question, but if you're changing all your bindings to vim, then why use emacs at all? Is there any extra functional difference?
Emacs is more like an ecosystem around text, so switching keybinding does not matter much. And most people's system is installed on a single computer, very much like Photoshop or Visual Studio. Vim is all about editing text and the keybinding are like a DSL for this purpose, so changing things will make you awkward everywhere.
The clue lies in the fact that you can customize the editing experience to function like Vim. Because that’s one out of a thousand different ways you can customize that app to function like a one-off editor, a Git client, an email reader, and so on.
There's a ton more to both editors than just keybindings.
See this post[1] where I talk about some of the things I've done with emacs -- none of which have anything to do with bindings.
You can do millions of other things too, as I'm not using emacs nearly to its full capacity. Same with vim.
Bindings in editors are like symbols in math. Yes, they're necessary, and you can do a lot with them, but symbols are not nearly all there is to math.
[1] - https://news.ycombinator.com/item?id=35560107
See this post[1] where I talk about some of the things I've done with emacs -- none of which have anything to do with bindings.
You can do millions of other things too, as I'm not using emacs nearly to its full capacity. Same with vim.
Bindings in editors are like symbols in math. Yes, they're necessary, and you can do a lot with them, but symbols are not nearly all there is to math.
[1] - https://news.ycombinator.com/item?id=35560107
Vi is like an standard for moving around and editing text files. I use Vi-style commands in all my editors: Emacs, IntelliJ, and VSCode. For me, any application that supports Vi keybindings and has some sort of command palette will feel like home.
Regarding why edit files in Emacs instead of vim: I simply work on Emacs. I don't use a CLI or a file manager to navigate to my files, I already have projects set up in Emacs and can quickly open files in any such projects. Emacs also holds my note taking system. And when I'm dealing with git, nothing comes close to magit. Also, I've been using the Spacemacs framework for years, which makes it really easy to create such a customized and efficient configuration without much hassle.
Regarding why edit files in Emacs instead of vim: I simply work on Emacs. I don't use a CLI or a file manager to navigate to my files, I already have projects set up in Emacs and can quickly open files in any such projects. Emacs also holds my note taking system. And when I'm dealing with git, nothing comes close to magit. Also, I've been using the Spacemacs framework for years, which makes it really easy to create such a customized and efficient configuration without much hassle.
The reason people like emacs has nothing to do with the default key bindings, which are basically arbitrary. Emacs is a framework and programming environment for building custom IDEs.
You get the vi bindings and modal behaviour which I find better _plus_ all emacs functions and most of the emacs bindings. I’m often mixing the 2 modes while editing.
> they're not even aware that it was an option
Actually in this case I was - but my goal was to use "vanilla" emacs just like I use "vanilla" vi(m). After all, if I'm using vi key bindings... why not just use vi?
Actually in this case I was - but my goal was to use "vanilla" emacs just like I use "vanilla" vi(m). After all, if I'm using vi key bindings... why not just use vi?
The pure text editing is just a tiny detail. I exclusively use vim keybindings inside Emacs, as many others do.
Emacs makes extending the editor a breeze. As a new user this just means that you have packages (like VS 'extensions' or IntelliJ 'plugins') for, well, everything. For a more advanced user it means you can automate away many things that are a pain in the ass to repeatedly do in your daily work.
I'd suggest you try Doom Emacs when you have a couple of free hours to get a taste of what a properly configured Emacs can do. And, once you are on it, just press "SPC f p", select 'init.el' and check what popular packages you can activate just by uncommenting a line and doing a 'doom sync'. Then press "SPC f p" and select 'config.el' to check how even "configuration" in Emacs is just elisp code. You are just running a piece of code you can edit and even debug from itself _while_ you are running it (although that'd require a bit more explanation of how it's done) . This should give you a taste of what Emacs is about.
Emacs makes extending the editor a breeze. As a new user this just means that you have packages (like VS 'extensions' or IntelliJ 'plugins') for, well, everything. For a more advanced user it means you can automate away many things that are a pain in the ass to repeatedly do in your daily work.
I'd suggest you try Doom Emacs when you have a couple of free hours to get a taste of what a properly configured Emacs can do. And, once you are on it, just press "SPC f p", select 'init.el' and check what popular packages you can activate just by uncommenting a line and doing a 'doom sync'. Then press "SPC f p" and select 'config.el' to check how even "configuration" in Emacs is just elisp code. You are just running a piece of code you can edit and even debug from itself _while_ you are running it (although that'd require a bit more explanation of how it's done) . This should give you a taste of what Emacs is about.
Both vanilla emacs and vanilla vim are only a tiny fraction as powerful as either editor enhanced with plugins. You really missed out with this choice.
They're the default keys because a lot of programs use the GNU readline package for line editing.
It's also possible to configure GNU readline on your system to use vi keys. See https://vim.fandom.com/wiki/Use_vi_shortcuts_in_terminal
Put this in ~/.inputrc
Put this in ~/.inputrc
set editing-mode vi
set keymap vi-commandYou'll also want `set show-mode-in-prompt on`.
Note that this feature is broken when you have a PS1 with a \n in it, in an older version of readline/bash (I am not sure which), so if you're having this problem, just upgrade your bash version.
Note that this feature is broken when you have a PS1 with a \n in it, in an older version of readline/bash (I am not sure which), so if you're having this problem, just upgrade your bash version.
would definitely agree. i find tmux + vim does almost everything i need. granted i don't try to script anything myself. generally there are command line tools or vim plugins that do most i want. adding to much gravy to vim also just slows vim down which can be incredibly frustrating when one is used to typing very fast.
i would say just a couple of years of vim isn't enough to really become one with the software. think it took me around 5 years to really understand why vim is amazing. took me at least one year just to get the hang of it properly and be highly productive. i can't even type in a normal editor anymore as my brain is wired to vim commands. and i still to this day learn new commands which make my life easier.
that being said i totally understand why people love emacs. but i get a decent amount of the window management stuff just using the tmux.
and vi is installed almost everywhere as an editor which makes editing in 90% of environments a breeze. even when in windows gvim does pretty good.
i would say just a couple of years of vim isn't enough to really become one with the software. think it took me around 5 years to really understand why vim is amazing. took me at least one year just to get the hang of it properly and be highly productive. i can't even type in a normal editor anymore as my brain is wired to vim commands. and i still to this day learn new commands which make my life easier.
that being said i totally understand why people love emacs. but i get a decent amount of the window management stuff just using the tmux.
and vi is installed almost everywhere as an editor which makes editing in 90% of environments a breeze. even when in windows gvim does pretty good.
> the emacs cursor movement commands, which are (for some reason) the default cursor movement commands in most command line environments like the Postgres CLI.
I think this is because they're used in GNU readline. They're also defaults in all the macOS GUIs, though, so maybe not.
I think this is because they're used in GNU readline. They're also defaults in all the macOS GUIs, though, so maybe not.
> GNU readline
Interesting... I always assumed that emacs was around for a while before anybody generalized a "readline" library, but I guess it makes sense that readline would have come first.
Interesting... I always assumed that emacs was around for a while before anybody generalized a "readline" library, but I guess it makes sense that readline would have come first.
emacs definitely came first, and readline adopted emacs bindings (it also supports vi)
To each their own. Minds function differently, desire different workflows, and thus are extended better with different tools.
I use both non-evil emacs and neovim, given the mood I am feeling that day. For quick and dirty things, I prefer neovim, and for more extended workflows, I prefer emacs.
But besides functional differences, the two "mediums" feel different. Neovim is clean (and hangs less in general). No bloat. Emacs is a monster, suited towards my liking (with many years of .emacs config).
But as much as I love Lisp, sometimes you want to get away from the bloat and sit quietly with a blinking cursor in vim.
I use both non-evil emacs and neovim, given the mood I am feeling that day. For quick and dirty things, I prefer neovim, and for more extended workflows, I prefer emacs.
But besides functional differences, the two "mediums" feel different. Neovim is clean (and hangs less in general). No bloat. Emacs is a monster, suited towards my liking (with many years of .emacs config).
But as much as I love Lisp, sometimes you want to get away from the bloat and sit quietly with a blinking cursor in vim.
I had a very similar experience and at the end of the day I switched back to vi(m) (and specialized IDEs) mostly because I didn't have the time to constantly evolve my emacs environment to solve the tasks at hand efficiently. I can see the appeal of emacs though if you really have the time and energy to deep dive and make it your own environment.
To this day, I still swap ctrl/capslock - that is so useful that it should just be a standard.
To this day, I still swap ctrl/capslock - that is so useful that it should just be a standard.
The default cursor movement commands probably predate emacs. Such that you are used to readline defaults. https://news.ycombinator.com/item?id=24083753 is the first post I'm finding on that.
That said, I'm curious what the weight of emacs was on you? If it was that you were wanting to be in the other editor, than it makes sense that you should stay in the other editor. But this is no different than a lot of things. Is why some folks don't like changing the vehicle type that they use daily. Very little rational argument one way or the other. Such that, yes, you should use what makes you happy. Not only does it make you happy, but you are probably more effective because of that.
That said, I'm curious what the weight of emacs was on you? If it was that you were wanting to be in the other editor, than it makes sense that you should stay in the other editor. But this is no different than a lot of things. Is why some folks don't like changing the vehicle type that they use daily. Very little rational argument one way or the other. Such that, yes, you should use what makes you happy. Not only does it make you happy, but you are probably more effective because of that.
> what the weight of emacs was on you
What I've noticed about emacs lovers is that they all customize it heavily - I didn't want to do that, since to me the point of using a plain text editor is that it's always available in exactly the same form wherever I happen to be. I did start to looking into all the ways to customize it, but at that point, I couldn't really see much benefit over just using an IDE.
But that's just me.
What I've noticed about emacs lovers is that they all customize it heavily - I didn't want to do that, since to me the point of using a plain text editor is that it's always available in exactly the same form wherever I happen to be. I did start to looking into all the ways to customize it, but at that point, I couldn't really see much benefit over just using an IDE.
But that's just me.
"What I've noticed about emacs lovers is that they all customize it heavily - I didn't want to do that, since to me the point of using a plain text editor is that it's always available in exactly the same form wherever I happen to be. "
So you not customize vim either?
If you don't, you're missing out 99.999% of the greatness of both editors and doing yourself a huge disservice.
It's like being a carpenter and limiting yourself to only ever using a screwdriver.
So you not customize vim either?
If you don't, you're missing out 99.999% of the greatness of both editors and doing yourself a huge disservice.
It's like being a carpenter and limiting yourself to only ever using a screwdriver.
> you not customize vim
No, and I have a specific reason - I ssh into remote boxes a lot, and I want the editor to work more or less the same wherever and whenever I use it. I guess I could customize vi to be a multi-purpose IDE but... that's what I have IntelliJ for.
No, and I have a specific reason - I ssh into remote boxes a lot, and I want the editor to work more or less the same wherever and whenever I use it. I guess I could customize vi to be a multi-purpose IDE but... that's what I have IntelliJ for.
That isn't a perfect reason to not customize your local editor. Most all allow opening remote files and shells. And simpler things like recently opened files can already be very convenient.
Simply put, IDE in the IDEA sense is not the only end goal. Such that that straw man is obnoxious.
Now, it is perfectly fine to just not want to. Such that I am not saying you should reconsider. Just don't be too proud of that reasoning.
Simply put, IDE in the IDEA sense is not the only end goal. Such that that straw man is obnoxious.
Now, it is perfectly fine to just not want to. Such that I am not saying you should reconsider. Just don't be too proud of that reasoning.
If you're using vi or vim for really simple tasks, and not using it much, you're not missing out by not customizing it.
But the more you use it, the more you're missing out by just using vanilla vi or vim... and I hesitate to mention them in the same sentence because even vanilla vim is thousands of times more powerful than vi.
Vim's true power, however, lies in its customization and plugins. You're really missing out by restricting yourself this way.
But the more you use it, the more you're missing out by just using vanilla vi or vim... and I hesitate to mention them in the same sentence because even vanilla vim is thousands of times more powerful than vi.
Vim's true power, however, lies in its customization and plugins. You're really missing out by restricting yourself this way.
Oddly, I haven't customized mine heavily. I'd assert that there really isn't a single "crowd" that are computer users. All the more true for stuff as customizable as emacs.
Even more amusing, I'm fairly certain I had more customization in vim before I decided I wanted to learn lisp. What ultimately killed my customization in all things, was I felt like I was customizing on top of a very shaky foundation. Emacs/vim are stable enough, of course. But building/packaging software is basically a giant playground.
Even more amusing, I'm fairly certain I had more customization in vim before I decided I wanted to learn lisp. What ultimately killed my customization in all things, was I felt like I was customizing on top of a very shaky foundation. Emacs/vim are stable enough, of course. But building/packaging software is basically a giant playground.
I've been using Emacs for more than 30 years and my init file is mostly loading and configuring extra packages, and not customizing the editing behavior. I have no problem working in a basic "emacs -q" session (which skips loading the init file) when I don't want to "pollute" my main session (eg. working with huge logs/dumps).
This is the way. While I do rebind plenty keys to enhanced or do-what-I-mean versions, I'm careful to avoid fundamentally change the meaning of any of the vanilla keys. So I see my config as more of a progressive enhancement over `emacs -q` or `mg` and I can still work with them just fine (if somewhat less comfortably).
Being able to work with `emacs -q` is also important to me for extending Emacs. It's easy to partially roll back a change if I break something in my config, and I can test out new elisp code against base Emacs.
Being able to work with `emacs -q` is also important to me for extending Emacs. It's easy to partially roll back a change if I break something in my config, and I can test out new elisp code against base Emacs.
This has gotten easier as the years go by, as well. Standard emacs has a lot of affordances that computers just couldn't do without bogging down the system years ago.
I have all my emacs stuff in a git repo called .emacs.d. Wherever I am, I clone it into my home folder, and Emacs picks it up when I run it. Then it ends up looking the same as it always is.
"But what if you end up somewhere where you can't do this?" - well, when it happens, I guess I will figure something out! But I've had no problems so far, and I've been doing this a while.
My config currently works with Windows, macOS and Linux, terminal or GUI, and with any Emacs from 26 to 29, and it behaves about the same in all cases. This didn't take much effort! - though each untested combination have a bad habit of requiring 5-10 minutes of fiddling about.
"But what if you end up somewhere where you can't do this?" - well, when it happens, I guess I will figure something out! But I've had no problems so far, and I've been doing this a while.
tmbp ~/.emacs.d % git log | tail -n 1
Date: Sat Feb 23 23:30:41 2008 +0000
My config currently works with Windows, macOS and Linux, terminal or GUI, and with any Emacs from 26 to 29, and it behaves about the same in all cases. This didn't take much effort! - though each untested combination have a bad habit of requiring 5-10 minutes of fiddling about.
Yeah I adore picking at my config to solve some small issue. Or implement a cool feature or customization.
I don't really use Emacs for the editor! It's more because it's a very configurable language runtime/vm with an editor interface.
And org-mode is great too.
I don't really use Emacs for the editor! It's more because it's a very configurable language runtime/vm with an editor interface.
And org-mode is great too.
Emacs predates readline by 13 years
I think of emacs as more of an operating system for emacs lisp with an in-built editor more than I think of it as an editor.
I say that because I have "live documents" that run Jira queries for me, and cross reference defects to other systems behind REST interfaces and can drive the whole thing with a few keystrokes.
(And it didn't take long to put together)
Emacs and emacs lisp, is a bit like Smalltalk in some ways too, once you get the hang of it. (and I've thought of porting that entire workflow I just mentioned to Pharo too)
I say that because I have "live documents" that run Jira queries for me, and cross reference defects to other systems behind REST interfaces and can drive the whole thing with a few keystrokes.
(And it didn't take long to put together)
Emacs and emacs lisp, is a bit like Smalltalk in some ways too, once you get the hang of it. (and I've thought of porting that entire workflow I just mentioned to Pharo too)
> to this day I still don't see what the hype was about.
As an Emacs user[1], I agree. The flexibility is really cool, and there are a handful of Emacs applications (notice I didn't call them "packages") that are "killer apps", like Magit, Org-Mode, Calc, etc.
But, even though I do use and like Emacs, I can't honestly recommend it to anyone and I wouldn't even consider it to be a very good programming environment unless you're specifically working in a Lisp/Scheme (where it's awesome).
These days, I mostly use Emacs for programming in Rust and for using Magit as a git porcelain even when not using Emacs for the actual code editing.
Here are the things that suck[2] about Emacs (mostly from the point of view of a programming text editor):
* The UI is slow. Don't tell me that it's "only" when we have long lines, or too much syntax highlighting or whatever. Sure, if I turn off all of the useful programming features, the UI updates fast enough for me to not notice any latency, but any time I open a file that uses a LSP server or equivalent (not just Rust- I've done Clojure, JavaScript, PHP, and C++ in Emacs), the latency for even just moving the cursor around is noticeable and it's distracting.
* Tramp sucks. I don't understand how everyone says that Tramp is awesome and magical. Every single time I've tried to use it to do anything, it's been a bad experience. It's been a few years since I've even tried it, but I remember having to wrestle with ssh-agent authentication, some packages not playing nicely with it (besides the "obvious" ones like LSP-mode), and the whole application hanging if the Tramp session hung for some reason.
* It's actually really HARD to customize properly. The experts say that Emacs is "self-documenting" and "introspectable", but many times, I'll try to customize some behavior or a keymap or something, and I'll read the documentation for a variable or function and it'll say something like "takes a plist of FOO definitions,"--well, what the heck does a "FOO" definition look like? What are the keys for the plist? What are acceptable values for those keys? It's very common to just have to dig through the actual elisp code to find out. Then, you'll find out that your customization doesn't even work correctly because some other mode or function stomps on your code, or gets initialized in a different logic path that isn't affected by your change. Since every feature and every package is different, you have little chance of just figuring out a few conventions or any standard structure for packages.
* Handling buffers is tedious. Sometimes buffers appear and take over the whole frame, sometimes they split the frame and steal focus, and sometimes they split the frame and don't steal focus. And it's very ad-hoc and tedious to try to separate out "background, system buffers" from "my actual work buffers". There are tons of Emacs packages that attempt to make it easier to manage buffers, switch between them more easily, group them in lists, etc.
Like I said, I like Emacs. But, I also run Linux on my personal machines and run a de-Googled AOSP ROM on my rooted Android phone. UX, polish, and convenience are obviously not a high priority for me.
[1]: I've used Emacs to varying degrees and with varying levels of dedication and hardcore-ness since 2008-ish. At a few points, I would've said that I was pretty competent/proficient in Elisp, and have authored some fairly elaborate functions to help me with common tasks within Emacs. I even use to try to do a version of "literate programming" with org-mode and org-mode babel blocks in place of something like Jupyter notebooks for Python.
[2]: Yes, this is a very negative comment, but I tend to complain loudest about the things that I love and care about. I don't complain or criticize things that I don't like or don't want to use.
As an Emacs user[1], I agree. The flexibility is really cool, and there are a handful of Emacs applications (notice I didn't call them "packages") that are "killer apps", like Magit, Org-Mode, Calc, etc.
But, even though I do use and like Emacs, I can't honestly recommend it to anyone and I wouldn't even consider it to be a very good programming environment unless you're specifically working in a Lisp/Scheme (where it's awesome).
These days, I mostly use Emacs for programming in Rust and for using Magit as a git porcelain even when not using Emacs for the actual code editing.
Here are the things that suck[2] about Emacs (mostly from the point of view of a programming text editor):
* The UI is slow. Don't tell me that it's "only" when we have long lines, or too much syntax highlighting or whatever. Sure, if I turn off all of the useful programming features, the UI updates fast enough for me to not notice any latency, but any time I open a file that uses a LSP server or equivalent (not just Rust- I've done Clojure, JavaScript, PHP, and C++ in Emacs), the latency for even just moving the cursor around is noticeable and it's distracting.
* Tramp sucks. I don't understand how everyone says that Tramp is awesome and magical. Every single time I've tried to use it to do anything, it's been a bad experience. It's been a few years since I've even tried it, but I remember having to wrestle with ssh-agent authentication, some packages not playing nicely with it (besides the "obvious" ones like LSP-mode), and the whole application hanging if the Tramp session hung for some reason.
* It's actually really HARD to customize properly. The experts say that Emacs is "self-documenting" and "introspectable", but many times, I'll try to customize some behavior or a keymap or something, and I'll read the documentation for a variable or function and it'll say something like "takes a plist of FOO definitions,"--well, what the heck does a "FOO" definition look like? What are the keys for the plist? What are acceptable values for those keys? It's very common to just have to dig through the actual elisp code to find out. Then, you'll find out that your customization doesn't even work correctly because some other mode or function stomps on your code, or gets initialized in a different logic path that isn't affected by your change. Since every feature and every package is different, you have little chance of just figuring out a few conventions or any standard structure for packages.
* Handling buffers is tedious. Sometimes buffers appear and take over the whole frame, sometimes they split the frame and steal focus, and sometimes they split the frame and don't steal focus. And it's very ad-hoc and tedious to try to separate out "background, system buffers" from "my actual work buffers". There are tons of Emacs packages that attempt to make it easier to manage buffers, switch between them more easily, group them in lists, etc.
Like I said, I like Emacs. But, I also run Linux on my personal machines and run a de-Googled AOSP ROM on my rooted Android phone. UX, polish, and convenience are obviously not a high priority for me.
[1]: I've used Emacs to varying degrees and with varying levels of dedication and hardcore-ness since 2008-ish. At a few points, I would've said that I was pretty competent/proficient in Elisp, and have authored some fairly elaborate functions to help me with common tasks within Emacs. I even use to try to do a version of "literate programming" with org-mode and org-mode babel blocks in place of something like Jupyter notebooks for Python.
[2]: Yes, this is a very negative comment, but I tend to complain loudest about the things that I love and care about. I don't complain or criticize things that I don't like or don't want to use.
I love emacs, but agree with many of your criticisms.
Emacs can be slow. I don't use LSP, so can't comment on that, but it's definitely slow on long lines with syntax highlighting.
I don't use TRAMP for exactly one of the reasons you mentioned: it can hang Emacs. I want to avoid that at all costs, because I pretty much live in Emacs.
Emacs' default handling of windows (in emacs terminology it's "windows", not "buffers" that you're talking about) is painful, but you can improve that through various packages, like popper[1]
Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?
Also, remember that you don't have to go it alone in troubleshooting the issues you run in to with emacs. There's a whole community ready and willing to help.
Despite the downsides of emacs, I still use and love it. Every editor has downsides, and emacs is no exception. Its positives far, far outweigh the negatives for me. There's just so much more that it can do than other editors, and it's far more customizable. I very much doubt I'll ever seriously consider switching to another.
[1] - https://github.com/karthink/popper
Emacs can be slow. I don't use LSP, so can't comment on that, but it's definitely slow on long lines with syntax highlighting.
I don't use TRAMP for exactly one of the reasons you mentioned: it can hang Emacs. I want to avoid that at all costs, because I pretty much live in Emacs.
Emacs' default handling of windows (in emacs terminology it's "windows", not "buffers" that you're talking about) is painful, but you can improve that through various packages, like popper[1]
Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?
Also, remember that you don't have to go it alone in troubleshooting the issues you run in to with emacs. There's a whole community ready and willing to help.
Despite the downsides of emacs, I still use and love it. Every editor has downsides, and emacs is no exception. Its positives far, far outweigh the negatives for me. There's just so much more that it can do than other editors, and it's far more customizable. I very much doubt I'll ever seriously consider switching to another.
[1] - https://github.com/karthink/popper
> Emacs' default handling of windows (in emacs terminology it's "windows", not "buffers" that you're talking about) is painful, but you can improve that through various packages, like popper[1]
Whether I'm complaining about buffer handling or window handling is a matter of perspective. If some event causes Emacs to create a new buffer and to split my frame with a new window to display it, I see that as Emacs handling the buffer *by* creating a window. Not that it matters, because we all know what I mean, because we all share the pain.
It's such a universal issue that there are tons of packages and tips for trying to improve the situation, such as popper. I've tried several over the years and have given up on using any of them because it's always a game of whack-a-mole. There's always some new surprise that is not caught by the helper package and/or your own configuration. So, today, I just have some easy-to-hit key bindings to quickly close the most recent buffer/window, or change focus, etc. It's still a pain in the ass to sift through my buffer lists, but oh well.
> Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?
I don't know anything about VSCode, honestly, but I'll pessimistically assume that its plugins are "closed" to the end-user. Is that true?
But, it's all a double-edged sword. Everyone acts like Emacs is so open that you or I can just go in and fix whatever we want, but that's obviously not true- neither in a strict technical sense (can't edit the tons of inner C code directly in my configs), nor in a practical sense. If Emacs is such that you or I can just hack some ELisp to improve whatever we want, then why haven't you or I fixed our troubles with TRAMP, or slow UI rendering, or the buffers/windows problems?
Is Emacs very hackable? Yes. Much more so than any other editing environment. Is it completely changeable? No. Not even close.
Yet, the trade-off is that there's no structure to anything. Packages all do their own thing, and tap into various parts of Emacs when they're loaded. So, if you load the same two packages in different orders, you can end up with different results. This is especially frustrating with keymaps. Plus, a lot of (most?) packages have auto-loading, which means you don't always even *know* the order in which your packages will load, so sometimes your Emacs will behave differently than other times even with no config changes!
I love the philosophy of making everything hackable, but there's definitely something to be said for enforcing some structure or limits on when and how things are modified.
By far the best part about other programming editors compared to Emacs is that I can install umpteen addons/plugins/whatever and still go to ONE settings menu and see/edit all of my keybindings. And those keybindings will always be correct, no matter how many times I restart the editor, no matter what order I do work during an editing session, etc.
> Despite the downsides of emacs, I still use and love it.
Same here. I love it, but I also hate it. It's so powerful and there's so much potential, but it's also just so bad in a lot of ways.
Closing thought:
Sometimes people say Emacs has bad defaults. But that makes it sound like it's just a matter of some settings. Like you just need to pick a nicer font, pick a nice color scheme, change some key bindings, and turn off the splash screen and that'll do it.
But, if you look at all of the buffer/window helper packages (e.g., popper), and all of the package-management helpers that basically every single one of us use (use-package, straight, elpaca, etc), and how many people ask for help with key binding (and use things like general.el), then it starts to seem like the issue of "bad defaults" isn't really about minor settings tweaks--it's just that Emacs doesn't really *work* that well by default.
I'm going to keep using it, but I'm not going to pretend that it's actually a good editor. It's not even actually a good application platform because a hung SSH connection through TRAMP or a slow-to-load email refresh in gnus or mu4e can take the whole thing down--imagine if your OS went down when an SSH connection dropped...
Whether I'm complaining about buffer handling or window handling is a matter of perspective. If some event causes Emacs to create a new buffer and to split my frame with a new window to display it, I see that as Emacs handling the buffer *by* creating a window. Not that it matters, because we all know what I mean, because we all share the pain.
It's such a universal issue that there are tons of packages and tips for trying to improve the situation, such as popper. I've tried several over the years and have given up on using any of them because it's always a game of whack-a-mole. There's always some new surprise that is not caught by the helper package and/or your own configuration. So, today, I just have some easy-to-hit key bindings to quickly close the most recent buffer/window, or change focus, etc. It's still a pain in the ass to sift through my buffer lists, but oh well.
> Depending on what problems you run in to and your skill level, it could be tricky to debug elisp programs. However, compare that to when you run in to some bug in VSCode... how are you going to debug that? You'll probably have to submit a bug report and wait for the developers to get to it (if they ever do)... how is that better than emacs?
I don't know anything about VSCode, honestly, but I'll pessimistically assume that its plugins are "closed" to the end-user. Is that true?
But, it's all a double-edged sword. Everyone acts like Emacs is so open that you or I can just go in and fix whatever we want, but that's obviously not true- neither in a strict technical sense (can't edit the tons of inner C code directly in my configs), nor in a practical sense. If Emacs is such that you or I can just hack some ELisp to improve whatever we want, then why haven't you or I fixed our troubles with TRAMP, or slow UI rendering, or the buffers/windows problems?
Is Emacs very hackable? Yes. Much more so than any other editing environment. Is it completely changeable? No. Not even close.
Yet, the trade-off is that there's no structure to anything. Packages all do their own thing, and tap into various parts of Emacs when they're loaded. So, if you load the same two packages in different orders, you can end up with different results. This is especially frustrating with keymaps. Plus, a lot of (most?) packages have auto-loading, which means you don't always even *know* the order in which your packages will load, so sometimes your Emacs will behave differently than other times even with no config changes!
I love the philosophy of making everything hackable, but there's definitely something to be said for enforcing some structure or limits on when and how things are modified.
By far the best part about other programming editors compared to Emacs is that I can install umpteen addons/plugins/whatever and still go to ONE settings menu and see/edit all of my keybindings. And those keybindings will always be correct, no matter how many times I restart the editor, no matter what order I do work during an editing session, etc.
> Despite the downsides of emacs, I still use and love it.
Same here. I love it, but I also hate it. It's so powerful and there's so much potential, but it's also just so bad in a lot of ways.
Closing thought:
Sometimes people say Emacs has bad defaults. But that makes it sound like it's just a matter of some settings. Like you just need to pick a nicer font, pick a nice color scheme, change some key bindings, and turn off the splash screen and that'll do it.
But, if you look at all of the buffer/window helper packages (e.g., popper), and all of the package-management helpers that basically every single one of us use (use-package, straight, elpaca, etc), and how many people ask for help with key binding (and use things like general.el), then it starts to seem like the issue of "bad defaults" isn't really about minor settings tweaks--it's just that Emacs doesn't really *work* that well by default.
I'm going to keep using it, but I'm not going to pretend that it's actually a good editor. It's not even actually a good application platform because a hung SSH connection through TRAMP or a slow-to-load email refresh in gnus or mu4e can take the whole thing down--imagine if your OS went down when an SSH connection dropped...
I have love/hate relationship with Emacs too, but for the stuff I do in Emacs I hate other software more. So Emacs it is.
> Handling buffers is tedious.
I feel the pain. I often daydream about spending time customizing it to my needs, and add that to the other 576 ways I want to customize it and don't have time.
And then I sigh and remind myself "At least it's better than tabs!" before I return to my tasks at hand.
I feel the pain. I often daydream about spending time customizing it to my needs, and add that to the other 576 ways I want to customize it and don't have time.
And then I sigh and remind myself "At least it's better than tabs!" before I return to my tasks at hand.
> which are (for some reason) the default cursor movement commands in most command line environments like the Postgres CLI.
AFAIK/IIRC these bindings are something to do with readline being widely used for CLI interfaces?
Additionally, they work all over OSX too (on text inputs), not just the shell--<C-a>, <C-e> for start and end of line, etc, probably lots of others too that I'm unaware of.
AFAIK/IIRC these bindings are something to do with readline being widely used for CLI interfaces?
Additionally, they work all over OSX too (on text inputs), not just the shell--<C-a>, <C-e> for start and end of line, etc, probably lots of others too that I'm unaware of.
why didn't you just use evil mode? vim is great and so is emacs and with evil mode you get vim inside emacs. i still use emacs for magit as it's hands down the best git gui i've seen so far.
i used to use spacemacs but just wanted a quicker startup while still being reasonably configured... doom emacs is both.
i used to use spacemacs but just wanted a quicker startup while still being reasonably configured... doom emacs is both.
> I've been a hardcore vi user pretty much my entire life, but I decided to force myself to spend a year using emacs a while back just to see what all the fuss was about.
This is like saying that you have been a mountain biker all your life, but then decided to play the trumpet for one year. Nonsensical conjunction.
This is like saying that you have been a mountain biker all your life, but then decided to play the trumpet for one year. Nonsensical conjunction.
As someone who used Emacs 10yrs before ditching it.. I just really don't think it's very good at doing much.
I mean sure it can sorta half ass a lot of different things but besides org-mode and magit, it's a pretty mediocre and clunky piece of software (clunky, incredibly slow, ugly, etc)
I mean sure it can sorta half ass a lot of different things but besides org-mode and magit, it's a pretty mediocre and clunky piece of software (clunky, incredibly slow, ugly, etc)
Nonsense. Emacs and vi have similar use cases, right? And similar inputs (keyboard) and similar environments, for similar users.
They might be a difference of degree along a few axes, but they aren't a difference of kind like trumpets and mountain bikes are.
They might be a difference of degree along a few axes, but they aren't a difference of kind like trumpets and mountain bikes are.
I did the same experiment and came to the same conclusion. There’s really nothing killer in Emacs that makes it a huge sell over just using vim which is a much better editor unless you just love Emacs lisp. Emacs also has some glaring issues - tramp being a major one. It’s slow and very unreliable.
Vim is much more in line with the Unix philosophy. It’s a great editor that can be extended with fzf, ripgrep, lsps, git etc. Emacs has three versions of every plugin and they’re all usually not as good as the thin vim wrapper around fzf etc. If you’re not editing and need email, mutt is a great email client. Irssi is a great chat client. Emacs is very much an all or nothing computing environment.
I am glad I tried Emacs though, because I did love which-key and ended up adding it to my Vim config. And Emacs is slightly easier to quit?
ADVICE: Try both Emacs and Vim vanilla before you do anything else. Downloading a "distro" is really doing yourself a disservice by not showing you just how much either can do without the chrome. And for the love of RMS DON'T USE VSCODE.
Vim is much more in line with the Unix philosophy. It’s a great editor that can be extended with fzf, ripgrep, lsps, git etc. Emacs has three versions of every plugin and they’re all usually not as good as the thin vim wrapper around fzf etc. If you’re not editing and need email, mutt is a great email client. Irssi is a great chat client. Emacs is very much an all or nothing computing environment.
I am glad I tried Emacs though, because I did love which-key and ended up adding it to my Vim config. And Emacs is slightly easier to quit?
ADVICE: Try both Emacs and Vim vanilla before you do anything else. Downloading a "distro" is really doing yourself a disservice by not showing you just how much either can do without the chrome. And for the love of RMS DON'T USE VSCODE.
> There’s really nothing killer in Emacs
1. Org mode 2. Magit 3. Wdired 4. Synergy between various components (shameless plug: https://mbork.pl/2023-01-30_The_benefits_of_everything_being...)
1. Org mode 2. Magit 3. Wdired 4. Synergy between various components (shameless plug: https://mbork.pl/2023-01-30_The_benefits_of_everything_being...)
1. Org mode - I will admit that I'm not a fan of org mode and find it to be oversold and another time waster for people who are already wasting time configuring their editors. I personally use vimwiki, there is a vim plugin for org mode.
2. Magit - Tim Pope is the pope of Vim plugins and fugitive is easily as good or better than Magit. I have never had any issue doing any sort of complex task in git or fixing conflicting using fugitive.
3. Wdired - Tim Pope again has vim-vinegar to improve netrw. Never had a problem or thought about manipulating directories inside of Vim.
4. Again, if you believe in the Unix philosophy then you have to admit that Emacs is simply bloated and trying to do too much and therefore is not really the best at anything. And more importantly, if there's something that Emacs can't do you've screwed yourself because you haven't built an environment around many distinct tools on the command line and it's going to be awkward to integrate.
2. Magit - Tim Pope is the pope of Vim plugins and fugitive is easily as good or better than Magit. I have never had any issue doing any sort of complex task in git or fixing conflicting using fugitive.
3. Wdired - Tim Pope again has vim-vinegar to improve netrw. Never had a problem or thought about manipulating directories inside of Vim.
4. Again, if you believe in the Unix philosophy then you have to admit that Emacs is simply bloated and trying to do too much and therefore is not really the best at anything. And more importantly, if there's something that Emacs can't do you've screwed yourself because you haven't built an environment around many distinct tools on the command line and it's going to be awkward to integrate.
> if you believe in the Unix philosophy then you have to admit that Emacs is simply bloated and trying to do too much and therefore is not really the best at anything
On the contrary, Emacs tries to do just one thing: provide an Elisp runtime for other applications. It does this fairly well.
Do not confuse Elisp applications like evil, org, calc, magit, etc. with Emacs itself!
On the contrary, Emacs tries to do just one thing: provide an Elisp runtime for other applications. It does this fairly well.
Do not confuse Elisp applications like evil, org, calc, magit, etc. with Emacs itself!
Yep. If you see Emacs as a text editor with lots of features, then it's doing lots of things. But, if you see Emacs as a platform that comes bundled with some apps by default, then its "one thing" is to be a text-oriented app platform.
The whole "do one thing" slogan is kind of vacuous anyway; e.g., what if my "one thing" is "implement all WWW standards to be able to use any web page"? Is that still "one thing"? If not, then wouldn't implementing only "one" part of WWW be useless?
The whole "do one thing" slogan is kind of vacuous anyway; e.g., what if my "one thing" is "implement all WWW standards to be able to use any web page"? Is that still "one thing"? If not, then wouldn't implementing only "one" part of WWW be useless?
Emacs is a lisp refugee in Unixland. It does not follow the Unix philosophy, it follows the Lisp philosophy. But it integrates.
-- Source unknown (to me)
-- Source unknown (to me)
> Again, if you believe in the Unix philosophy then you have to admit that Emacs is simply bloated and trying to do too much and therefore is not really the best at anything.
If.
If.
> I will admit that I'm not a fan of org mode and find it to be oversold and another time waster for people who are already wasting time configuring their editors. I personally use vimwiki, there is a vim plugin for org mode.
I actually use emacs solely for org-mode. I find editing single files and even larger projects to be more of a pain that it is worth, so I just use my custom vim to do that.
What keeps me with org mode and emacs is mostly bibliography management. I have emacs set up to read my Zotero directory, and with a keybinding I can insert a reference to a book or magazine or the such. Now, what is really great about this is that when I export the org file (usually to latex->pdf, but also occasionaly to HTML), it exports the references in the style that they need to be in (MLA, APA, Turabian, etc.) and creates a bibliography page at the end of the export with everything that I referenced.
I can also add notes to any references using org-roam, so that I have have annotated bibliographies quite easily.
If I could have something else that does just this, I would drop emacs in a heartbeat. But until I do find that, emacs and org-mode it is.
I actually use emacs solely for org-mode. I find editing single files and even larger projects to be more of a pain that it is worth, so I just use my custom vim to do that.
What keeps me with org mode and emacs is mostly bibliography management. I have emacs set up to read my Zotero directory, and with a keybinding I can insert a reference to a book or magazine or the such. Now, what is really great about this is that when I export the org file (usually to latex->pdf, but also occasionaly to HTML), it exports the references in the style that they need to be in (MLA, APA, Turabian, etc.) and creates a bibliography page at the end of the export with everything that I referenced.
I can also add notes to any references using org-roam, so that I have have annotated bibliographies quite easily.
If I could have something else that does just this, I would drop emacs in a heartbeat. But until I do find that, emacs and org-mode it is.
Same. I have try many outliners to irrationally avoid emacs but they all suck compared to org-mode.
How do you surf the web in vim?
How do you read email, RSS news, and usenet with vim?
Does vim have a chat client as powerful as ERC?
Mainly, though, is vim programmed in and extended through a lisp, and does it have an entire lisp ecosystem built around it?
Don't get me wrong, I love vim, and used it and vi for 25 years before switching to emacs. But my emacs can do far, far more than vim ever did... and there's no way I'll be switching back until it has all the above and more.
How do you read email, RSS news, and usenet with vim?
Does vim have a chat client as powerful as ERC?
Mainly, though, is vim programmed in and extended through a lisp, and does it have an entire lisp ecosystem built around it?
Don't get me wrong, I love vim, and used it and vi for 25 years before switching to emacs. But my emacs can do far, far more than vim ever did... and there's no way I'll be switching back until it has all the above and more.
seems weird to me that one would want to do any of these things inside vim... though it should be possible with the right plugins... but why? just use a window manager like screen or tmux to multi-task.
It's because of the tight integration with the rest of the editor and all the rest of the packages that I use.
For example, when I go to edit an email I don't have to start up an external editor, so there is no context switching. Also, as emacs is super powerful, the editor that I use to edit my emails is super powerful, unlike the editors in most other mail clients.
Copying and pasting or importing/exporting between the various packages and other emacs buffers that I use is also seamless unlike anything that you do between conventional, separate applications. Everywhere that I go within emacs and everything that I do has the full power of emacs to do it with. I have macros, snippets, and elisp (to name just a few) at my fingertips.
Another advantage is that all these packages that I use (email, my git interface, RSS reader, etc) are all written in elisp and are integrated using elisp, so if you know elisp (which I do) it's easy to modify them to your liking, and have them do exactly what you want. This makes the whole experience super customizable to an extent unmatched pretty much anywhere else.
Without such integration and customizability, virtually all other software that I've used seems primitive and rigid by comparison.
So, yeah, it makes a big difference.
For example, when I go to edit an email I don't have to start up an external editor, so there is no context switching. Also, as emacs is super powerful, the editor that I use to edit my emails is super powerful, unlike the editors in most other mail clients.
Copying and pasting or importing/exporting between the various packages and other emacs buffers that I use is also seamless unlike anything that you do between conventional, separate applications. Everywhere that I go within emacs and everything that I do has the full power of emacs to do it with. I have macros, snippets, and elisp (to name just a few) at my fingertips.
Another advantage is that all these packages that I use (email, my git interface, RSS reader, etc) are all written in elisp and are integrated using elisp, so if you know elisp (which I do) it's easy to modify them to your liking, and have them do exactly what you want. This makes the whole experience super customizable to an extent unmatched pretty much anywhere else.
Without such integration and customizability, virtually all other software that I've used seems primitive and rigid by comparison.
So, yeah, it makes a big difference.
> seems weird to me that one would want to do any of these things inside vim... though it should be possible with the right plugins... but why? just use a window manager like screen or tmux to multi-task.
Imagine you put tons of information in vimwiki from your browser.
It's not a far stretch to wish you had a text browser inside of vim to more easily get important information into vim wiki.
At some point the browser could even begin to feel like a hindrance to curating and improving upon your higher quality vimwiki notes.
Emacs is like this, but not just for notes... for pretty much everything.
> just use a window manager like screen or tmux to multi-task.
I'm quite used to my auto-completion and snippets in emacs. As well as my clipboard history. The flexibility of isearch and how intuitive it's UX is.
If I leave emacs I never have all of those familiar things that fit like a glove. I'm in a different world with different rules that is far less malleable, understandable, and introspectable as emacs.
Hopefully that helps make sense of things a bit =)
Imagine you put tons of information in vimwiki from your browser.
It's not a far stretch to wish you had a text browser inside of vim to more easily get important information into vim wiki.
At some point the browser could even begin to feel like a hindrance to curating and improving upon your higher quality vimwiki notes.
Emacs is like this, but not just for notes... for pretty much everything.
> just use a window manager like screen or tmux to multi-task.
I'm quite used to my auto-completion and snippets in emacs. As well as my clipboard history. The flexibility of isearch and how intuitive it's UX is.
If I leave emacs I never have all of those familiar things that fit like a glove. I'm in a different world with different rules that is far less malleable, understandable, and introspectable as emacs.
Hopefully that helps make sense of things a bit =)
I think this sort of defense of EMacs misses a key point: most people have no interest in running a browser, email, chat, etc. from within their text editor.
Generally people prefer to do those sorts of things with specialized applications that are more tailored towards those individual use cases.
Generally people prefer to do those sorts of things with specialized applications that are more tailored towards those individual use cases.
Alas, living in emacs can't be appreciated until you get good at
emacs. More than the "one-stop-shop" aspect of it, there's the
"everything is a buffer of manipulable text" aspect which, again, can't
be appreciated until you make the leap of faith.
> Never had a problem or thought about manipulating directories inside of Vim.
It's extremely useful though, I find myself using the fact I can treat my directory list as a text file quite often.
It's extremely useful though, I find myself using the fact I can treat my directory list as a text file quite often.
Also related plug, a newsletter with emacs plugins to help out with, mostly org mode and AI and emacs integration open source tepos.
https://generativereview.substack.com/p/tasks-open-source-em...
https://generativereview.substack.com/p/tasks-open-source-em...
I wouldn't call Magit "killer" at this point, its basically feature competitive with other editor git integrations and that is about it
Use both heavily. Vim is fantastic for editing one off files.
Emacs on the other hand is fantastic to work on a computer for a long period of time. I do use evil mode, as I do think it's a much better way to work in a file. Project management, magit, org-mode, being able to edit functionality of the editor within couple of mins to adjust for an temporary change/or indefinitely is what keeps me coming back to emacs.
I've tried vim variations that build in project management and all I'm missing from emacs, but left it at some own written telescope functions to cover base needs.
Love for both, but to me they are not comparable.
(Maybe because I picked up emacs at the same time a good friend picked up vim, and it's been a parallel editor journey for 6+ years)
Emacs on the other hand is fantastic to work on a computer for a long period of time. I do use evil mode, as I do think it's a much better way to work in a file. Project management, magit, org-mode, being able to edit functionality of the editor within couple of mins to adjust for an temporary change/or indefinitely is what keeps me coming back to emacs.
I've tried vim variations that build in project management and all I'm missing from emacs, but left it at some own written telescope functions to cover base needs.
Love for both, but to me they are not comparable.
(Maybe because I picked up emacs at the same time a good friend picked up vim, and it's been a parallel editor journey for 6+ years)
Vim has terminal support, gdb support built in. We have vim plugins maintained by the top Vim plugin specialist for git and project management. We have vimwiki, markdown, org mode support. We have fuzzy finding, autocomplete, lap support. I really don't think you can reasonably tell me you can't live in Vim, when I have had the same session open editing the linux source tree for like two months now.
>I really don't think you can reasonably tell me you can't live in Vim
Vim at the end of the day is a terminal application and when it comes to debugging objectively it does not live up to the graphical interface of a proper IDE. Emacs is only slightly better in that regard, it's a GUI application but the age shows as well.
I don't think it's an accident that a lot of vim users are obsessive print-debuggers and that's just a plain handicap coming from living in a terminal. From just observing a lot of developers work I would say not knowing how to fully utilize debuggers and the modern interfaces we have for them is the number one productivity killer.
Vim at the end of the day is a terminal application and when it comes to debugging objectively it does not live up to the graphical interface of a proper IDE. Emacs is only slightly better in that regard, it's a GUI application but the age shows as well.
I don't think it's an accident that a lot of vim users are obsessive print-debuggers and that's just a plain handicap coming from living in a terminal. From just observing a lot of developers work I would say not knowing how to fully utilize debuggers and the modern interfaces we have for them is the number one productivity killer.
Maybe a Vim expert can help me out. I’ve used Vim for a long time, but never with any plugins, and only a few lines in my .vimrc.
My problem is that the syntax highlighting, specifically for TypeScript is pretty bad. I have a regular expression (for parsing front matter) that seems to cause Vim’s syntax highlighting to go haywire (it stops and sometimes crashes).
Is anyone aware of a way to get more reliable syntax highlighting in Vim, ideally with a minimum of fuss?
My problem is that the syntax highlighting, specifically for TypeScript is pretty bad. I have a regular expression (for parsing front matter) that seems to cause Vim’s syntax highlighting to go haywire (it stops and sometimes crashes).
Is anyone aware of a way to get more reliable syntax highlighting in Vim, ideally with a minimum of fuss?
using lsp with typescript-language-server?
most of the neovim setup scripts (lazyvim etc) get this set up automatically
most of the neovim setup scripts (lazyvim etc) get this set up automatically
An LSP seems overkill for syntax highlighting? This seems more like a treesitter thing.
(Mind you, I have no experience with TypeScript, just saying this as a general remark on what those components do.)
(Mind you, I have no experience with TypeScript, just saying this as a general remark on what those components do.)
Oh, my initial research (reading the Neovim docs) indicated that setting up Neovim would require a lot of manual configuration for getting an LSP working. I will give it another look, thanks!
Most blog posts I found seemed to assume you already had a gigantic custom config, plug-in manager, etc. I couldn’t find a “how to set up better highlighting and/or an LSP for people who know Vim but don’t know anything about configuration” guide.
Most blog posts I found seemed to assume you already had a gigantic custom config, plug-in manager, etc. I couldn’t find a “how to set up better highlighting and/or an LSP for people who know Vim but don’t know anything about configuration” guide.
Not disputing that VIM has those things, but I am telling you that I can't live in Vim based on your plugin setup. But of course, I'm glad there are good crafted ext/plugin communities on both sides so we can all can tweak it the way we like!
Huh, my experience is the other way around. The "killer" of vim is the control scheme, and evil mode ports that over very faithfully to emacs. Then you get the best of both worlds. Why would you use vim other than in very barebones environments where you cannot access your own config?
(I also don't see how tramp is an issue -- it opens up workflows I wouldn't even have access to without it!)
(I also don't see how tramp is an issue -- it opens up workflows I wouldn't even have access to without it!)
Why would I want to run an emacs layer adding more latency to my work to turn Emacs in to Vim when, as I said, I can do everything in Emacs I can do in Vim.
> (I also don't see how tramp is an issue -- it opens up workflows I wouldn't even have access to without it!)
Because it will randomly freeze and it's single threaded, it's slow, and it's also not novel. Vim can also edit files over SSH, VSCode can run itself remotely.
> (I also don't see how tramp is an issue -- it opens up workflows I wouldn't even have access to without it!)
Because it will randomly freeze and it's single threaded, it's slow, and it's also not novel. Vim can also edit files over SSH, VSCode can run itself remotely.
> I can do everything in Emacs I can do in Vim
Can you immediately jump to the source code associated with any key binding, read it, debug it, modify and reload it, etc., regardless of whether it comes from the base distribution or a plug-in?
For me that’s the killer feature of emacs.
Can you immediately jump to the source code associated with any key binding, read it, debug it, modify and reload it, etc., regardless of whether it comes from the base distribution or a plug-in?
For me that’s the killer feature of emacs.
I am in the same boat. Been working a lot with C++ recently and could not get debugging working. Threw in the towel and loaded vscode in about 2 hours had everything humming along and being productive.
I'm pretty sure I did the wrong thing and started with a setup like Spacemacs where random stuff would break and wouldn't even know where to look. Thought I can't seem to loose the muscle memory of vim bindings so evil is a must. On my next round will try dooms or centaur so I learn more under the hood. I do miss magit and helm.
I'm pretty sure I did the wrong thing and started with a setup like Spacemacs where random stuff would break and wouldn't even know where to look. Thought I can't seem to loose the muscle memory of vim bindings so evil is a must. On my next round will try dooms or centaur so I learn more under the hood. I do miss magit and helm.
> some glaring issues - tramp being a major one. It’s slow and very unreliable.
Over SSH? Did you turn on ssh connection sharing in ssh config?
> ControlMaster auto
> ControlPersist yes
> ControlPath /tmp/ssh-%u-%r@%h:%p
massive speedup when you do this, otherwise it starts a new connection for every operation.
Over SSH? Did you turn on ssh connection sharing in ssh config?
> ControlMaster auto
> ControlPersist yes
> ControlPath /tmp/ssh-%u-%r@%h:%p
massive speedup when you do this, otherwise it starts a new connection for every operation.
Tramp is fast for me as well, it did take some work though. I had to configure it to use my controlmaster options from my ~/.ssh/config, set tramp-verbose to 0, set remote-file-name-inhibit-locks to t, and finally set vc-handled-backends to just Git. I'm glad I spent the effort to make it fast though, because now it's pretty magical.
Yes, and it's not that it's just slow, it also freezes Emacs completely when it borks (and it does bork). I also found that none of the emacs terminals could correctly display my prompt and I ended up writing a bunch of bash conditionals to make my prompt dumber to work in Emacs. Just worked out of the box with Vim's :term.
A common thing people run into with Emacs is using the "shell" under the impression that it's a terminal emulator. You want "term" for a proper terminal emulator that can handle fancy terminal stuff. The "term" terminal emulator can even run TUI stuff like nano, and even vim itself!
Are you using tramp on a LAN or halfway round the world with 200ms latency and poor bandwidth?
The strength of Emacs lies in customizing it to the user's needs. A clean installation of Emacs is not representative of what Emacs can be, but the various modern configuration frameworks such as Spacemacs and Doom Emacs offer a window into their creators' visions of what Emacs can be. And from there, it's easy to slowly transform their vision into your own.
These frameworks offer good defaults that lean towards having lots of features packed in, but it's easy to take away everything you don't want. Both Spacemacs and Doom Emacs can be stripped to almost nothing, leaving you with just a standard for organizing your custom configuration.
These frameworks offer good defaults that lean towards having lots of features packed in, but it's easy to take away everything you don't want. Both Spacemacs and Doom Emacs can be stripped to almost nothing, leaving you with just a standard for organizing your custom configuration.
The tell in your message (and those in general from vim users), is insisting on treating Emacs as an editor, and comparing it primarily on that benchmark.
There are no shortage of Emacs lovers and users who will accept that vim is a better editor. You didn't need to try Emacs to gain that appreciation.
The other tell (common on HN, which has a clear selection bias), is comparing Emacs to an IDE like VS Code. Many, if not the majority, of Emacs users are not primarily using Emacs for coding.
> Vim is much more in line with the Unix philosophy.
Neither follows the Unix philosophy well. And as many people have pointed out, most of the Unix utilities are poor at following it well.[1] The amusing thing about the Unix philosophy is that when you stay within Emacs, the Emacs environment is a much better exemplar of the Unix philosophy than Unix and its tools are. It is a lot easier to compose functionalities in different Emacs packages than it is in UNIX.
I was using a Mastodon client for Emacs and wanted to render LaTeX formulae into rendered equations. I'm an average elisp coder and I got this working in under an hour by composing different Emacs packages.
There are various ChatGPT clients out there. I wanted to integrate it with my Emacs email client (notmuch). It's not a lot of work. I doubt one could integrate things into mutt as quickly/easily.
When reading an email in Mutt, how easy is it to quickly do a Web/network query on a selected text, perform analysis on the result, and display the outcome within Mutt? The analogue is fairly easy in Emacs, despite the mail tool(s) there not having any functionality to do this.
As for Mutt in general: I used it for about a decade. While it has a soft spot in my heart, there is a reason I switched to an Emacs client - before I knew anything about customizing Emacs with elisp. There were lots of gaps in Mutt that other clients out there filled. I miss nothing from Mutt, other than the color scheme.
In many of these cases, there are simply no quick, viable solutions outside of Emacs. People spend a lot of time doing these things in Emacs because it enables them to do more than they could otherwise. Imagine someone who doesn't know any programming complaining about someone else who does. To them they just see a person "wasting" all their time on another "tool".
[1] An example: https://www.johndcook.com/blog/2012/05/25/unix-doesnt-follow...
I've had the same visceral reaction when dealing with grep and find. Overly complex and bloated (albeit extremely useful).
There are no shortage of Emacs lovers and users who will accept that vim is a better editor. You didn't need to try Emacs to gain that appreciation.
The other tell (common on HN, which has a clear selection bias), is comparing Emacs to an IDE like VS Code. Many, if not the majority, of Emacs users are not primarily using Emacs for coding.
> Vim is much more in line with the Unix philosophy.
Neither follows the Unix philosophy well. And as many people have pointed out, most of the Unix utilities are poor at following it well.[1] The amusing thing about the Unix philosophy is that when you stay within Emacs, the Emacs environment is a much better exemplar of the Unix philosophy than Unix and its tools are. It is a lot easier to compose functionalities in different Emacs packages than it is in UNIX.
I was using a Mastodon client for Emacs and wanted to render LaTeX formulae into rendered equations. I'm an average elisp coder and I got this working in under an hour by composing different Emacs packages.
There are various ChatGPT clients out there. I wanted to integrate it with my Emacs email client (notmuch). It's not a lot of work. I doubt one could integrate things into mutt as quickly/easily.
When reading an email in Mutt, how easy is it to quickly do a Web/network query on a selected text, perform analysis on the result, and display the outcome within Mutt? The analogue is fairly easy in Emacs, despite the mail tool(s) there not having any functionality to do this.
As for Mutt in general: I used it for about a decade. While it has a soft spot in my heart, there is a reason I switched to an Emacs client - before I knew anything about customizing Emacs with elisp. There were lots of gaps in Mutt that other clients out there filled. I miss nothing from Mutt, other than the color scheme.
In many of these cases, there are simply no quick, viable solutions outside of Emacs. People spend a lot of time doing these things in Emacs because it enables them to do more than they could otherwise. Imagine someone who doesn't know any programming complaining about someone else who does. To them they just see a person "wasting" all their time on another "tool".
[1] An example: https://www.johndcook.com/blog/2012/05/25/unix-doesnt-follow...
I've had the same visceral reaction when dealing with grep and find. Overly complex and bloated (albeit extremely useful).
Agree. Except vim cannot be better editor as emacs can be better vim if one likes
0zemp1c(1)
"Emacs has three versions of every plugin and they’re all usually not as good as the thin vim wrapper around fzf etc"
This is a bold claim. Not that fzf isn't good, but I'd like to hear about some specific ways in which fzf is better.
This is a bold claim. Not that fzf isn't good, but I'd like to hear about some specific ways in which fzf is better.
Vim is pretty much the best of both worlds: the ease of use of vi combined with the small footprint of Emacs!
I am personnally fan of command line vi modes. readline has one (bash, gdb, and others), zsh and fish have (a better) one too.
I have remapped Caps Lock to Esc and it's never been easier to just go up and down the history with j an k and to make quick edits.
> the default cursor movement commands in most command line environments like the Postgres CLI.
and also macOS!
and also macOS!
Oh man. I'm embarrassed to say I've been using emacs for almost 40 years and it probably accounts for 80% of my screen time.
I wonder how many people know emacs predates gnu-emacs? I remember being skeptical of open source until I saw what gnu emacs could do. Then I got slightly more skeptical when I looked at the code ;-)
I wonder how many people know emacs predates gnu-emacs? I remember being skeptical of open source until I saw what gnu emacs could do. Then I got slightly more skeptical when I looked at the code ;-)
My entire software dev career was using emacs nearly 100% of the time. Originally it was on tops-20 (about 1981) and it was the TECO based emacs. (someone will correct me but I think Stallman was involved in the TECO version at MIT) Then the unix version used an abomination called mlisp. I briefly used EINE on lisp machines. Once Stallman got gnu going in earnest the first thing seemed to be emacs and elisp. I've been retired for a few years now so I don't type at emacs nearly as much. I feel crippled typing this into a text box in the default UI on a chromebook. Once I found control and meta on the keyboard it was all finger macros.
Anyway, I didn't do much customizing and never got used to vi when I was forced to use it. I don't think I liked the modefulness of vi. Yeah, emacs isn't very unix-y, but the unix-y text editor is ed. You kids get offa my lawn.
Anyway, I didn't do much customizing and never got used to vi when I was forced to use it. I don't think I liked the modefulness of vi. Yeah, emacs isn't very unix-y, but the unix-y text editor is ed. You kids get offa my lawn.
I got less enamoured of GNU when I started reading glibc. It works and it's solving for a complex set of build constraints and so on, but wow, it is not what I'd type.
Yeah. Thank god for musl.
Software people are hilarious. Wow, I sure hate using this amazingly working and workable product because I don't like what the source code looks like! I'm so glad there's an alternative that looks prettier!
Hilarious, huh? For a free software project whose literal philosophy is the freedom to read and study the source code, they sure don't make it easy. They should improve that if they don't want people to thank god for the existence of musl. Whatever understanding of libc that I've got is thanks to musl.
Your own issues comprehending the source code do not change that the source code is free to read, free to study, and free for many other things. And also quite easy to find.
Or, as the kids these days like to put it, "skill issue tbh".
Or, as the kids these days like to put it, "skill issue tbh".
So? Musl is still lightyears ahead of glibc in terms of being easy to understand. You can actually open up the git repository, find a random function definition and actually understand what it's doing. In seconds. Even the makefile is easy to understand. I was even able to understand the musl-gcc machinery and adapt it for my needs. Musl is so good it makes GNU stuff like GCC startfiles easier to understand than GNU's own documentation.
Skill issue? I have no doubt I could understand glibc if I was willing to pour enough time into that task. That's just the thing: I'm not willing. I have better things to do. Mercifully, I don't have to. Because musl exists.
Skill issue? I have no doubt I could understand glibc if I was willing to pour enough time into that task. That's just the thing: I'm not willing. I have better things to do. Mercifully, I don't have to. Because musl exists.
Never had to maintain legacy code, huh?
There's nothing legacy about glibc, except maybe that it supports legacy systems quite well.
Yeah there is.
If only there were a HN commenter that would tell us how we should think.
How many fingers do you have left?
Me? I lost a finger in the great key-binding wars of the late 80s. Like I said... if you make it to your deathbed with all 9 fingers, you're not trying hard enough.
Tell us more. What were you using before GNU?
https://dspace.mit.edu/handle/1721.1/5736
is about pre-GNU Emacs, with history of Emacs going back to the mid-1970s.
is about pre-GNU Emacs, with history of Emacs going back to the mid-1970s.
I've used emacs daily for maybe 15 years (and not as daily before that). I think I have a love/hate relationship with it. It's certainly the most customizable editor I can think of, but over time, that can be a burden. And its age means... the APIs are often not very intuitive. The terminology is often a bit strange.
I dunno. I can see why folks use VSCode.
I dunno. I can see why folks use VSCode.
I've used emacs for 25+ years. I was never into LISP; I just really liked the interface. And muscle memory goes deep.
Two months ago I switched to VSCode. The "Awesome Emacs Keymap" extension by Yuichiro Tachibana made it possible:
https://marketplace.visualstudio.com/items?itemName=tuttieee...
It's not 100% perfect, but close enough. I'm quite enjoying using VSCode now. It's fantastic having a wealth of actually user-friendly features/extensions to choose from.
VSCode is so annoyingly cluttered/blinking/animating/popup-infested by default though. There are a lot of things to disable in the default config.
Two months ago I switched to VSCode. The "Awesome Emacs Keymap" extension by Yuichiro Tachibana made it possible:
https://marketplace.visualstudio.com/items?itemName=tuttieee...
It's not 100% perfect, but close enough. I'm quite enjoying using VSCode now. It's fantastic having a wealth of actually user-friendly features/extensions to choose from.
VSCode is so annoyingly cluttered/blinking/animating/popup-infested by default though. There are a lot of things to disable in the default config.
The incremental search behavior still trips me up; it sorta works but not exactly.
Then there are a few crucial key bindings missing (like creating and closing split windows) - that seems doable without changing the core VSCode behavior.
Then there are a few crucial key bindings missing (like creating and closing split windows) - that seems doable without changing the core VSCode behavior.
I'm in the same boat - I've used it almost daily for 7ish years at this point. It's so much fun to use and customize, but there are easier options out there.
When people find out I use Emacs I always caution them against using it. It's taken me a long, long time to be productive in Emacs. VSCode, JetBrains tools, etc. don't have the same requirement and start up time to productivity.
Buying into Emacs does give you a lot though! Emacs way of splitting panels, going through buffers, going through files, always feel better than other applications for me.
When people find out I use Emacs I always caution them against using it. It's taken me a long, long time to be productive in Emacs. VSCode, JetBrains tools, etc. don't have the same requirement and start up time to productivity.
Buying into Emacs does give you a lot though! Emacs way of splitting panels, going through buffers, going through files, always feel better than other applications for me.
> Emacs way of splitting panels, going through buffers, going through files, always feel better than other applications for me.
Yes!
Some of the people who built GNU Emacs were legit UX geniuses.
Yes!
Some of the people who built GNU Emacs were legit UX geniuses.
It does. And the editor design, where almost everything of significance is just a function you can call/advise etc. from user code, makes it the most supple editor on earth. That's why I'm still there. But...
Pretty huge learning curve to adopt it.
Pretty huge learning curve to adopt it.
crabbone(1)
> As I said, I started from the point of zero experience with Lisp. I had a degree in software engineering, but I don’t feel like it has helped me in any direct sense. At most, it exposed me to different kinds and concepts of programming, but I am confident that it’s anything but a prerequisite, as also shown by the story of Protesilaos.
A reminder that back in the late 1970s, secretaries at MIT who knew nothing about programming were using Lisp to customize Multics Emacs to their liking and workflow -- and Emacs was far less convenient then than it is now!
The weird trick they used was, telling the secretaries they were just customizing their editor, not programming it!
A reminder that back in the late 1970s, secretaries at MIT who knew nothing about programming were using Lisp to customize Multics Emacs to their liking and workflow -- and Emacs was far less convenient then than it is now!
The weird trick they used was, telling the secretaries they were just customizing their editor, not programming it!
A few random Emacs thoughts...
One really nice feature of MacOS text widgets is the inclusion of basic Emacs key bindings such as C-k, C-d, C-a, etc. Brought forward from the Next days.
I used Zmacs on Lisp Machines back at MIT in the early 80's. A couple of my favorite Emacs-related acronyms are the editor EINE (Eine Is Not Emacs) and its successor ZWEI (Zwei Was EINE Initially).
I remember at one point in the late 80's using Emacs in the shell on SGI Irix workstations. No mouse support at that time for it.
Today I still use Emacs/Slime for my Common Lisp 3D graphics hacking.
One really nice feature of MacOS text widgets is the inclusion of basic Emacs key bindings such as C-k, C-d, C-a, etc. Brought forward from the Next days.
I used Zmacs on Lisp Machines back at MIT in the early 80's. A couple of my favorite Emacs-related acronyms are the editor EINE (Eine Is Not Emacs) and its successor ZWEI (Zwei Was EINE Initially).
I remember at one point in the late 80's using Emacs in the shell on SGI Irix workstations. No mouse support at that time for it.
Today I still use Emacs/Slime for my Common Lisp 3D graphics hacking.
In grad school in the 80’s I used Emacs. At home around 1984 I got my first PC running MSDOS. For years I used a commercial product that used Emacs keybindings (Epsilon) because Emacs wouldn’t run on my PC.
When I went to work at IBM I was disappointed that concerns over the Gnu license forced me to use vi for a few years, but I discovered it to be great an editor for me.
I eventually was drawn back to Emacs and now, many years later, I enjoy playing with my config file every week. There is always something new to be added.
It’s org mode and magit that make it impossible to leave Emacs. (Right now I’m experimenting with a configuration where I’ve installed the top 600 most popular add on packages at once. I’m kind of using the wisdom of crowds approach to picking packages this time. Next week it will be something else.)
When I went to work at IBM I was disappointed that concerns over the Gnu license forced me to use vi for a few years, but I discovered it to be great an editor for me.
I eventually was drawn back to Emacs and now, many years later, I enjoy playing with my config file every week. There is always something new to be added.
It’s org mode and magit that make it impossible to leave Emacs. (Right now I’m experimenting with a configuration where I’ve installed the top 600 most popular add on packages at once. I’m kind of using the wisdom of crowds approach to picking packages this time. Next week it will be something else.)
I switched from VSCode to Doom Emacs a couple of months ago.
I've been using ChatGPT (GPT-4) to help me write config (~1,000 lines of elisp code so far) and it's been very interesting/fun. I'm not going back.
I've been using ChatGPT (GPT-4) to help me write config (~1,000 lines of elisp code so far) and it's been very interesting/fun. I'm not going back.
That's interesting. I've asked Bing Chat and ChatGPT several times to write me elisp code, and not once did it work well. It often invents APIs.
I recently had GPT 3.5 write me a function for translating the number under point to an ISO timestamp. It handled whether the epoch number was milliseconds or seconds since epoch. I kinda had to iterate on it and ask it to do some things different, but it never wrote invalid code.
Hm, I've had luck with openai gpt4. I've had it make fake APIs before, but usually when I say "fooFakeApi doesn't exist" it corrects itself.
But how well does it do on elisp?
When I've informed it of fake APIs, it apologizes, and replaces it with another fake API.
Yes. It gave me quite a lot of trouble when I asked it to replace "cut -d:" with pure elisp. Eventually after a few minutes I got it to work, but during real work I probably would have just written it myself if something so simple didn't work the first time I asked.
Here's the log:
Here's the log:
ChatGPT> Replace the cut shell command with a pure elisp implementation in this code:
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-data (with-temp-buffer
(shell-command group-command (current-buffer))
(sort (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n") #'string<))))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
<shell-maker-end-of-prompt>
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-data (sort (split-string (with-output-to-string
(call-process-shell-command group-command nil standard-output))
"\n")
#'string<)))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
ChatGPT> replace group-command with and call-process-shell-command with elisp that does the same
<shell-maker-end-of-prompt>
(setq group-command "cut -d: -f1 /etc/group")
(setq group-data (sort (split-string (shell-command-to-string group-command) "\n") #'string<))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
ChatGPT> What is the elisp equivalent of: cut -d: -f1 /etc/group
<shell-maker-end-of-prompt>
The equivalent Elisp code for `cut -d: -f1 /etc/group` is:
(concat
(nth 0 (split-string (with-temp-buffer
(insert-file-contents "/etc/group")
(buffer-string))
"\n"))
":")
ChatGPT> Give me elisp I can evaluate to check that the elisp you gave is equal to the cut call
<shell-maker-end-of-prompt>
You can evaluate the following Elisp code to check that the Elisp I provided is equal to the `cut` call:
(equal
(concat
(nth 0 (split-string (with-temp-buffer
(insert-file-contents "/etc/group")
(buffer-string))
"\n"))
":")
(shell-command-to-string "cut -d: -f1 /etc/group"))
ChatGPT> It's not equal. the cut shell command gave a list of results. The elisp you gave only gives one result
<shell-maker-end-of-prompt>
I apologize for the confusion. You're right, the Elisp code I provided only returns the first entry in `/etc/group`.
Here's the updated code to get all group names from `/etc/group` file separated by a newline:
(with-temp-buffer
(insert-file-contents "/etc/group")
(let ((groups (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n")))
(mapconcat #'(lambda (group)
(car (split-string group ":")))
groups
"\n")))
When you evaluate this Elisp code, it will return all the group names separated by a newline character, as the `cut -d: -f1 /etc/group` command would.
ChatGPT> Give me elisp to check the equality of it
<shell-maker-end-of-prompt>
You can use the following Elisp code to check the equality of the two commands:
(equal
(with-temp-buffer
(insert-file-contents "/etc/group")
(let ((groups (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n")))
(mapconcat #'(lambda (group)
(car (split-string group ":")))
groups
"\n")))
(shell-command-to-string "cut -d: -f1 /etc/group"))It actually helped me create a lot of completion examples when I knew very little about completing read.
It disobeyed a bit, but here's it giving a simple example:
It disobeyed a bit, but here's it giving a simple example:
ChatGPT> Show me the simplest possible example of using completing read. Code only, no explanation
<shell-maker-end-of-prompt>
Sure, here's an example of using `completing-read` without any explanation:
```emacs-lisp
(let ((options '("apple" "banana" "cherry" "date")))
(completing-read "Choose an option: " options nil t))
```
This code defines a list of options called `options`. The `completing-read` function is then used to prompt the user to choose an option from the list. The first argument to `completing-read` is the prompt, the second argument is the list of options, and the other arguments are set to `nil` and `t` to indicate that the user can choose any option and that an exact match is not required.
ChatGPT> Instead of options let's use the list of groups on my linux system as the list for completing read
<shell-maker-end-of-prompt>
Sure, here's an example of using `completing-read` to retrieve one of the groups on your Linux system:
```emacs-lisp
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-list (split-string (shell-command-to-string group-command) "\n"))) ; split the output into a list
(completing-read "Choose a group: " group-list nil t))
```
This code uses the `shell-command-to-string` function to execute a shell command (`cut -d: -f1 /etc/group`) that lists all the group names on your system. The output of the command is then split into a list of strings using `split-string` function. Finally, the `completing-read` function is used to prompt the user to choose one of the groups from the list. The first argument is the prompt string, the second argument is the list of groups, and the other arguments are set to `nil` and `t` to indicate that the user can choose any group and that an exact match is not required.
ChatGPT> when a group is chosen print its name in the message area
<shell-maker-end-of-prompt>
Sure, here's an example of how to print the selected group name in the message area after the user makes a selection:
```emacs-lisp
(let* ((group-command "/usr/bin/cut -d: -f1 /etc/group") ; command to list the groups
(group-data (with-temp-buffer
(shell-command group-command (current-buffer))
(sort (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n") #'string<))))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
```
This code is almost the same as the previous example, but instead of just returning the selected group name from `completing-read`, it is passed as an argument to the `message` function. This will cause the selected group name to be displayed in the message area in the format "Selected group: {group name}".
ChatGPT> use cut instead of /usr/bin/cut, no explanation, code only
<shell-maker-end-of-prompt>
Sure, here it is:
```emacs-lisp
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-data (with-temp-buffer
(shell-command group-command (current-buffer))
(sort (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n") #'string<))))
(message "Selected group: %s" (completing-read "Choose a group: " group-data nil t)))
```
This code is almost the same as the previous example, but the `cut` command is used without specifying the full path to the executable.
ChatGPT> instead of printing the name to the message area search duckduckgo for that group
<shell-maker-end-of-prompt>
Sure, here's an example of how to search DuckDuckGo for the selected group name using Emacs' built-in `browse-url` function:
```emacs-lisp
(defun my-search-group (group-name)
(browse-url (format "https://duckduckgo.com/?q=%s" group-name)))
(let* ((group-command "cut -d: -f1 /etc/group") ; command to list the groups
(group-data (with-temp-buffer
(shell-command group-command (current-buffer))
(sort (split-string (buffer-substring-no-properties (point-min) (point-max)) "\n") #'string<))))
(my-search-group (completing-read "Choose a group: " group-data nil t)))
```
This code defines a new function `my-search-group` that takes a single argument (`group-name`) and sends a search query to DuckDuckGo using the `browse-url` function. The search query is generated using the `format` function, and includes the selected group name.
The rest of the code is similar to the previous example, but `my-search-group` is called with the selected group name instead of displaying it in the message area. This will cause Emacs to open the default web browser and search DuckDuckGo for the selected group name.
very cool can you share more?
My process is kind of organic.
I'll start working on a project, and if I run into something that feels wrong about the Doom Emacs default config/keybindings, I'll just open up a conversation with ChatGPT (the GPT-4 model, it's much better than 3.5).
I'll tell it that I'm using Doom Emacs, and then explain what I want, or what problem I'm having, and it will output code that I can try. It's not always correct on the first try, and sometimes I have to have a dialogue with it for a little while before it gets it right. Sometimes it struggles and begins to guess - and for those cases, I'll fall back to doing manual searches in Google, and if that fails, give up entirely and just write myself a TODO comment and keep marching forward.
It's help me set up config quickly that would've taken me a very long time to figure out.
I'll start working on a project, and if I run into something that feels wrong about the Doom Emacs default config/keybindings, I'll just open up a conversation with ChatGPT (the GPT-4 model, it's much better than 3.5).
I'll tell it that I'm using Doom Emacs, and then explain what I want, or what problem I'm having, and it will output code that I can try. It's not always correct on the first try, and sometimes I have to have a dialogue with it for a little while before it gets it right. Sometimes it struggles and begins to guess - and for those cases, I'll fall back to doing manual searches in Google, and if that fails, give up entirely and just write myself a TODO comment and keep marching forward.
It's help me set up config quickly that would've taken me a very long time to figure out.
> Poof I made my free-time disappear
- Ellis Kenyő, on being called an "elisp mage"
Haha, this is exactly what I fear if I tried to switch from Neovim to Emacs. I have a pretty bare-bones Emacs config that I started a while back, but haven't spent the time to really get it going.
- Ellis Kenyő, on being called an "elisp mage"
Haha, this is exactly what I fear if I tried to switch from Neovim to Emacs. I have a pretty bare-bones Emacs config that I started a while back, but haven't spent the time to really get it going.
Maybe Doom Emacs can win me back, I ended up preferring the vim emulation mode in Emacs, evil, over nvim but my dotfiles bitrotted over the long years
Cool post! I really don't want to know how much time I've spent configuring Emacs over the last 12 years :P The explosion of great Emacs Lisp packages over the last few years has absolutely made it difficult to avoid forever playing around with Emacs.
Have you tried any of the distributions? I have had sort of a semi-annual ritual of re-evaluating my emacs configuration. This last December I've tried Centaur out and while it's not perfect, it's not too bad. Definitely an interesting place to start from.
I’ve never used one. I’ve declared init.el bankruptcy a few times in those 12 years but I always build from vanilla Emacs- lots of use-package use though.
This website is a treasure trove of emacs config goodness. Bookmarked to come back to to explore switching from vim once again.
I love posts like this. It reminds me of having fun with computers is so rewarding. Reading a post like this reminds me of being young and diving into Vim and learning new tricks with it every day!
How did you collect such detailed statistics of your usage that's the crazy part in my opinion not that you actually switch but you have the statistics to monitor the switch!
If you've done any significant amount of contract work you get used to logging your time for multiple clients. Arguably you then grow wiser and charge per day.
I just stopped worry and succumbed to https://github.com/emacs-evil/evil.
Now I only mostly just fiddle with orgmode configs to generate nice looking HTML and PDFs.
Yeah, thanks a lot, I just lost two hours setting up and configuring EXWM.
Very cool, makes me wonder why I didn't think of this before, I've been using Emacs since forever.
Very cool, makes me wonder why I didn't think of this before, I've been using Emacs since forever.
I have used XEmacs for about a decade (1995 - 2005), to the point I still remember most stuff.
However that was only due to being in UNIX environments where IDE was a foreign word, and nothing compared to the likes of Borland offerings.
Nowadays there are plenty of IDE choices for UNIX like workloads, I don't miss Emacs, and basic VI knowledge is enough for editing configuration files on bare bones POSIX systems.
However that was only due to being in UNIX environments where IDE was a foreign word, and nothing compared to the likes of Borland offerings.
Nowadays there are plenty of IDE choices for UNIX like workloads, I don't miss Emacs, and basic VI knowledge is enough for editing configuration files on bare bones POSIX systems.
For the EMACS guru's in this thread I have a question.
How practical is EMACS for a non-programmer? My preferred environment is FreeBSD + i3WM. I'm a sysadmin, I have no programming skills so anything beyond tweaking the odd configuration file is of no interest to me.
I know that being able to write elisp is a major component of using emacs, but how usable is it without being able to write your own programs?
How practical is EMACS for a non-programmer? My preferred environment is FreeBSD + i3WM. I'm a sysadmin, I have no programming skills so anything beyond tweaking the odd configuration file is of no interest to me.
I know that being able to write elisp is a major component of using emacs, but how usable is it without being able to write your own programs?
As a sysadmin you’re probably very tech savvy, so Emacs should be very usable for you without ever learning elisp.
This video by a self professed non-programmer about using Emacs in the broader Unix ecosystem might pique your interest enough to give it a try:
https://youtu.be/qTncc2lI6OI
This video by a self professed non-programmer about using Emacs in the broader Unix ecosystem might pique your interest enough to give it a try:
https://youtu.be/qTncc2lI6OI
Thanks, that's just what I was looking for!
recently put effort into improving my emacs environment and i love it more than ever. great things that were new to me: wgrep, native compilation, rg-mode, dir-locals, straight.el. Not new to me, but lsp and magit are still fast and intuitive. After the initial push, i haven’t had to give it much thought. To be fair, yaml-mode is still the pits.
[deleted]
the .vimrc I've been using for like 7 years has 8 lines
My emacs config is zero lines.
282 hours of configuration! If we subtract the weekends from that 916 days, that's an average of about 45 mins a day fiddling with config.
I don't even want to spend 45 mins a month fiddling with config. I really don't understand Emacs people.
I don't even want to spend 45 mins a month fiddling with config. I really don't understand Emacs people.
> I don't even want to spend 45 mins a month fiddling with config. I really don't understand Emacs people.
Some people like to customize their environment to their exact specifications. Others will use whatever is available and never change it.
That is not required. Although default Emacs is pretty barebones (from a modern interface standpoint, not features) one can get a pretty good kickstart by using something like Spacemacs or Doom emacs and only sprinkling a bit of configuration here and there.
I too had a pile of config accrued over years - mostly porting features from other editors to Emacs. After adding Doom, I have just a few lines, it does all the rest.
The point is - usually on other editors you need to either wait for someone to create a "plugin" to do what you need, or you need to create a full blown plugin yourself, which is not a small task. In Emacs, it's extremely easy to create functions that will do tasks for you. And that gets addictive.
Some people like to customize their environment to their exact specifications. Others will use whatever is available and never change it.
That is not required. Although default Emacs is pretty barebones (from a modern interface standpoint, not features) one can get a pretty good kickstart by using something like Spacemacs or Doom emacs and only sprinkling a bit of configuration here and there.
I too had a pile of config accrued over years - mostly porting features from other editors to Emacs. After adding Doom, I have just a few lines, it does all the rest.
The point is - usually on other editors you need to either wait for someone to create a "plugin" to do what you need, or you need to create a full blown plugin yourself, which is not a small task. In Emacs, it's extremely easy to create functions that will do tasks for you. And that gets addictive.
>or you need to create a full blown plugin yourself, which is not a small task
That is what I thought when was motivating myself to continue diving into vim and emacs. In the end it turned out that the this this problem of "difficult extensibility" exists only in my head but not in VSCode or IntelliJ IDEA. Eventually, you can do magic on your files with sed/python/any other language in terminal and this most likely is better solution because it is editor-agnostic and good for automation.
That is what I thought when was motivating myself to continue diving into vim and emacs. In the end it turned out that the this this problem of "difficult extensibility" exists only in my head but not in VSCode or IntelliJ IDEA. Eventually, you can do magic on your files with sed/python/any other language in terminal and this most likely is better solution because it is editor-agnostic and good for automation.
> 282 hours of configuration! If we subtract the weekends from that 916 days, that's an average of about 45 mins a day
It's 0.43 hours a day, which is 26 minutes, not 45. (Hint: 0.5 hours is 30 minutes.)
It's 0.43 hours a day, which is 26 minutes, not 45. (Hint: 0.5 hours is 30 minutes.)
Superb point, I did always suspect I'm an idiot but it's useful to have it pointed out sometimes!
The whole point of emacs is that it’s not “fiddling with config”, it’s programming. Which is an activity a lot of people enjoy.
Emacs is essentially an IDE for developing emacs.
Emacs is essentially an IDE for developing emacs.
Plus, with time it becomes more like writing programs and less configuration. I write Elisp commands like I used to write shell scripts. These commands do entirely new things. I feel that can't count as mere configuration.
Yep. Just wrote this today to prettify all the tables in a Markdown file:
(while (not (eobp))
(while (not (markdown-table-at-point-p))
(forward-char 1))
(markdown-table-align)
(goto-char (markdown-table-end)))
A macro and a plugin installed with the markdown-table-align equivalent? Though you could also use this approach with emacs macros too.
In vim I wouldn’t know where to find that markdown-table-align exists nor how to write a macro (and I used vim for much longer than emacs). In emacs I just had to notice that pressing tab in markdown mode aligned tables (among other things), then press C-h k <TAB> to see what function that key invokes, jump to the code for it and start reading.
> I don't even want to spend 45 mins a month fiddling with config. I really don't understand Emacs people.
The problem is in the terminology: Config
Replace the word with programming and it will all make sense. People who write Javascript code to build custom tools for their own use are doing the exact same thing as Emacs users tweaking their config.
These days when I have time I'm writing elisp to make it easier for me to write math notes. One org roam node per concept/definition/proof. However, I'm building a graph: If a definition of a math object involves prior knowledge, I want to link to those nodes. The default org roam interface makes this a pain, so I want an interface that prompts me for the title, and lets me select dependencies one by one. It then inserts the node, with links to all those dependencies.
Where does all this code go?
In my config.
The problem is in the terminology: Config
Replace the word with programming and it will all make sense. People who write Javascript code to build custom tools for their own use are doing the exact same thing as Emacs users tweaking their config.
These days when I have time I'm writing elisp to make it easier for me to write math notes. One org roam node per concept/definition/proof. However, I'm building a graph: If a definition of a math object involves prior knowledge, I want to link to those nodes. The default org roam interface makes this a pain, so I want an interface that prompts me for the title, and lets me select dependencies one by one. It then inserts the node, with links to all those dependencies.
Where does all this code go?
In my config.
In my last 20 years of using emacs, I have spent about 45 minutes total fiddling with the config. (Before that I spent a little more time getting it set up.) Am I missing out on something?
For me, Emacs as a Lisp programming environment is just a lot fun! I was a big fan of the iPython REPL, but always struggled with reliably reloading modules when I made changes to functions and classes. With Emacs Lisp, I don't worry about any of that. Everything is so interactive and hands-on! It's easy to change and introspect the state of the system while it's running. The built-in debugger is pretty great too. It's a really nice way to work.
There's a very good reason for it. I spend about an hour every month. It sharpens your tool and pays back massively over time.
When we need to quickly debug or carry out a complex operation at work? People gather around my machine. Once you're set up with things like org-mode, magit, lsp your productivity goes up a lot.
When we need to quickly debug or carry out a complex operation at work? People gather around my machine. Once you're set up with things like org-mode, magit, lsp your productivity goes up a lot.
I have four commits to my .emacs in 2022 and eight in 2021, all fairly minor. So I guess that's about 45 minutes per year on average :)
Some guys look at a car as going from point A and B. Some guys find
they can get to B faster and more safely if they can modify the car.
Furthermore I'd say that I (presumably like most emacs users) am probably closer to 45 minutes per month, or per year, on general emacs config stuff, certainly not per day. It has still made a huge difference for me in terms of convenience and just general aesthetics.
Right, it's an extension of your life right. Some people find it fulfilling to kit out there house with exactly what they think they desire. Its just a matter of processing the stuff that makes you happy while providing _internal_ development.
[deleted]
Its a hardly a requirement, some people just enjoy doing it. You can just use someone else's config, lots to choose from.
It's part of the fun. Once you realize how much you can do within Emacs, it becomes really easy to fiddle.
That being said, I'm also one of those people that break my Emacs config often, and I have a different version on each PC I use.
Not every user is like this though! Many try to keep their setup as stable as possible.
That being said, I'm also one of those people that break my Emacs config often, and I have a different version on each PC I use.
Not every user is like this though! Many try to keep their setup as stable as possible.
I wrote a few functions for my emacs configuration. It's simply that I wanted the editor to work differently. And I could not do that in literally any other editor.
When I first started using emacs I spent 10 hours a day for many months customizing it.
That's 28k dollars to configure Emacs, if we assume 100 USD / hour...
By that argument, watching The Irishman costs 350 USD.
Odd that you chose The Irishman (2019) to evince the opportunity cost
fallacy. The toll of that schnoozer can't adequately be measured in
dollars.
Where's your mercedes?
Plus the time for writing that blog post. ;)
I'd love to give it another try, but not convinced it's a good fit for me. Love it conceptually though.
The stumbling block I usually come to is wondering how to utilize these data sets on my smartphone in an efficient and effective manner.
The stumbling block I usually come to is wondering how to utilize these data sets on my smartphone in an efficient and effective manner.
It does only work for a subset of org-mode functionality, but for TODOs and similar I find Orgzly on Android works great. I sync between my laptop and phone via Syncthing.
Wow! That's exactly what I hoped for. That's lovely looking.
I use emacs from termux frequently, even better if I use my bluetooth keyboard and hdmi out to a tv, but even though the text is small in normal mode I still prefer it to any of the fdroid emacs or org mode packages.
For those who worry about runaway configs, I highly suggest starting with sanemacs for a good minimal configuration you can start with and build from a good foundation on.
For those who worry about runaway configs, I highly suggest starting with sanemacs for a good minimal configuration you can start with and build from a good foundation on.
I find the iOS app BeOrg great for mobile access to my org mode inbox. It works well as not only a place to write quick notes but also to, say, "share to" links from Safari and other apps to create inbox entries as well to quickly capture URLs to view later.
emacs is a lot more fun if you explore xmodmap setups too.
i have control left of space, alt left of that. capslock is also alt, and is used for most alt presses.
i have control left of space, alt left of that. capslock is also alt, and is used for most alt presses.
Actually, what's the fuss about Emacs being so good? I'm a hardcore vim user to the point that I've installed Vimium for browsers, use vim on my iPad as well.
Someone please enlighten me with links, guides or just a comment as to what's in Emacs that makes it productive and special.
Someone please enlighten me with links, guides or just a comment as to what's in Emacs that makes it productive and special.
https://news.ycombinator.com/
There's a lot of non-emacs filler but it's still the best emacs e-zine
There's a lot of non-emacs filler but it's still the best emacs e-zine
I'll use Algolia and search maybe.
I don't know why I am being downvoted. Sorry if you smelled snark in my comment.
I am genuinely asking for an experiential guide/comment rather than a link to documentation.
I am genuinely asking for an experiential guide/comment rather than a link to documentation.
Plenty of google-able info to answer your question. But to wax poetic
for a moment, you may think of vim as chess and emacs as baduk. You can
learn chess quickly, and the game goes as deep as you're willing to go.
Absorbing baduk takes significantly more time, but once you get it, it's
like peering into another dimension.
> baduk
(for people who don't know it by this name: this is apparently the Korean name of the board game Go.)
(for people who don't know it by this name: this is apparently the Korean name of the board game Go.)
Start with the official Emacs Tour: https://www.gnu.org/software/emacs/tour/
Sure, this might help. If you've had experience, what's unique about Emacs for you?
You could think of Emacs as a mix between an integrated program suite (like Lotus Symphony, Ashton-Tate’s Framework or AppleWorks) and a Lisp Machine.
Like an integrated program suite, you can move from program to program (Emacs modes), copying your data around easily, and using similar (or the same) commands and user interface for every program/mode, making data manipulation in many ways simple and fast.
Like a Lisp Machine, Emacs is totally user programmable at every level, making both debugging easy when/if something breaks, and extensible with your own programs, ranging from simple keybindings, or macros, to full major modes. (Most major modes in Emacs started out as a single person’s personal customizations.)
Like an integrated program suite, you can move from program to program (Emacs modes), copying your data around easily, and using similar (or the same) commands and user interface for every program/mode, making data manipulation in many ways simple and fast.
Like a Lisp Machine, Emacs is totally user programmable at every level, making both debugging easy when/if something breaks, and extensible with your own programs, ranging from simple keybindings, or macros, to full major modes. (Most major modes in Emacs started out as a single person’s personal customizations.)
> Like a Lisp Machine, Emacs is totally user programmable at every level
It's just that the levels of GNU Emacs don't get as low-level as the Lisp operating system of Lisp Machine (which is an actual computer with its operating system, and not an programmable editor written on top of operating systems, which were written in C and a bunch of other languages). The levels of a Lisp Machines go all the way down to (for example) the network stack and the actual instructions interfacing with the hardware. GNU Emacs usually re-packages the underlying OS services (I/O, file system, GUI, ...) with a Lisp-based API and one programs with that.
It's just that the levels of GNU Emacs don't get as low-level as the Lisp operating system of Lisp Machine (which is an actual computer with its operating system, and not an programmable editor written on top of operating systems, which were written in C and a bunch of other languages). The levels of a Lisp Machines go all the way down to (for example) the network stack and the actual instructions interfacing with the hardware. GNU Emacs usually re-packages the underlying OS services (I/O, file system, GUI, ...) with a Lisp-based API and one programs with that.
Well, yes, because GNU Emacs runs on Unix-compatible systems, and Emacs uses the Unix API to do its thing. For instance, Emacs does not implement TCP itself, it uses the Unix TCP/IP stack.
It also on Linux/UNIX does not create a directory listing itself, but calls an external program, provided by the operating system: ls. Where on a Lisp Machine it calls the Lisp function FS:DIRECTORY-LIST, which underneath is implemented in Lisp via its object system.
On a Unix-compatible system, ls(1) is the highest-level interface to get a directory listing. There is no good reason for Emacs to use scandir(3) (or even opendir(3)/readdir(3)).
GNU Emacs has complex code to deal with it. Some "ls" programs support a "-dired" option, some not. If this option is not supported, then Dired may fail to parse some unusual filenames. Then there is an 'ls' emulation in Emacs Lisp, which by default is not used on UNIX, but on Windows...
There is a huge machinery with lots of complexity to deal with listing directories, either with ls, a GNU provided ls, or by providing a complex emulation of ls.
There is a huge machinery with lots of complexity to deal with listing directories, either with ls, a GNU provided ls, or by providing a complex emulation of ls.
I like the idea of emacs, but I notice its warmest advocates often make excuses for its slowness. If an editor doesn’t respond instantly I don’t want to use it.
Well it really depends on what operations you expect to be instant. Basic editing like movement, inserting, etc is instant, but summing from 1 to 100000000000000000000000 is where elisp would show its poor performance.
People talk about its slowness, but I've got mine pretty damn kitted out and it's still faster than VSCode, VStudio, and JetBrains products. It's not as fast as vim, I'll admit, though.
I'm an emacs fan but there's no excuse. It's insane that an editor from the 1970's is perceptibly laggy on the latest Macbook Pro.
This is a good article about the problem https://discourse.doomemacs.org/t/why-is-emacs-doom-slow/83/...
This is a good article about the problem https://discourse.doomemacs.org/t/why-is-emacs-doom-slow/83/...
It's still single threaded.
This is basically why I don't use intellij.
Work pays for everything, I just dont want to wait 10 minutes for an environment to change.
Work pays for everything, I just dont want to wait 10 minutes for an environment to change.
I use Goland at work - which is intellij. Switching between project environments is about 2 seconds. Cold start is about 5 seconds.
Use a vanilla config (i.e. no config), and it's pretty fast.
Why do people still use emacs and vim in this age of VS code and intellij?
I’ve heard plenty of arguments, but they kind of suck to be honest. They’re more like rationalizations for why they stick to what they know.
I just don’t get it. Why use inferior tools?
Both are lighter weight. Big deal, buy a faster computer. It’s nothing compared to your salary.
Both may let you type slightly faster and move around faster. Maybe. But that’s not the bottleneck anyway.
Why? Am I missing something or is it just an irrational attachment to software they learned long ago and prefer to stick with rather than learn something new?
I’ve heard plenty of arguments, but they kind of suck to be honest. They’re more like rationalizations for why they stick to what they know.
I just don’t get it. Why use inferior tools?
Both are lighter weight. Big deal, buy a faster computer. It’s nothing compared to your salary.
Both may let you type slightly faster and move around faster. Maybe. But that’s not the bottleneck anyway.
Why? Am I missing something or is it just an irrational attachment to software they learned long ago and prefer to stick with rather than learn something new?
I think I would rephrase this question as why would I stop using emacs for VS code and intellij? Seriously, there is no feature they have that my emacs config doesn't (AFAICT after using Intellij and VS code each for 4+ years). But I have the ability to work with emacs without ever touching my mouse. You may consider that only being "slightly" faster, but every time I use VS code, _feel_ slow because I know how fast I would have been in emacs.
Combine this with my tiling window manager and I pretty much only have to use my mouse to interact with web browsers. That's the killer feature that makes VS Code and Intellij _feel_ inferior to me.
Now I wouldn't go so far as to say that VSCode and Intellij are _actually_ inferior to Emacs. I think both are great in their own right, but after years of familiarity I have a fluency with Emacs (because of the keyboard oriented interface) that I could never have with them.
To be fair, for someone without emacs fluency I would probably steer them towards VSCode and Intellij as they are definitely more approachable. In fact, I have done exactly that for several of my friends and colleagues.
Combine this with my tiling window manager and I pretty much only have to use my mouse to interact with web browsers. That's the killer feature that makes VS Code and Intellij _feel_ inferior to me.
Now I wouldn't go so far as to say that VSCode and Intellij are _actually_ inferior to Emacs. I think both are great in their own right, but after years of familiarity I have a fluency with Emacs (because of the keyboard oriented interface) that I could never have with them.
To be fair, for someone without emacs fluency I would probably steer them towards VSCode and Intellij as they are definitely more approachable. In fact, I have done exactly that for several of my friends and colleagues.
The no mouse thing is one of the best arguments I've heard. I'm not convinced it makes it worthwhile, but I'm willing to grant it's possible.
I don't think the fact that Vim and Emacs were created a long time ago makes them inferior.
They keep developing and they are up to date with many/all programming-features. There are bunch of extensions that VScode just doesn't have despite it's huge extension store.
Also the main thing for me about these editors and especially Emacs is that you can program it. Not just configure it but actually program and do anything with it. You can hook into any piece of the code and change it. You can read the source code of any "extension" and patch it on the fly. I don't think I'm aware of any other editors that allow that.
It's huge power.
They keep developing and they are up to date with many/all programming-features. There are bunch of extensions that VScode just doesn't have despite it's huge extension store.
Also the main thing for me about these editors and especially Emacs is that you can program it. Not just configure it but actually program and do anything with it. You can hook into any piece of the code and change it. You can read the source code of any "extension" and patch it on the fly. I don't think I'm aware of any other editors that allow that.
It's huge power.
To be clear, I'm not saying the problem is they were created long ago.
I'm saying (from my pov, which may be wrong) that they don't seem to have as good of an IDE experience. Certainly the out-of-the-box experience with emacs/vim is much worse. And the learning investment is pretty steep. But even if you configure everything as an expert would, the experience still seems lacking to me.
I'm saying (from my pov, which may be wrong) that they don't seem to have as good of an IDE experience. Certainly the out-of-the-box experience with emacs/vim is much worse. And the learning investment is pretty steep. But even if you configure everything as an expert would, the experience still seems lacking to me.
Things you can do inside emacs (and have all this be tightly integrated so you can copy and edit data seamlessly from one "application" to another, without leaving your editor):
- browse the web
- read/send/edit email, RSS news, usenet
- chat on IRC and other chat networks/protocols
- use org-mode to edit notes in an outline format with hyperlinks, executable code blocks, a spreadsheet, etc
- use magit, one of the most powerful git interfaces
- read and edit PDFs and LaTeX with visual LaTeX symbol substitution right in the editor
- program and configure the editor in elisp, with a whole elisp ecosystem used for every plugin (this alone would make me switch away from any other editor to emacs)
- use thousands of other scripts and plugins that are the result of 50 years of development
- absolutely everything customizable to the nth degree, as emacs is more of an editor construction kit than a mere editor
- browse the web
- read/send/edit email, RSS news, usenet
- chat on IRC and other chat networks/protocols
- use org-mode to edit notes in an outline format with hyperlinks, executable code blocks, a spreadsheet, etc
- use magit, one of the most powerful git interfaces
- read and edit PDFs and LaTeX with visual LaTeX symbol substitution right in the editor
- program and configure the editor in elisp, with a whole elisp ecosystem used for every plugin (this alone would make me switch away from any other editor to emacs)
- use thousands of other scripts and plugins that are the result of 50 years of development
- absolutely everything customizable to the nth degree, as emacs is more of an editor construction kit than a mere editor
Why waste time learning about some fad IDE that will get replaced by something ‘better’ in five years? Newer text editors don’t do anything better than Vim, and they are strictly worse when it comes to their primary function: editing text.
‘You can install a vi emulator.’ - Waste of time. I already have vim.
My vimrc file still works. New machine? Just install vim and copy my vimrc over.
Emacs is a totally different experience. Emacs is essentially the interface side of an operating system. There is really no replacement for it except a UNIX command-line with a bunch of CLI tools for things like news and email that people have forgotten about.
‘You can install a vi emulator.’ - Waste of time. I already have vim.
My vimrc file still works. New machine? Just install vim and copy my vimrc over.
Emacs is a totally different experience. Emacs is essentially the interface side of an operating system. There is really no replacement for it except a UNIX command-line with a bunch of CLI tools for things like news and email that people have forgotten about.
You seem to be missing that they're not actually inferior tools. I can't think of a single thing that can't be done at least approximately as easily with emacs than with VSCode and the like.
Are they really? Do you get all the same plugins, all the lints and hover info, refactoring, jump to usages/definition, smart auto complete, etc?
They seem awfully limited to me by comparison.
They seem awfully limited to me by comparison.
Yes.
https://github.com/neoclide/coc.nvim
Or
https://github.com/neovim/nvim-lspconfig
https://github.com/hrsh7th/nvim-cmp
No different than installing plugins in VSCode for completions, they all work via calling out to a LSP server using https://microsoft.github.io/language-server-protocol/
When you don't understand something it's only natural to be unaware of its capabilities, yes.
https://github.com/neoclide/coc.nvim
Or
https://github.com/neovim/nvim-lspconfig
https://github.com/hrsh7th/nvim-cmp
No different than installing plugins in VSCode for completions, they all work via calling out to a LSP server using https://microsoft.github.io/language-server-protocol/
When you don't understand something it's only natural to be unaware of its capabilities, yes.
> They seem awfully limited to me by comparison.
Can you list your most important feature(s) in chosen your ide or editor that you suspect emacs doesn't have or can't easily have?
Can you list your most important feature(s) in chosen your ide or editor that you suspect emacs doesn't have or can't easily have?
How about the intellij inspections? It's a ton of lints that underline bits of your code as you type, with a wavy line, and you can hover over it to see what the problem is, and even potentially fix it automatically. Is there anything like that in the emacs world?
Yep. You can use flymake or flycheck for that in combination with eglot or lsp-mode.
See https://github.com/joaotavora/eglot#diagnostics
See https://github.com/joaotavora/eglot#diagnostics
The ESS package (“Emacs Speaks Statistics”) does something like that for R without using a language server.
`lsp-ui` does it for Rust at the very least but probably for other languages too.
`lsp-ui` does it for Rust at the very least but probably for other languages too.
The argument for vi is easily made. UNIX devs are constantly diving in
and out of directories, grepping, awking, and otherwise spot checking
code at the shell prompt. A terminal-based editor emulsifies coding and
such command line activities. The argument for emacs is less easily
made, and its dwindling market share evidences that. If you're a black
belt in elisp like I am, all other editors seem unusable. But you're
right. If I hadn't already spent years mastering emacs, I'd likely not
give emacs so much as a look.
That's another good argument. Once you've invested the time learning everything about emacs, that's not a barrier to using it anymore, it actually kind of locks you in, since you won't have that level of familiarity in VS code or intellij (and anyway, they're not as friendly to modify.)
How do you know Emacs is inferior? How much time have you spent using it?
How are you sure VSCode and IntelliJ will be around in 10 years? 20 years? Why invest in learning a new tool every couple of years? How do I know MS doesn't suddenly kill VSC?
Also, why would I want to use an editor which calls home every few minutes? How can I be sure VSCode does not send my password files etc. to MS or OpenAI or whatever?
Also, Emacs extensibility and flexibility is unparalleled. I can mold it to fit _my_ workflow instead of molding myself to fit the workflow of some guys at MicroSoft.
Also, Emacs is self-documenting and has ridiculous introspection capabilities. My favorite example: do VSCode/IntelliJ have a counterpart of `view-lossage` (https://www.gnu.org/software/emacs/manual/html_node/emacs/Mi...)?
Also, the fact that Emacs is so keyboard-oriented (as others have mentioned) is not really about _objective speed_, but _subjective feeling of friction_ (and lack thereof).
Also, working with Emacs is so much fun. It's a piece of software so helpful that it almost feels like an A.I. assistant. ;-)
So, plenty of reasons for me.
How are you sure VSCode and IntelliJ will be around in 10 years? 20 years? Why invest in learning a new tool every couple of years? How do I know MS doesn't suddenly kill VSC?
Also, why would I want to use an editor which calls home every few minutes? How can I be sure VSCode does not send my password files etc. to MS or OpenAI or whatever?
Also, Emacs extensibility and flexibility is unparalleled. I can mold it to fit _my_ workflow instead of molding myself to fit the workflow of some guys at MicroSoft.
Also, Emacs is self-documenting and has ridiculous introspection capabilities. My favorite example: do VSCode/IntelliJ have a counterpart of `view-lossage` (https://www.gnu.org/software/emacs/manual/html_node/emacs/Mi...)?
Also, the fact that Emacs is so keyboard-oriented (as others have mentioned) is not really about _objective speed_, but _subjective feeling of friction_ (and lack thereof).
Also, working with Emacs is so much fun. It's a piece of software so helpful that it almost feels like an A.I. assistant. ;-)
So, plenty of reasons for me.
Emacs is not about being lightweight or faster to type with, this seems to be a misconception that stems from it being compared with Vim. Emacs is not a modal editor, it works just like your standard text editor as far as typing and navigation go.
As for the other things, Emacs has support for many more languages than VSCode or Intellij. An example of this, is support for (g)awk, or non-posix shell scripts, lots of lisps, jq, various config file formats, and other things that aren't "hot" right now.
There are other reasons too, like Emacs being a true FOSS project, which is important to me. There are lots of other things, these are just a few ottomh.
As for the other things, Emacs has support for many more languages than VSCode or Intellij. An example of this, is support for (g)awk, or non-posix shell scripts, lots of lisps, jq, various config file formats, and other things that aren't "hot" right now.
There are other reasons too, like Emacs being a true FOSS project, which is important to me. There are lots of other things, these are just a few ottomh.