Live data from Hacker News

Why GNU Emacs?

elephly.net

61–70 of 317 posts

Re: Why GNU Emacs?

#61

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

Eight Megabytes And Constantly Swapping.

Re: Why GNU Emacs?

#62
post #15

Apparently, I'm feeling ranty today... I've used Vi and Emacs as my primary editor. Now I've moved on to Sublime Text 3. Despite being powerful tools Vi and Emacs have probably harmed the state of Unix text editing. They've kept antiquated UIs from before keyboards were an text editing UIs were standardized. It's kinda sad that MS Dos, Windows and MacOS have all had a plethora of powerful editors with convenient stan…

I'd be interested to hear more about "powerful" text editors from the DOS or Windows world. Likely your definition of "powerful" is quite peculiar.

Re: Why GNU Emacs?

#63
post #50

Earlier quoted context omitted.

I can't say that I have experienced all of these issues myself after using helm for about a year. - There certainly are performance issues with helm, but setting gc-cons-threshold to a higher value helps my setup a lot. - I update all my installed packages pretty frequently, and I just use regular melpa. I haven't really noticed bugs with Helm. - As for the fuzzy matching, look into the "helm-flx" package. It gives y…

Ah, helm-flx didn't exist when I quit helm, and flx-ido did. Question: does helm-flx sort results, or does it just throw back an unsorted list of matching entries, like normal helm? I consider the sorting an even bigger and more ridiculous drawback than the matching. I haven't used helm-M-x. That may be better - but it doesn't solve the problem that everything else using completing-read is still on normal helm. I typ…

helm-flx sorts results by the "closest" match to your typed in characters. For me, typing "tetri" has "tetris" listed first, with the next result matching all of those characters in a different command, and each of the following results being less and less accurate matches. There is no alphabetical sorting, though.

Popwin is very annoying for me, too. I'll look into trying out shackle.

There is also a less-popular completion system for emacs called ivy. I don't know how it stacks up to ido or helm, but perhaps that one is also worth checking out.

Re: Why GNU Emacs?

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

Re: Why GNU Emacs?

#65

Many Emacs advocates fall for the trap of apologizing for why Emacs is not Unixy, as though it were some sort of defect. They should celebrate the fact that Emacs doesn't come from the Unix tradition of small, composable tools and "doing only one thing and doing it well". It is rooted in the ambitious work of the MIT Artificial Intelligence lab, the LISP programming language, and the single user MIT Lisp Machine that…

Unix has a big flaw: through the pipes pass random data. It's up to the receivers to interpret it. Lisp gives you the possibility to easily structure your data and pass it around, plus the ability to pass programs around. Other than this, the unix way and the lisp way are nearly parallel, though in lisp "command line utility" is called a "procedure".

Re: Why GNU Emacs?

#66

Earlier quoted context omitted.

I won't use an IDE on OSX or windows that doesn't support VIM or Emacs key bindings because I'm not an animal that wants to take his fingers off the line to use the mouse or arrow keys every time needs to move the cursor (or run a regex real fast to mass update code). Luckily there are VIM bindings for nearly every single IDE of importance out there.

> I won't use an IDE > a regex real fast to mass update code For things like renaming, an IDE would have a function for that, which isn't text based but symbolic . At the very least, bringing up a replace diaglog with regex functionality doesn't require any more keys to be pressed in an IDE than in emacs. Most IDEs's also support key bindings that are pretty close to Emacs or vim. unless you use a dynamic language in…

You can do the same thing in Emacs too. For example, this[1] supports that for Scala (and I think Java now as well).

[1] http://ensime.github.io/

Post reply on HN