Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Even more batteries included with Emacs

karthinks.com

Post reply on HN
Print view View original

131–139 of 139 posts

Re: Even more batteries included with Emacs

#131

Post by iLemming »

royal__ wrote: post #123
iLemming wrote: post #98

Earlier quoted context omitted.

> what's wrong with the Neovim ecosystem Nothing's wrong with it. It's just incomparable categorically. Just like you can't really equate a photo-editor and the web-browser. Sure, there's a way to do photo editing in the browser, still will be weird to compare them. > Neovim has been much better In what sense? Emacs is a Lisp interpreter with a text editor embedded in it - one can fully emulate Neovim features in it,…

That all makes sense. I wasn't trying to attack Emacs or defend Neovim, for the record. I liked Emacs and didn't have any problems with it (except some window jankiness). I was mostly just curious about the ecosystem. The big reason I switched is because a lot of the big features of Emacs (org mode, magit, "living" in Emacs, advanced text manipulation, the extreme extensibility of the software) were things that sound…

Missing the point - it's not about "attacking/defending" - Emacs and Vim just can't be compared categorically, the core of their design is about two dissimilar, unrelated concepts. Vim's augmentation of modality is absolutely brilliant, beautiful model, enormously practical idea. Emacs rooted in another incredible, powerful idea - practical symbolic notation for lambda calculus. Comparing them plainly from their "text editor" aspect is wrong - it creates wrong perception of they are about.

It's almost invariably about the trade-offs, without knowing what they are and how to navigate them would remain a highly debatable topic.

You have fixated on a single (albeit voluminous) aspect of things to make a choice. But there are dozens of other things we can drop there and steer away from Emacs with wrong conclusions, e.g. Emacs has mail client capabilities, and for anyone unfamiliar with Lisp, it might be obvious - more specialized email apps would look far more capable. But for an experienced Lisper, no specialized app would ever suffice. Particularly because Lisp allows them to adapt things with extreme precision, specifically for their use cases.

> The big reason I switched

You have switched (as it seems) without even understanding what it was about. It's not about Org, Magit, or any other "features" of Emacs. The main idea is and always was the Lisp interpreter. For someone like me (staunch Lisper) Magit is not some "packaged", ready-to-use piece of software, it's a set of libraries I can use. I can easily incorporate just about any Magit function into my workflow directly. I don't have to submit patches, I don't have to ask anyone's permission, I don't have to guess - the source code is given, I don't even have to save my experiments anywhere - I can just start typing Elisp code in my scratch buffer and eval things in place. Similarly - I use Org-mode for a bunch of things that may sound absolutely unrelated - I consume HN, Reddit, Jira, GitHub, Slack and other content in org-mode derived buffers. Why? Again, because of bunch of APIs, functions and commands that Org provides. I can for example easily retrieve any HN thread and extract all the URLs people posted in comments, and inspect each in-place - takes me a keystroke. Or I can send the text to an LLM - without ever copying and pasting, without context switching, without losing focus. No other [popular] piece of software ever granted me such enormous power and liberation.

I am absolutely so grateful to my younger self for forcing me to grok Emacs and Lisp, and I will never understand the sentiment and the "reasoning" of people moving away from it (after being exposed to its absolute supremacy over plain text). Realistically, there's never switching away from Emacs for me, that, unless a better Lisp engine emerges at some point. And btw. I am a die-hard Vimmer. I use vim motions everywhere - system wide. They permeate my editors/IDEs, web browsers, terminals, and yes, even Emacs. And I use Neovim as well - it works well when I need to reach for it - like I said: it's not a comparison.

Re: Even more batteries included with Emacs

#132

Post by iLemming »

tptacek wrote: post #2

I have been using Emacs since 1994 (Lucid!) and I still don't understand Dired.

I have an opposite argument - no other file manager ever worked for me and I tried and keep trying so many. And not because Dired "is so much better" or "far more capable", or "has better default keybindings", or due to my muscle memory or Stockholm syndrome, no. It's because I can always introspect every single feature of it, override any command, integrate things with any other packages.

