Live data from Hacker News

Why GNU Emacs?

elephly.net

71–80 of 317 posts

Re: Why GNU Emacs?

#71
post #64

> Sometimes people who use computers ask me why I would use something as “bloated” as Emacs for text editing. Usually they remark that Emacs is a hold-over from a by-gone era, much too large compared to editors like “vi”, and that they are quite content using a variant of vi or some Notepad-like editor. This feels like a very out of date sentiment to me. I know a decade ago this was the perception, and well know the…

I guess bloated means compared to 'instant startup'. Vi starts always instantaneously, whereas Emacs can have a noticeable delay, even if it's only a fraction of a second. Hence the perception that is bloated. Of course compared to the others you mention is quite fast.

The best way to run emacs IMO is to use "emacs --daemon" to spawn a single daemon process, and then connect to it using emacsclient. Then, startup time is instant!

Re: Why GNU Emacs?

#72
I'm a Emacs user and use it everyday. I've seen a post like this from time to time. Most of them make sense, and I indeed agree on it. But from my personal experience, I prefer Clion to write C/C++, prefer IntelliJ to write Java. I will not recommend Emacs for these coding job. A modern IDE is doing a much better job. I still love the org-mode of Emacs though.

Re: Why GNU Emacs?

#73
post #13

Nowadays the only thing I use outside of Emacs is GNOME Terminal / Google Chrome / bash / screen / ssh. All the rest (including E-Mail) is inside Emacs. The Emacs/Vim war is a bit silly, because historically they're really not comparable in that way (although vim has gotten larger). Emacs is more of an alternative to GNOME/KDE/Windows/OSX than it is an alternative text editor.

"Nowadays the only thing I use outside of Emacs is GNOME Terminal / Google Chrome / bash / screen / ssh. All the rest (including E-Mail) is inside Emacs."

There are ansi-term, shell, and eshell. The first is an actual ansi-term within your emacs, the second is a comint shell, and the third is a shell implemented in elisp. Emacs has frames, and with C-u M-x shell you can open as many new shells as you want. proced is like top/ps aux. So it's time to get rid of gnome terminal and screen :)

Re: Why GNU Emacs?

#74
post #32

Earlier quoted context omitted.

I went from Emacs to Sublime and back to Emacs. The UI could be improved, maybe, but there's a lot to be said for knowing that your editor will still exist next year. I'm frankly not confident in ST3, but I'm 100% certain that Emacs will be there. But beyond that, I find that a lot more stuff Just Works in Emacs. I spend my days working in Python, and both major Python modes for Emacs are miles ahead of ST's equivale…

The thing is, in this day and age most people don't need their editor to last 100 years. Because of https://en.wikipedia.org/wiki/IBM_Common_User_Access & friends, you can just switch to another editor. Meanwhile, if you're used to Vi's modal editing or Emacs's elisp, you're basically going to hate the other tools forever if for whatever reason. For example if you need IDE features for your project or the Vim/Emacs e…

Once you're past the basic navigation cluster + cut/copy/paste/undo/save (which tend to be more Windows-style, I'd say, than CUA!) every editor is different.

Ctrl+F for Find is a common standard, for example, but it's hit or miss whether this is Ctrl+F for Find (and that's your lot! Find & Replace is something entirely different), Ctrl+F for Find (and you have a checkbox for Replace), Ctrl+F for Find (and you have a checkbox for Replace... and this is how you search across multiple files as well). And there are multiple standards for all of these additional options. Your muscle memory will be useless no matter what you're used to. You're welcome to describe emacs as unusual... but don't assume everything else is a nirvana of UI consistency. The process of "just" switching can be a bit more inconvenient than you might think ;)

Re: Why GNU Emacs?

#76
I find it interesting that we as programmers love to base a lot of our technical decisions on hard data, but somehow the choice of editors seems immune to this. Has anyone ever done an analysis of the actual objective benefits of these editors? I got suckered into the 'religion' of vi and have spent countless hours learning it to a fairly high level of proficiency over the years. I don't think I've ever recovered all the time I spent. Maybe it requires a special use case. Most of my time is spent outside of the editor - reading specs/docs/code, debugging/tracing/analyzing existing code, or just thinking about code.

Re: Why GNU Emacs?

#77
post #36
post #20

Earlier quoted context omitted.

There's a lot of antiquated stuff in Emacs, but despite the almost total lack of a modern UI toolkit for extensions, there are also interfaces in Emacs that are better than anything available elsewhere --- reasons to launch Emacs even if you don't need its expressive power for editing. Magit is a good example, Helm is another, org-mode another, FlyCheck another. If Emacs looked as good as Sublime, I'd be marginally h…

Helm may be the most flagrant example of a terrible package that remains inexplicably popular. I haven't uninstalled it yet, because there are a few packages that use helm that don't have ido equivalents yet, but I try to minimize my usage of it as much as possible. Issues include: - Significant performance issues - Constant bugs - updates often break the package completely, especially if you're using the melpa versi…

You may be interested in checking out Ivy; it has a similar workflow to Helm but is much more lightweight. As a fan of Ido, Ivy has replaced Ido everywhere for me except for opening files.

Re: Why GNU Emacs?

#78

Earlier quoted context omitted.

I went from Emacs to Sublime and back to Emacs. The UI could be improved, maybe, but there's a lot to be said for knowing that your editor will still exist next year. I'm frankly not confident in ST3, but I'm 100% certain that Emacs will be there. But beyond that, I find that a lot more stuff Just Works in Emacs. I spend my days working in Python, and both major Python modes for Emacs are miles ahead of ST's equivale…

> The UI could be improved, maybe, but there's a lot to be said for knowing that your editor will still exist next year. I'm frankly not confident in ST3, but I'm 100% certain that Emacs will be there. This is misleading. In the era of JetBrains and its perpetual licensing and Steam and whatnot, it's worth pointing out that ST3 is a binary that you download and have complete access to, so of course it will be there n…

> it's worth pointing out that ST3 is a binary that you download and have complete access to, so of course it will be there next year

This is not "being there." Popular architectures change, as do operating systems. Unless you intend to freeze your current computing environment for posterity, a working executable means nothing.

Re: Why GNU Emacs?

#80
post #64

> Sometimes people who use computers ask me why I would use something as “bloated” as Emacs for text editing. Usually they remark that Emacs is a hold-over from a by-gone era, much too large compared to editors like “vi”, and that they are quite content using a variant of vi or some Notepad-like editor. This feels like a very out of date sentiment to me. I know a decade ago this was the perception, and well know the…

I guess bloated means compared to 'instant startup'. Vi starts always instantaneously, whereas Emacs can have a noticeable delay, even if it's only a fraction of a second. Hence the perception that is bloated. Of course compared to the others you mention is quite fast.

Running emacs like "$ emacs " is like booting a computer, editing a single text file, and then "$ shutdown -h now".
Post reply on HN