Live data from Hacker News

Why GNU Emacs?

elephly.net

91–100 of 317 posts

Re: Why GNU Emacs?

#91
post #39

Earlier quoted context omitted.

> The UI could be improved, maybe, but there's a lot to be said for knowing that your editor will still exist next year. I'm frankly not confident in ST3, but I'm 100% certain that Emacs will be there. This is misleading. In the era of JetBrains and its perpetual licensing and Steam and whatnot, it's worth pointing out that ST3 is a binary that you download and have complete access to, so of course it will be there n…

Emacs is actually having a bit of a renaissance - ever since package.el came out and became widely adopted, Emacs adoption seems to have increased significantly, and Emacs development is quite active these days.

And 25 is near and with xwidget support, i.e. embedding things like a Webkit instance in a buffer. I guess I will be able to "exec emacs --debug-init" in my .xsession soon.

Re: Why GNU Emacs?

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

Re: Why GNU Emacs?

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

That fits in level 3 cache these days:

http://www.tomshardware.com/reviews/Intel-i7-nehalem-cpu,204...

Re: Why GNU Emacs?

#95
post #82

Earlier quoted context omitted.

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

then you have maintain that thing that monitors the daemons.

Re: Why GNU Emacs?

#97
I've been an emacs user for the last year or so. Previously, I'd used Sublime Text, which I think is a fantastic editor. I loved its speed and especially its simplicity -- pretty much everything just works right out of the box, configuration is managed through JSON instead of some obscure imperative language, etc. But ultimately I really needed two things: the ability to use it over SSH, and the ability to run a terminal inside of it. (ST has a third party shell plugin but it's frankly terrible). So much of my work involves either SSHing into a machine to do work, or rapidly alternating between a shell and an editor. The frustration of having to fumble my way through emacs or vim every time I SSH'd into a remote machine, or having to hackily arrange windows side-by-side so that I could get ST next to a terminal, ultimately became too much and I decided to just start using Emacs.

At this point, I'm reasonably proficient at emacs. From the sound of it, I'm nowhere at the level of the author of this article. But at least I'm comfortable with the essentials -- copy/paste, find/replace, nagivation, etc, and I can easily accomplish the two things I missed from ST (though I'm getting increasingly fed up with the shortcomings of ansi-term, and I might just switch to using tmux).

Unfortunately, what I've lost is the simplicity. I find emacs lisp to be a horrible language. I find it ironic that a platform built on a functional language like lisp manages to produce some of the most complex and incomprehensible compositions of state, as different packages interact with each other in a non-deterministic way, or one package will simply hijack the editor and freeze/crash it, or refuse to let you enter input because a plugin can't parse your buffer, etc. Have some weird behavior in your editor? How can you tell which plugin is causing it? No one knows. It's really quite unpleasant at times. Maybe vim would be better, or maybe not, but learning vim would mean a period of being woefully unproductive or frustrated.

It's irritating that the only choices for terminal-based editors are either embarrassingly under-featured (nano, pico, etc) or require a ton of learning to become proficient in (emacs, vim). On the other hand, there are several GUI-based editors which are powerful and easy, but none of them work in a terminal, nor do they provide a terminal emulator of their own. :(

Re: Why GNU Emacs?

#98
post #89

Earlier quoted context omitted.

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

This works great if you have all the commands memorized. If you don't, fuzzy matching in ido is a fantastic way to find commands and variables that do what you want (Emacs has a great tendency to name user-facing commands very sensibly a lot of the time). Most of the time I can use C-h f and C-h v to figure out how to configure something without having to read the documentation.

In addition, ido and flx-ido provide more efficient and faster (you don't have to manually invoke it) autocompletion than what you can get with prefix-based tab completion.

Also, I haven't had any issue with ido+TRAMP - everything works seamlessly on my end.

Re: Why GNU Emacs?

#99
post #73
post #13

Nowadays the only thing I use outside of Emacs is GNOME Terminal / Google Chrome / bash / screen / ssh. All the rest (including E-Mail) is inside Emacs. The Emacs/Vim war is a bit silly, because historically they're really not comparable in that way (although vim has gotten larger). Emacs is more of an alternative to GNOME/KDE/Windows/OSX than it is an alternative text editor.

"Nowadays the only thing I use outside of Emacs is GNOME Terminal / Google Chrome / bash / screen / ssh. All the rest (including E-Mail) is inside Emacs." There are ansi-term, shell, and eshell. The first is an actual ansi-term within your emacs, the second is a comint shell, and the third is a shell implemented in elisp. Emacs has frames, and with C-u M-x shell you can open as many new shells as you want. proced is…

I've tried all of those things. While Emacs deals with a lot of things really well, I have around 100 terminal windows (screen sessions nested within screen sessions based on topic) at any given time. While it would be neat to have that all within Emacs for copy/pasting etc. since it's single threaded it just deals with it horribly.

So instead I spawn Emacs just for editing/changing/email/finding, and do all shell stuff through screen/ssh/bash.

Re: Why GNU Emacs?

#100
post #80
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.

Running emacs like "$ emacs " is like booting a computer, editing a single text file, and then "$ shutdown -h now".

Not really. GNU Emacs is no operating system. It has no network stack, no framebuffer interface, no file system implementation, etc. It provides interfaces to those. As such it does not initialize hardware and it starts no OS during startup.

GNU Emacs starts a Lisp environment, loads a memory dump, runs various initialization code, etc.

Post reply on HN