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

61–70 of 139 posts

Re: Even more batteries included with Emacs

#61

Post by tapete1 »

Paradigma11 wrote: post #28
gnulinux wrote: post #5

My 2 cents (I hope I don't offend anyone, and of course Emacs community is amazing). I've been using Emacs full-time since ~2010 but I must admit it's been more like part-time along with VSCode since ~2024. > This is largely a discoverability problem In my experience it's not a discoverability problem at all . Not even a little bit. My problem with emacs batteries has always been stability between different combinati…

LLMs are a godsend in fixing emacs problems.

I have asked LLMs several Emacs-related questions and _never_ got a reply that works. And at generating elisp code they are especially awful.

Re: Even more batteries included with Emacs

#62

Post by kqr »

jr_isidore wrote: post #58
kqr wrote: post #34

Earlier quoted context omitted.

That would be a problem if the Emacs project needed to attract new users that aren't "the kind of person to invest time in" their editor. I'm not sure it does. Emacs has a healthy user base of people like you and I and appears to receive stable funding from the FSF. I don't see that changing any time soon. Emacs can be Emacs and be just fine the way it is. I will keep suggesting new users should aim to get as close t…

appears to receive stable funding from the FSF No, about ten underemployed or semi-retired graybeards on the emacs.devel mailing list burn most of their waking hours futzing with emacs. That's not an exaggeration. They receive no remuneration.

That's sad. Is there a way I can fund them without going through FSF? I tried looking into it before but it seemed like FSF was the only alternative, so I assumed it was well-managed.

Re: Even more batteries included with Emacs

#64

Post by antiframe »

tapete1 wrote: post #61
Paradigma11 wrote: post #28

Earlier quoted context omitted.

LLMs are a godsend in fixing emacs problems.

I have asked LLMs several Emacs-related questions and _never_ got a reply that works. And at generating elisp code they are especially awful.

That is not my experience. I had Claude add a variety of useful functions to my init.el as well as refactor it for easier maintenance. I now have a more useful to use and pleasant to edit init for it.

Re: Even more batteries included with Emacs

#65

Post by antiframe »

shevy-java wrote: post #12
skydhash wrote: post #10

Earlier quoted context omitted.

Both you and the sibling common by buzzwords have the same contexte: You’re both using someone’s configuration framework, which goes bery much against the vanilla emacs’s way. Most package assumes something standard and you can expect something to break if your configuration isn’t.

> You’re both using someone’s configuration framework, which goes bery much against the vanilla emacs’s way I heard a similar argument about vim's billion configuration options. At some point I simply got tired of having to tweak it and switched to a better editor (not emacs though; both vim and emacs are losing in any debate, but it's a fun debate nonetheless since both camps think software can only be written with…

You met some odd Emacs users. Every Emacs user I have met is a strong proponent of personal computing and crafting tools that work for the individual. It's true that some have a hatred of software that removes users' freedoms but that doesn't mean they think users of freedom-restricting software are skilless.

Re: Even more batteries included with Emacs

#66

Post by SoftTalker »

tapete1 wrote: post #61
Paradigma11 wrote: post #28

Earlier quoted context omitted.

LLMs are a godsend in fixing emacs problems.

I have asked LLMs several Emacs-related questions and _never_ got a reply that works. And at generating elisp code they are especially awful.

Same. I'm not an elisp expert by any means, so I tried using claude and chatgpt to help me write some functions. They got close, close enough that I could massage what they wrote into something that did what I needed, but they have never produced anything that just worked.

Re: Even more batteries included with Emacs

#67

Post by sachac »

kqr wrote: post #62
jr_isidore wrote: post #58

Earlier quoted context omitted.

appears to receive stable funding from the FSF No, about ten underemployed or semi-retired graybeards on the emacs.devel mailing list burn most of their waking hours futzing with emacs. That's not an exaggeration. They receive no remuneration.

That's sad. Is there a way I can fund them without going through FSF? I tried looking into it before but it seemed like FSF was the only alternative, so I assumed it was well-managed.

https://github.com/tarsius/elisp-maintainers and https://github.com/freetonik/support-emacs-community-devs list quite a few people, so you can support them directly.

Re: Even more batteries included with Emacs

#68

Post by maleldil »

lycopodiopsida wrote: post #54
royal__ wrote: post #19

Earlier quoted context omitted.

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)

I think a big difference is that in the end emacs often makes a call and adopts one of the very popular packages to the core - eglot, modus-themes, use-package - there are certainly more, and more will come. It may not make everyone happy, but is sets the baseline - e.g., I am using eglot as package manager, but I wrap it into use-package commands for compatibility reasons. No such thing exist in neovim (or at least…

> emacs often makes a call and adopts one of the very popular packages to the core

> No such thing exist in neovim

neovim has been doing that too. Plugin manager (vim.pack), treesitter stuff, LSP management, completion, comments, etc.

> which-key

neovim also has this.

> neovim ecosystem is concentrated on one (very productive) developer in an unhealthy manner

folke has nice stuff, but I find a lot of it is largely unnecessary and bloated. The only thing I use is his which-key, and there are alternatives, such as mini.clue.

Re: Even more batteries included with Emacs

#69

Post by maleldil »

rjzzleep wrote: post #20
royal__ wrote: post #19

Earlier quoted context omitted.

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)

LSPs keep getting reimplemented, package managers keep getting reimplemented. It's a bit like the react version of text editors. I used it more than I use emacs, but I agree with the assessment of doom emacs vs neovim.

neovim core has most of what you need for LSPs. The only thing missing is server-specific configuration (e.g. binary name, flags), which you can copy from nvim-lspconfig or write yourself. There's also a native package manager in the core.
Post reply on HN