I honestly think that we (programmers) collectively went backwards when we tried to abandon Lisp. Why aren't there [popular] apps with a built-in true Lisp REPL for file management, email, version control?

Misunderstanding (or complete incomprehension) of Lisp lead us to the mess we're in today. Some may say: "people made their choice", etc. Well, like so many times in history, majority is not always right, but quite the opposite. We spent almost 2000 years building with inferior Portland cement, which degrades in seawater within decades, instead of using techniques perfected by Romans. We keep piling the crap, making CO2 emissions even worse. And only because we lost the recipe. The Pantheon built with Roman harbor concrete that strengthens in seawater still stands. Emacs is the Pantheon of software - the monumental example of what we've lost, the shining display of continuous progress in a world of regression.

It is heartbreakingly sad because there's now an entire generation that has no clue, because they have not witnessed the decades of callback hell. They don't know anything (or wouldn't even want to know) about "Beating the Averages", Greenspun's Tenth Rule, Gabriel's "Worse Is Better" and how he was so conflicted about his own essay that he spent a decade writing rebuttals under a pseudonym.

Lisp won't ever die, but it will never regain its former supremacy. Because for humans, economic/social reasons matter more than technical merits.

Re: Even more batteries included with Emacs

#133

Post by kqr »

Steeeve wrote: post #126

Back when I was on usenet, it was a common joke that all real programmers used emacs - and at the time I was a vi guy. It took me so long to get the muscle memory to do what I needed in vi that I thought I'd never change. But sure enough, I'm a nerd, and just like when I tried to learn the Dvorak keyboard layout, I decided to spend two weeks learning emacs. Absolutely frustrating for a few days. But I've been on emac…

But you can get the best of both worlds by using Evil. That gets you Emacs-the-platform with Vim-the-editor.

Re: Even more batteries included with Emacs

#134

Post by Barrin92 »

royal__ wrote: post #19
QwenGlazer9000 wrote: post #7

All the other comments in this thread talk about emacs instability when that hasn't been the case for me. I'm on doom emacs, update once in a while, and everything mostly just works other than some color scheme weirdness I had to fix. I used to be on neovim, and that ecosystem compared to emacs feels like this image: https://i.imgflip.com/2pg2s7.jpg Some of it is the maintainer shielding us from the breaking changes,…

Can you explain more what's wrong with the Neovim ecosystem? I just switched from Doom Emacs to Neovim and my impression of Neovim has been much better. (I get that Emacs has a much more powerful backbone, I just realized that I didn't really need that power; I just want a good text editor)

>wrong with the Neovim ecosystem?

It's like a willful exercise in ignoring systems thinking. With Emacs every package tends to be designed with Emacs itself in mind, packages like consult, vertico, marginalia etc all built on Emacs' facilities improving not just the package itself but the overall experience of using Emacs, intentionally so.

The Neovim ecosystem is a bit like a dozen architects each designing a room in a house with total disregard for the layout of the house. A very common experience I had, and I never even used many plugins, was that when something was updated often something else would break. An update in the completion engine would cause some weird quirk with the lsp backend, etc.

Re: Even more batteries included with Emacs

#135

Post by kqr »

dired_fan wrote: post #114
tptacek wrote: post #2

I have been using Emacs since 1994 (Lucid!) and I still don't understand Dired.

Like you, I've been using emacs (gnu) for decades, and dired is my directory/file manipulation tool, for both linux and windows. I never see a desktop with files/folders or anything like that, it's dired for everything. For example: Just a few minutes ago, in a directory with lots of PDFs, I did: - wdired to rename pdfs to a consistent convention. Did this with the awesome multiple-cursors package, then interactively…

> dired-dwim-target

Aha! That's what's been missing in my life! Thank you.

Re: Even more batteries included with Emacs

#136

Post by simiones »

saltcured wrote: post #107
simiones wrote: post #94

