The email that made me convert to emacs

Received this email from a role-model about why I should use emacs. I thought you all would appreciate. ​ >Nice to hear from you. Doom emacs looks great! (Although I'm too much of a dinosaur to have tried it.) > >The customization you can do in VSCode, or any other environment, stands in relation to that which can do in emacs as the sounds you can coax from a referee's whistle stand in relation to the music you can play on a piano. > >But that's not the point. The point is that everything is a buffer -- EIAB. Until one has used emacs enough for that to sink in, one has not really used it, and one might as well stick with VSCode. Pick your favorite shell (bash, zsh, etc.) and make it your default shell in emacs. Then do M-x shell. Start using your new shell. Observe that it is *just another buffer*. Live with that for a while, until the profundity of it sinks in. Then accept your fate, which is to watch in pity, for the rest of your life, as your non-emacs colleagues struggle to interact with their computers. You're now a deer bounding through the woods, past coyotes chewing their own legs off from the traps they're stuck in. Unfortunately, you can never unsee that vision. Sorry! ​ I'm still using Doom because I like the evil keybindings, but maybe one of you can convince me to fully commit!

what is he smoking?

He’s smoking genius

Love Emacs; hate tool fetishes.

M-x tiger-blood

[deleted]

As far as "fully committing" goes, I've done vanilla emacs, spacemacs, and doom. I personally like the boilerplate doom takes care of, and the flexibility it still gives you. I loved spacemacs, but didn't feel like I had the same flexibility (even with writing my own layers) that I have with doom, but I honestly don't think I have a reason to go back to vanilla when I'm using doom. (A lot of what it gives you is just reasonable defaults, and extensions on things like use-package/general.el/straight.el, which you'll likely end up using with a vanilla config after using doom anyway) But I wouldn't think of it as "not fully committing" by using doom :)

But agreed (and upvoted :) ) on hating tool fetishes: if you're not liking doom, just leave. I bet you'll find it isn't so difficult once you get used to configuring things. "99% of emacs configs are weird, and the other 1% are /really/ weird", or however the saying goes. Goes without saying, but it's just about what works for you.

Can you explain why Spacemacs lacks the flexibility?

