Live data from Hacker News

Toward a “modern” Emacs

lwn.net

191–200 of 539 posts

Re: Toward a “modern” Emacs

#191

Earlier quoted context omitted.

In Emacs, you can configure literally anything, including the keybindings . Some people use Emacs with Vim keybindings (Evil, Spacemacs, Doom). Now, for me, typical Emacs keybindings, of which the majority is defined in 3rd party packages are very logical, while Vim's are not. But the users who prefer the Vim way did they work and configured Emacs however they liked. OTOH, of the million people who complain and ask f…

Probably because having the default be something other than what a user is used to is not going to compel them towards doing the research to fix it. In order to get cua-mode working in emacs, you first have to know that it exists. I didn't know it existed for like two years of daily emacs usage, I just can't find it in myself to expect someone to know about it after 10 minutes. By the time you know it exists, you've…

This is _very_ surprising. CUA mode is called out as the fifth item in the options menu, and the menu description itself describes what it offers.

"Use CUA Keys (Cut/Paste with C-x/C-c/C-v)"

It doesn't require any knowledge of lisp at all (contrary to the assertion in the LWN article), and you don't have to know it exists, at least not any more than any other option in a menu requires that.

Re: Toward a “modern” Emacs

#192
post #26

Earlier quoted context omitted.

I suppose rms can't understand why anybody would think anything could be better than what he chose to do 40-something years ago.

A lot of things are different without being better. Before ctrl-x/Ctrl-v became the standard for Cut/paste, it was Ctrl-del/Ctrl-insert in many dos and early Windows editors - which makes a lot more mnemonic sense. It’s better to standardize on something, but that something isn’t necessarily better and is often worse.

Ctrl+Ins for copy, Shift+Del for cut and Shift+Ins for paste. Still works in Windows. Ctrl+Del deletes a word.

DOS editors often used WordStar bindings. C-k C-b to start a block, C-k C-c to copy or C-k C-v to move. Turbo Pascal used these bindings. They're also the default bindings for the `joe` editor.

Re: Toward a “modern” Emacs

#193
post #183

I’ve recently switched to VS Code, and the driving issue for me was really related to the popularity of the editor. Some combination of the LSP server and the chain of emacs packages to interface with that server were constantly broken. I can’t blame the maintainers, seeing as the LSP was being implemented by a skeleton crew and the various emacs packages were abandoned short of a couple heroes fixing some of the big…

I _highly_ recommend emacs-libvterm. Without a doubt, it's an advanced install, so I'm not arguing its better for beginners, but I adore it just the same.

https://github.com/akermu/emacs-libvterm

Re: Toward a “modern” Emacs

#194

Earlier quoted context omitted.

What are some of the changes you would want to see?

I think adopting cua-mode as the default would go a long way towards reducing the initial friction for new users. Most of the time when I try to get people to adopt emacs, they abandon it because it feels like a huge task to relearn basic text manipulation. They never get to actually see what makes emacs good because they don't feel compelled to get past the initial bump.

Have you tried with a init.el with cua-mode to see how people adopt it? My intuition is incentivizing on org-mode or magit has higher chance of adoption than cua-mode. After all an alternative free editor(VSCode/notepad) is probably good enough for their current usage.

Re: Toward a “modern” Emacs

#195
post #39

I've been an emacs user for more than 20 years. Is it just me, or is this article completely missing the point? I've switched to VS Code because I can install extensions so easily. Getting a theme installed is not my concern at all. With emacs, I'm still never sure how to get elpa (or why not melpa) to work correctly. And, modern packages for react never seem to be available there anyway. I'm still astounded package…

use-package has basically solved the package management problem for me in Emacs.

To add packages, but to remove them...

Re: Toward a “modern” Emacs

#196
post #101
post #25

Earlier quoted context omitted.

> Emacs is in that disastrous stage of a product's life where the geezers destroy their own community by refusing to adapt to new expected behavior It doesn't look like your an Emacs user. As another commenter pointed out (as did the article indirectly), Emacs has more users than ever. It's definitely growing - not dwindling. As an Emacs user, the last decade has shown an immense growth in capabilities via MELPA pack…

I don't really buy the argument I'm afraid. I've been an Emacs user for over 20 years. I like it, and find it productive. But it's stuck in a rut, in a very similar manner to Perl 5. If that isn't addressed, it will fade into the background. I'd argue that's already happened. None of my coworkers in any of the jobs I've worked in have used it, and that includes academia and various industries. It seems to be restrict…

>The keybindings need to be fixed. CUA has been the norm for what, 35 years at this point.

M-x cua-mode

Oh, and you're welcome.

Re: Toward a “modern” Emacs

#197
post #131

Earlier quoted context omitted.

