Live data from Hacker News

Why GNU Emacs?

elephly.net

131–140 of 317 posts

Re: Why GNU Emacs?

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

> It seems like they've managed to starve out a good chunk of innovation on this front.

If you look the way magit dialogs are handled, they're quite innovative and could be useful in many other contexts (like shell commands). Magit itself has many other innovative UI approaches. EMMS/gnus/notmuch/twittering-mode have innovative UIs of their own. Also look at spacemacs and the things its doing with guide-key for more UI innovation.

Being able to search (C-s) or filter (occur) almost any text on the screen (including UI like button names) is very nice, and something I miss when in Atom (like the Settings tab where one can only search things the creator decided to add a search field for).

There is a ton of innovation in vim and emacs these days, mostly in new packages. I'm glad we have them (and Atom and others) exploring different approaches.

There are plenty of gedit-like editors with standard user interfaces.

Re: Why GNU Emacs?

#133
post #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/

I've been a vim user for a few years (I wouldn't consider myself a power user, though). I switched to Spacemacs last year, and I don't regret it at all. The power of the Emacs ecosystem mixed with excellent hotkeys (on top of vim's better keybinds already) is a formidable combination.

Re: Why GNU Emacs?

#134
post #102

Earlier quoted context omitted.

I do not have all the commands memorised. But how emacs completes changes upon where you hit tab. if you type M-x re-bu TAB, it will show revert-buffer, re-builder, etc. If you hit TAB when cursor is at the beginning, like M-x buffer M-b TAB, it will show any command with buffer in it. Then you can C-x o to the Completions buffer and use any search tool on it, e.g. isearch-forward-regexp.

More power to you, but I couldn't go back to manually-invoked completion at this point. An environment which gives me as much information as possible as quickly as possible in as few keystrokes as possible is a big priority for me, and I'm willing to have a few extra dependencies in order to get that.

It's not about dependencies, after all ido is part of emacs. I find the default with some tweaks to simply be better. Though it's a bit personal preference here I think.

Re: Why GNU Emacs?

#135
post #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. Ho…

[deleted]

Re: Why GNU Emacs?

#136
post #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. Ho…

[deleted]

Re: Why GNU Emacs?

#137
post #92

I'd love to get started using emacs, but it's extremely difficult. I want to use it to write c++ on Windows. I'd like to have autocompletion support, and navigation support on a large project (>1million lines). I have yet to manage to get it set up. If it were more straightforward to set up and use, more people would use it I'm sure.

Agreed. I tried for a good portion of last night to get it setup for Clojure, and it was surprisingly difficult.

Re: Why GNU Emacs?

#138

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.

What? You literally just call emacs --daemon on startup. You can also easily kill it and restart it.

Re: Why GNU Emacs?

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

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

I did forget it supports out-of-order matching, my apologies. Still, it does use a strange, difficult-to-use form of matching, and does not sort the results by default.

I use flx-ido, which supports out-of-order matching to some degree. This is not a knock on helm, as helm (now) has helm-flx, but nevertheless I consider ido's default much better than helm's, as ido at least sorts the results.

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

I may have made this point badly, but it's not about features, it's about letting me use those features the way I want. I don't recall the exact discussion, as this was over a year ago, but I asked for the ability to change a specific default and was told "that's the wrong way to do it" - and I'm not the only one who's recounted something like that happening in the project. That's unacceptable for something I use in Emacs - I want to be able to change anything.

> ido is not changing, and most extensions to it are very hacky.

ido does everything I need it to, and works seamlessly with every package I've tried it with. If its extensions are hacky, I haven't noticed - my ido config has literally never broken, whereas when I used helm I dealt with things breaking constantly, and not because of the introduction of grand new features. I don't mind bugs due to newness; I greatly dislike bugs that are due to doing things in a non-standard, difficult-to-customize manner, combined with a lack of care towards not breaking things, which has been my experience with helm.

Helm has a lot more features. That's certainly true. A lot of those features are ones I wished I could have in ido. But in nearly every other aspect helm is significantly deficient, often pointlessly so. Helm had to have extra work put in in order to use custom non-standard windowing functions - extra work that makes the package significantly worse, IMO.

FWIW, I don't mean to say your response is wrong, and I don't mind that people use helm (I use helm a little, though only when I have to). If you can get helm working, and you like it, that's great. I just don't want new users to get disillusioned with emacs because of how finicky and frustrating helm can be - as I mentioned in another comment, I see more people in the #emacs IRC channel having problems with helm than with any other package. Helm is often proselytized without much warning about the issues I listed - I almost quit Emacs when helm, one of its "star packages" according to most Emacs bloggers, caused me so many problems.

Re: Why GNU Emacs?

#140
post #134

Earlier quoted context omitted.

More power to you, but I couldn't go back to manually-invoked completion at this point. An environment which gives me as much information as possible as quickly as possible in as few keystrokes as possible is a big priority for me, and I'm willing to have a few extra dependencies in order to get that.

It's not about dependencies, after all ido is part of emacs. I find the default with some tweaks to simply be better. Though it's a bit personal preference here I think.

"dependencies" was a reference to the numerous plugins I use to get ido in a state that I enjoy. I don't particularly like stock ido, though I prefer it to the standard completing-read.
Post reply on HN