Live data from Hacker News

Why GNU Emacs?

elephly.net

41–50 of 317 posts

Re: Why GNU Emacs?

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

Yeah or you should install Atom and be spied by Google Analytics [1]. Let's take the creepiness of the web to the desktop. [1]: https://atom.io/faq

I've found VS Code a great alternative to Atom for that level of editor (fast and light). Don't tell me it does something equally as awful?

Re: Why GNU Emacs?

#42
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 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 you real fuzzy matching, much better than the default helm matching.

- I have M-x bound to helm-M-x, which is a better option than the default. Also, helm-mini is a better option for a buffer switcher.

I agree that Helm is lacking in many areas, but this guide made Helm work better for me: https://tuhdo.github.io/helm-intro.html

Re: Why GNU Emacs?

#43
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 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 which case you are shit out of luck.

Re: Why GNU Emacs?

#44
The boilerplate argument against emacs is getting kinda old, isn't it? I used vim exclusively for ~5 years up until last summer when I switched to emacs which I use in more or less the same way, edit something, ctrl-z out to the shell, fix something, fg back to emacs etc... I find the ~2 second startup time for the times when I don't run it as a daemon negligible, and imho it's easily worth it at least if you make use of some of the more powerful editing modes.

Also the lacking a decent text-editor joke is just that, a joke :S

Re: Why GNU Emacs?

#45

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.

This doesn't make sense. You used to be someone easily distracted by yak shaving, is what it reads like.

Installing features in Emacs is not exactly tough, either. I do think you can get distracted by the sea of things you can install. Probably no different from the new toys in the realm.

Re: Why GNU Emacs?

#46
> 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 "good operating system, bad text editor" joke you'd see on Slashdot or whatever.

But nowadays while Emacs clocks in at a dozen MB, it's still smaller than what I'd consider "light weight" editors like ST3 and Atom, and minuscule compared to the likes of IntelliJ, Eclipse, or XCode.

Re: Why GNU Emacs?

#47
post #22
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…

Sublime Text is proprietary closed source. That seems counter to modern Unix/Linux goals.

Which UNIX isn't proprietary?

Note UNIX, not UNIX like.

Re: Why GNU Emacs?

#48
post #22
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…

Sublime Text is proprietary closed source. That seems counter to modern Unix/Linux goals.

There is Atom these days which is OS and similar to ST.

Mind you, Atom takes longer to start than Visual Studio.

Re: Why GNU Emacs?

#49
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 essentially booted up to a LISP REPL.

Re: Why GNU Emacs?

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

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 typically use a small emacs window next to a terminal (or few - I don't run terminals in emacs) and browser in my tiling wm. Helm makes this nearly impossible, since it's very difficult to control where helm windows will go without using popwin (horrifically buggy) or shackle (I never tried this, as I'd already moved to ido by the time it showed up), because of helm's nonstandard way of doing things.

With regards to the bugginess, I can anecdotally say that I've seen more asking about problems with helm on the #emacs IRC channel than any other package - and there are several of equivalent popularity (magit, for instance). I also experienced numerous bugs while I was using helm, including some that broke my emacs config. The only package I've had break my config more than helm is org, but org generally works quite well if you can get it loaded without problems.

Post reply on HN