Live data from Hacker News

Why GNU Emacs?

elephly.net

121–130 of 317 posts

Re: Why GNU Emacs?

#121

Once, I used Emacs. All I did with it was play in the land of elisp. I never got any real work done. Then, a passionate friend converted me to Vim. I only ever used it to do battle with my .vimrc. I never got any real work done. Now, I use Atom. Click a button, install a feature. No more distractions. I wish it were faster though; I can never get any real work done.

The features just aren't there for me in Atom. I have a feeling they are if you're a web developer, but us non webdevs are left out in the cold (at least for now). Compare LaTeX and R in Atom to AUCTeX and ESS in Emacs and it's like night and day. Every time I switch to Atom I get frustrated within a day due to lack of features for the things I use.

Re: Why GNU Emacs?

#122
If you are a newcomer and look at Emacs what you see at first glance on the outside is basically total crap. The default behavior of Emacs distinguishes itself by the complete lack of sanity. Emacs key-bindings are neither ergonomic nor do they make any sense in any way. They are barely consistent across modes, only if you are lucky. They are the way they are because they are old. And old people don't like change. However my experience was, the more I learned the more crap appeared. One layer of crap after the other. At first everything could somehow be fixed with a lot of configuration and scripts. I needed several hundred lines of Lisp code in my init.el just to be able to work normally.

But then the lowest emacs layer of crap appears which can not be fixed. It includes issues like lack of multithreading, elisp being the least capable and at the same time by far slowest lisp dialect. Stuff like the lack of ability to move the cursor off screen. Inherent jumpiness while scrolling which can not be fixed and really strains my eyes. And don't even try to look at the C source, it is the worst historically grown ifdef hell you will ever experience.

And finally there is the community which lacks disposition to unify or work together. It is more like a community of loners where each of his own produces personal "modes" which are inconsistent to use and most of the time conflict which each other. The most important reason for this might be lisp itself. It is inherently hard to read other peoples lisp code. So everybody writes his own.

Re: Why GNU Emacs?

#123
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…

> An atrocious version of "fuzzy matching" (you have to separate terms with spaces, which are then turned into ".asterisk" (can't type a single asterisk in HN comments) and everything's concatenated into a regex to match)

That's not true. Helm doesn't just insert .asterisk, which is why it supports out of order matching. If one searches for "file rename" Helm will find rename-file, while typing "filerename" in ido it will not find it. In ido one would have to do "filerename"

> Dictatorial maintainers that only allows options and features that they deem the "right way" to do it.

Helm is already criticized by many ido fans for having too many features, now it's also criticized by ido fans for not having more (despite it having way more than ido).

> Constant bugs

This is because helm is constantly changing and improving. ido is not changing, and most extensions to it are very hacky.

I prefer ido, but helm is a good tool that's perfectly usable that tons of people like and does a lot more than ido.

Re: Why GNU Emacs?

#125
Does anyone have an opinion on Spacemacs[0]?

I haven't used it, nor Vim/Emacs. Just came across it during researching the two. Spacemacs appears to have excellent documentation though.

[0] http://spacemacs.org/

Re: Why GNU Emacs?

#126

I use both Emacs and Vim and Emacs is slow. Often I would issue commands too fast for Helm to pick it up. It has rich environment and a lot going for it, but it is slow. Excuse to have "full featured" environment does not stand because Sublime Text is very much full featured and very fast. Anyhow, while Vim is still my goto editor, Emacs has a lot going for it and I fire it up when I work on Elixir because of superio…

This entirely depends on the set of packages you configure. I was able to make vim plenty slow by running too many plugins over too many files. I made vim lightning-fast by keeping things simpler. I did both of the same to emacs.

Actually, advanced IDEs like Idea only feel fast because they do most of the stuff asynchronously. Afaict neither vim nor emacs are excessively good at it.

Re: Why GNU Emacs?

#127
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…

I think both built-in completing read and helm/ivy have their uses. ido is best for when you know what you want and want to get it to it with minimal number of keystrokes. helm seems better for when you want to review many (but not too many) options before deciding on what you want.

I find ido unusable for find-file, because of how it splits up directory from filename. So I use the builtin completion.

But I rarely open files using find-file anymore. ido-use-virtual-buffers is magical. For commonly opened files it let you use switch-to-buffer whether the file is opened or not.

  (require 'recentf)
  (recentf-mode t)
  (setq recentf-max-saved-items 200)

  (setq ido-use-virtual-buffers t)        ; include recentf files

While, something like this works better with helm:

  (require 'yari)
  (define-key ruby-mode-map [(meta h)] 'yari-helm)

Re: Why GNU Emacs?

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

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

why is that not the default behavior then?

Re: Why GNU Emacs?

#129
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…

> An atrocious version of "fuzzy matching" (you have to separate terms with spaces, which are then turned into ".asterisk" (can't type a single asterisk in HN comments) and everything's concatenated into a regex to match) That's not true. Helm doesn't just insert .asterisk, which is why it supports out of order matching. If one searches for "file rename" Helm will find rename-file, while typing "filerename" in ido it…

ido would really benefit from being spun-out as a package. People would actually fix bugs and add functionality in a reasonable way rather than hacky extensions (like ido-hacks)

Re: Why GNU Emacs?

#130
I try Emacs around once per year. The problem is it's so slow under OSX. It's much faster on my 2007 iMac running Linux than 2013 mbp. I even tried to run it under X-Quartz but still performed poorly. What can I do?
Post reply on HN