Live data from Hacker News

Why GNU Emacs?

elephly.net

81–90 of 317 posts

Re: Why GNU Emacs?

#81
post #64

Earlier quoted context omitted.

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!

then you have to maintain/monitor that daemon, seems like too much work.

Re: Why GNU Emacs?

#82

Earlier quoted context omitted.

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!

then you have to maintain/monitor that daemon, seems like too much work.

If only someone made something that could monitor daemons and make sure they stay running...

Re: Why GNU Emacs?

#83
post #8

I enjoyed this; I moved from Vim to Emacs a couple of years ago and indeed the most important thing to recognise is this: Emacs does have a great text editor, and it's Vim! With evil-mode you can use all the Vim bindings you're used to (including sed commands with ':'), but with the added benefits (and drawbacks) of Emacs! I've also found that fiddling with my .emacs is really fun, fiddling with .vimrc was usually qu…

I tried this, but found that the issue is that most major modes use a "grammar" that make sense to native-emacs user, and ended up fighting with them.

Re: Why GNU Emacs?

#84

Earlier quoted context omitted.

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!

then you have to maintain/monitor that daemon, seems like too much work.

[deleted]

Re: Why GNU Emacs?

#85
post #36

Earlier quoted context omitted.

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.

I've heard good things about ivy, but haven't got around to revamping my config in some time. I'll check it out next time I do.

Re: Why GNU Emacs?

#86
lisp is beautiful. The crown jewels of computer science. getting to spend time with it reminds you that programming can be fun (and profound) while you are being paid to work with some awful drudgery language solving some stupid problem. Being close to lisp, in this way, is like being at the same party as Audrey Hepburn. It reminds you of grace.

Re: Why GNU Emacs?

#87
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.

I would instantly disregard anyone who says this. Just run it in daemon mode and connect with emacsclient.

Re: Why GNU Emacs?

#88

Earlier quoted context omitted.

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!

then you have to maintain/monitor that daemon, seems like too much work.

I use the GNU Shepherd init system as an unprivileged user to manage my emacs daemon, and other things like gpg-agent.

The real benefit of 'emacs --daemon', for me, isn't the faster client startup time, but the unification of the many programs that may spawn $EDITOR. Rather than each one spawning a new Emacs process, these programs spawn a client in the window I already have open where I can access everything else I was working on. On top of that, I use the ItsAllText extension for Firefox to edit text fields inside of that same Emacs instance, too. Very convenient.

Re: Why GNU Emacs?

#89
post #36

Earlier quoted context omitted.

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.

I'm on 24.5, and I don't know how it was in the past, but Emacs' default minibuffer reading functionality is good enough that Ido, Ivy, Helm or whatnot seem superfluous to me. I can type C-x C-f ~/Git/projectx/src/ding/~/.xombrero/runtime//etc/fstab RET

it will do the correct thing, and it will give visual feedback. Also I can type

  M-x rev-bu RET
and it will run revert-buffer, and if I type TAB instead of RET, it will complete to actual command name. It will ignore case in completions if these variables are set:

  ;; Ignore case when completing file names in minibuffer.
  read-file-name-completion-ignore-case t
  read-buffer-completion-ignore-case t
  completion-ignore-case t
Also an indispensable config:

  enable-recursive-minibuffers t
What does them tools provide that can't be easily done by these? And ido fails when entering a TRAMP file name, so one has to hit C-f in minibuf to drop to the original prompt.

Re: Why GNU Emacs?

#90
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.

well, that's for terminal mode. With a window manager, most application has similar start up time which I assume is caused by similar xorg routines being run.

However, running Emacs in daemon mode does reduce this to instant. Not sure why this is.

Post reply on HN