I think I still have the .emacs file I inherited from an upperclassman. It had better syntax highlighting than what was built in at the time =)

See, this is what I hate about emacs. It feels like a spring loaded bundle of magic that will explode if I look at it wrong, and, having exploded, I will never ever ever get it put back the way it was.

Or you can learn about the magic and wield it.

Re: Toward a “modern” Emacs

#198
I used Emacs as my exclusive DE when I was started programming (can't argue with free) but as I started coding professionally branched out to other IDEs; however, I am back to developing with Emacs 100% of my time. A rough history of editors would be:

* VisualBasic (HS)

* Emacs/R

* Spyder

* PowerBuilder/Emacs

* PyCharm

* SublimeText

* Visual Studio Code

* Emacs (but now full time)

Even when I wasn't using Emacs for the bulk of my development work, I still preferred it as my terminal editor of choice and fter having to configure Emacs from scratch several times, I finally decided to spend some time to try and make my Emacs config portable:

> https://gitlab.com/gshulegaard/my-emacs

My takeaway from doing that was both positive and negative. On one hand, Emacs is extremely customizable and it was pretty rewarding to get my set-up just right to fit my needs. On the other hand, it is extraordinarily time-intensive to do so. Even as a reasonably seasoned developer with almost a decade of experience _using_ Emacs, installing extensions and configuring them to work together is a pretty off-putting task.

For example, even before installing an extension you first have to answer, where do I want to download it from? To which there isn't an obvious answer. My personal config actually configures 4 separate package archives:

> https://gitlab.com/gshulegaard/my-emacs/-/blob/master/src/cu...

Once you have an extension installed, there can often be additional steps or dependencies which have to additionally be managed. Which I get; Emacs is not a IDE, it's an extensible text editor so it probably shouldn't try to be more than that. But if the goal is improving usage then I think improving extension management (and by extension configuration) should be the top of the list.

In my opinion, suggesting changing default key-bindings, right-click behavior, or theme are just dancing around the elephant in the room which is: The world has moved on from plain text editors and Emacs is just not as approachable as IDE counterparts.

Honestly, this might be fine! Even when using an IDE for development work I still reach for Emacs when doing terminal text editing or want to manage multiple shell buffers from a single SSH session. But if we want to have a discussion where the context is waning Emacs usage is a problem, I can't help but feel we have to start with extension and configuration management. It's hard to justify spending the time required to install and configure Emacs with extensions when there are alternative tools that require almost no additional components or offer nearly one-click installation processes (e.g. SublimeText and Visual Studio Code).

Re: Toward a “modern” Emacs

#199
post #41
post #25

Earlier quoted context omitted.

> Emacs is in that disastrous stage of a product's life where the geezers destroy their own community by refusing to adapt to new expected behavior It doesn't look like your an Emacs user. As another commenter pointed out (as did the article indirectly), Emacs has more users than ever. It's definitely growing - not dwindling. As an Emacs user, the last decade has shown an immense growth in capabilities via MELPA pack…

> Emacs has more users than ever. It's definitely growing - not dwindling. Growing in terms of the number of users, dwindling in terms of the share among editors

>Growing in terms of the number of users, dwindling in terms of the share among editors

That's as may be. Just because something has a high market share doesn't mean it's the best product.

Chrome is by far the most "popular" browser by market share, and that doesn't stop it from doing all kinds of stuff that benefits Google over users -- often to the detriment of those users.

Re: Toward a “modern” Emacs

#200
post #101
post #25

Earlier quoted context omitted.

> Emacs is in that disastrous stage of a product's life where the geezers destroy their own community by refusing to adapt to new expected behavior It doesn't look like your an Emacs user. As another commenter pointed out (as did the article indirectly), Emacs has more users than ever. It's definitely growing - not dwindling. As an Emacs user, the last decade has shown an immense growth in capabilities via MELPA pack…

I don't really buy the argument I'm afraid. I've been an Emacs user for over 20 years. I like it, and find it productive. But it's stuck in a rut, in a very similar manner to Perl 5. If that isn't addressed, it will fade into the background. I'd argue that's already happened. None of my coworkers in any of the jobs I've worked in have used it, and that includes academia and various industries. It seems to be restrict…

The CUA issue seems frivolous, since retention among those who don't even do the built-in tutorial on the splash page was never going to be high. It might help somewhat, but the bigger issue with emacs is the association with spacemacs (vi), lisp, and "configurability", which attracts some but perhaps leads many more to disregard emacs as Kool-Aid and never even try it. The reason to use emacs is that the text-editing is superior. magit, org-mode, email, and so on having an unified interface is great, but the text-editing (navigation, mark and region, macros, rectangles, and more) is what I miss acutely when using anything else, and it's also the reason why the rest of emacs exists.
Post reply on HN