Earlier quoted context omitted.

Ctrl-C in Emacs is not "terminate program", it is "start of user command", in most modes. Similarly, even in vi/vim, Ctrl-C does something completely different. So this has nothing to do with the terminal whatsoever.

It's an even more basic Unix affordance, that terminals had a key-binding that generated the interrupt signal, and programs could define useful behaviors that commenced upon receipt of interrupt. It made sense that interrupt in Emacs could get into a controlled state of receiving the next command. It's a little bit like the SAK (secure attention key) concept, as seen with Windows use of ctrl-alt-del. Edit: Ironically…

If you are running Emacs, either in the terminal or in graphical mode, pressing Ctrl+C does not generate any interrupt signal, it simply passes the C-c key to Emacs, which is just a general key bind.

Now, C-c in particular is the key stroke which non-core modes are recommended to use for their key binds (for example, sgml-mode uses C-c as a prefix for all of its commands, e.g. C-c C-f for sgml-skip-tag-forward, C-c C-b for sgml-skip-tag-backward, etc). Running `killall -SIGINT emacs` will not be interpreted as a C-c key being hit in emacs, it will just cause emacs to quit.

The same thing is true for other terminal based programs, like vi. Pressing Ctrl+C in vi does not generate an interrupt signal, it just passes this key combo to vi to do with as it pleases.

Re: Even more batteries included with Emacs

#137

Post by SoftTalker »

scoops_ wrote: post #130
SoftTalker wrote: post #117

Earlier quoted context omitted.

C-q just tells me the buffer is read-only. How does that work?

They probably mean ‘C-x C-Q’, which toggles a buffer with its read-only state. In this case it lets you edit the contents of the dired buffer (i.e directory or file names) to changing the buffer to wdired-mode, and then ‘C-x C-s’ to save the contents of the buffer, which changes the names and places the buffer back into read-only (dired-mode)

Yes, that worked! Thanks. Though it was C-c C-c to save and exit the r/w mode.

Re: Even more batteries included with Emacs

#138

Post by saltcured »

simiones wrote: post #136
saltcured wrote: post #107

Earlier quoted context omitted.

It's an even more basic Unix affordance, that terminals had a key-binding that generated the interrupt signal, and programs could define useful behaviors that commenced upon receipt of interrupt. It made sense that interrupt in Emacs could get into a controlled state of receiving the next command. It's a little bit like the SAK (secure attention key) concept, as seen with Windows use of ctrl-alt-del. Edit: Ironically…

If you are running Emacs, either in the terminal or in graphical mode, pressing Ctrl+C does not generate any interrupt signal, it simply passes the C-c key to Emacs, which is just a general key bind. Now, C-c in particular is the key stroke which non-core modes are recommended to use for their key binds (for example, sgml-mode uses C-c as a prefix for all of its commands, e.g. C-c C-f for sgml-skip-tag-forward, C-c C…

Yes, but the old ways were that the terminal interface itself was in charge of translating this keycode to a signal, based on the line discipline of the terminal. It was a consistent behavior across many apps unless they took effort to modify the current terminal line discipline, i.e. put the terminal into a raw mode. And then many apps tried to do something appropriately signal-like when they decided to handle these input characters without signals.

Re: Even more batteries included with Emacs

#139

Post by bogomog »

QwenGlazer9000 wrote: post #7

All the other comments in this thread talk about emacs instability when that hasn't been the case for me. I'm on doom emacs, update once in a while, and everything mostly just works other than some color scheme weirdness I had to fix. I used to be on neovim, and that ecosystem compared to emacs feels like this image: https://i.imgflip.com/2pg2s7.jpg Some of it is the maintainer shielding us from the breaking changes,…

20 or 25 years ago it almost never crashed. Now I might see a crash or freeze once a week or so. And slowdowns several times a day. Of course I'm running more modes now in a more customized environment. Hopefully this new version with more in it will improve the situation.
Post reply on HN