yeah, out of context that sounds more critical than I mean it. In an admittedly hand-wavey sense, doom feels more like a library and spacemacs feels more like a framework. For example: I can technically hook into spacemacs keymaps if I want to (either through editing the keymaps directly, or using the commands that I don't remember anymore) but doom just gives me a \`map!\` function. But honestly, there's such a huge spacemacs community that I still check in on their layers to see what I might be missing out on, because as far as a "community config" I still think spacemacs is way ahead. I just think some of the tooling doom provides is more obvious to use.

Thanks!

Wdym by tool fettish?

You’ll have to wait a little longer I guess!

i took it to mean, people becoming obsessed with their tools as an end-in-themselves, rather than as things to help one get stuff done. Which in my experience often leads to tribalism, sometimes of absurd levels. i love Emacs. i also love Vim. That i use them doesn't somehow make me superior; they just Work For Me. If using VSCode, or Sublime, or Notepad, or whatever, is what works best for helping someone to get the job done, then it's no skin off my nose, all power to them. (That said, it's interesting how many people who are vociferously 'anti-bloat' don't seem to use ed(1).)

Because it fundamentally alters the nature of what you can do with it. What you do with that depends on your view on the kind of problems you want to solve. Many people never grasp what this allows, and end up just using it as they would any shell in any terminal. Or put otherwise, look at all the "advanced" terminals cropping up, which try to treat the shell as if it's running in an anemic, pale copy of a buffer, and are considered the bee's knees for the crude leverage that allows.

I use the fact that a shell is a buffer to clear output of running programs like compiler/file watchers such as ghcid. I also copy paste a ton and its very low friction. How do others take advantage of M-x shell just being another buffer?

[deleted]

I decided to try VSCodium. I'd heard good things about the ecosystem and the extensibility, so I figured may as well. Some deep limitations of Emacs were giving me grief. At first I was bewildered by all the panels and drawers and menus. But I quickly found how to turn those off with the mouse, and the keybindings to toggle the ones I wanted. I installed the neovim integration plugin and once I actually got my vimrc working, the editing was flawless. I installed the closure extensions and added a package that loads a cljs file into the editor similarly to init.el. But the panels aren't buffers. The buffers are tabs. The terminal tab isn't usably a buffer. So many extensions and built-in features just don't take advantage of the theoretical power of the underlying editor. For example: man page extension. It's just a read-only text buffer with the generated man page catted out. Same as the integrated terminal. Now that's fine, that's what emacs does too. But vscode is a "real" GUI program, based on a rich document front-end (the browser, which renders html). It should be trivial to generate an html representation of the man page, and feed it straight to the app's renderer on the fly. And yet, no such extension exists. Nor any particular hack to implement it yourself. If you implement anything yourself, you make an extension. To make an extension requires jumping through hoops... Yeah, buffers (and the raw-ness of elisp) make emacs superior. It's almost tragic, but still awesome.

Turn the output to input. I consider terminal emulators an awful interface to my shell since they don't allow me to trivially mogrify the output to input. Other similar experiences include Rio command windows and Acme's win.

You can run a bunch of commands an then do M-x occur on the result.

[deleted]

https://emacsrocks.com/e16.html

Imagine if they ever discover iTerm

Agree about the superiority thing, but I absolutely use Emacs as an end to itself! I find great joy in elisp fiddling, optimizing the things that should not be optimized (see [relevant](https://xkcd.com/1205/) [xkcds](https://xkcd.com/1319/)). I've had way more fun with Emacs once I accepted it as a hobby rather than as a productivity booster. I understand that I'll never stop tweaking my config, and now I'm free of the thought that the Perfect Config™ is waiting for me and *then* I'll get productive. But maybe that's just me;)

[deleted]

I bounce between Emacs and a terminal a lot. Concrete example happened just this morning. I ran a command in a terminal. It printed some stuff and among its output was a filename that I wanted to pass as an argument to the next command I was about to run, but I needed to edit it. In zsh I was stuck selecting the path with a mouse, copy/paste, and edit the command line using zsh's "ZLE". While ZLE has a halfway descent subset of Emacs key bindings and is mostly-okay, the *difference* between it and Emacs regularly trips me up. In an Emacs shell shell buffer I would have searched up to get to the filename, selected it, yank, edit, etc. One environment where executing shell commands isn't fundamentally different from editing text. I stay with a terminal for many things a few reasons: * Many (arguably badly written) programs assume they run in a terminal without checking for termcap, so they spew garbage into a *shell* buffer. Emacs has some mitigations for this, but it is a game of whack-a-mole. * I sometimes run a command that unexpectedly spews a *lot* of output. A "real" terminal tends to deal with this better. Sometimes Emacs goes into a kind of slow death spiral, presumably trying to regex match the output. These are all probably bugs in Emacs. * The shell buffer gets regularly confused about what the shell's current directory is, which breaks things like tab completion. There are fancy mitigations for this that I haven't bothered to set up and make reliable. * The shell buffer doesn't participate in the various fancy "completion systems" that shells have these days. https://github.com/akermu/emacs-libvterm is a possible best of both worlds that I haven't tried yet.

>The shell buffer gets regularly confused about what the shell's current directory is, which breaks things like tab completion. There are fancy mitigations for this that I haven't bothered to set up and make reliable. I use the OSC escape sequence that was added in Emacs 28 and so far it proves to be a rock solid solution. >The shell buffer doesn't participate in the various fancy "completion systems" that shells have these days. This can be a pain but there are packages that solve this problem. I am not willing to search for it in my phone so you're on your own here, sorry. >In zsh I was stuck selecting the path with a mouse, copy/paste, and edit the command line using zsh's "ZLE". While ZLE has a halfway descent subset of Emacs key bindings and is mostly-okay, the difference between it and Emacs regularly trips me up The problem is not the mouse but the copy-paste that needs to happen. mouse-1 to set point, write whatever, mouse-3 to set the region and mouse-2 to send the command in works really well.

I believe one should let the magic sink in by trying it out themselves. No matter how much I say, you're not going to truly get it. Use M-x shell for a while, switch to the terminal and get insanely frustrated at the stupidly constrained UI. Line editing libraries cannot replace a two dimensional interface regardless of whoever cries.

[deleted]

The xkcds was absolutely true for me for quite a while... and I also accepted tinkering my computer as a hobby. But then eventually something unexpected will happen, it's that you'll start to get real fast at creating/fixing new tools and actually receive big productivity boosts. Admitted I didn't think that far ahead, I just keep tinkering because I want to. Another example is people talking about how fast and accurate typing won't help you to become better at programming or writing, "because you spent a lot more time thinking anyway". Well it's absolutely helped me doing typeracer, though initially it's just because I wanted to look cool :). What I realized is having my thoughts blasting on the screen as fast as possible help me think a lot faster, as I can spot mistakes a lot easier when I can see them versus when keeping them in my mind. Also, being accurate would help you focus on your flow of thought without the distraction from fixing typos. I realized many sensible online arguments that I 100% agreed with at first are actually proven wrong in the end, just because I couldn't help doing the opposite.

I don’t think there anything wrong with using evil. Emacs is much much more than it’s keybindings. And if there’s one a thing vim can do better, then why shouldn’t we incorporate it? And doom really does it perfectly

wait is it a literal buffer ? like an array of bytes?

How big is the gap between your thinking way and that of Vanilla? How big for Doom?

I’m just wondering if Vanilla would be a forcing function to actually doing my own configuring. Doom has had enough that I am fine if something is ~just right~

https://www.masteringemacs.org/article/searching-buffers-occur-mode

doom emacs is emacs. you can still be a deer in the woods. you just also are for some reason a fan of a 90's shooter game

Sorry, not sure exactly what you're asking .... Quoting the Emacs Lisp Reference Manual, [section "Buffer Type"](https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Type.html): > A buffer is an object that holds text that can be edited (see Buffers). Most buffers hold the contents of a disk file (see Files) so they can be edited, but some are used for other purposes. Most buffers are also meant to be seen by the user, and therefore displayed, at some time, in a window (see Windows). But a buffer need not be displayed in any window. Each buffer has a designated position called point (see Positions); most editing commands act on the contents of the current buffer in the neighborhood of point. At any time, one buffer is the current buffer. > > The contents of a buffer are much like a string, but buffers are not used like strings in Emacs Lisp, and the available operations are different. For example, you can insert text efficiently into an existing buffer, altering the buffer’s contents, whereas inserting text into a string requires concatenating substrings, and the result is an entirely new string object. The gory details can be found in [`buffer.h`](https://git.savannah.gnu.org/cgit/emacs.git/tree/src/buffer.h) and [`buffer.c`](https://git.savannah.gnu.org/cgit/emacs.git/tree/src/buffer.c).

Huh, that's an interesting anecdote. I will take the bonus productivity boosters by all means! My Emacs journey has barely started, I'm merely 3 years in, so I'm thrilled to see if it happens to me as well. How do you feel regarding that sudden boost? Does it take some joy from tinkering, or are you able to accept the booster without with stressing over it?

Dired is a better example. Recognizing that a file listing is just text and it can be modified the same way anything else can is huge.

Well I've also only started Emacs for around 3 years, but have been tinkering my computers for a lot longer than that, for around 15 years already. It's around over 3 years in that the boosts become significant. Since then, I spent plenty of working hours tinkering and still have more work done than most of my colleagues. In fact, I used my addiction to tinkering as a motivation. The faster and better I can finish my tasks, the more time I can spend tinkering. The tinkering would eventually help me to get faster, and now I have even more time for tinkering (LOL). The productivity boosts are basically life-changing. It to the point that I've been doing two "full time" remote jobs (only 4 hours/day :) ), take care of my children, and pursuing a research career (granted it's my own money, so time spent is very flexible), tinkering more, and still having plenty of free time. You also don't need to worry about losing the joy from tinkering, because you'll always have harder and crazier things to get into. I directly modified the code or making extensions for almost every tools/softwares I used on my computer: my window manager, bars, docks, file browser, terminal, pdf viewers, web browsers, music/video players, Emacs - I've even start tinkering with the C part of it. And I still felt like there are so much things that can be better.

[deleted]

For example, Dired lets you rename files (and edit symbolic links) using the text editing commands that are available to you in every othe buffer, since file names and links can be represented with just text. Instead of needing a shell like Bash for a complex renaming of files, I can just use `query-replace-regexp` as I would in any other buffer. Similarly, when using a shell as in `M-x shell` or `M-x ansi-term`, I don't need my shell to re-implement `vi` keybindings, I can just use Evil to edit my input. Any convenience command I write for editing text in one buffer is a command that I can also use for editing text in the shell buffer.

>I use the OSC escape sequence that was added in Emacs 28 and so far it proves to be a rock solid solution. Wanted to thank you for this recommendation. Works great, though somewhat hacky to set up. In doing so I noticed that Fedora ships their Emacs with this integration enabled, so that should help with popularizing it. I just copied their stuff and enabled the same logic when `TERM=dumb` and `INSIDE_EMACS`. Also, I think at some point something using something better than the `TERM` env var to negotiate terminal capabilities would be great.

You cannot expect anything better from Unix-likes other than a bunch of old variables. Even if we come up with something, it will take years before it gets adopted enough to be usable; I would be an old man by then...

Not being antagonistic, just wondering, how does everything's 'buffer-ness' help? I understand it's a mindset, just don't understand the mindset, I suppose.