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.
Why GNU Emacs?
91–100 of 317 posts
Re: Why GNU Emacs?
#92I 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> 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.
http://www.tomshardware.com/reviews/Intel-i7-nehalem-cpu,204...
Re: Why GNU Emacs?
#94Re: Why GNU Emacs?
#95Re: Why GNU Emacs?
#96http://howivim.com/2016/damian-conway/
https://www.emacswiki.org/emacs/AceJump
Worrying about startup time is the wrong problem. You want to optimize for keystrokes, for example. More work, less typing.
Re: Why GNU Emacs?
#97At 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?
#98Earlier 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…
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?
#99Nowadays 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…
So instead I spawn Emacs just for editing/changing/email/finding, and do all shell stuff through screen/ssh/bash.
Re: Why GNU Emacs?
#100Earlier 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".
GNU Emacs starts a Lisp environment, loads a memory dump, runs various initialization code, etc.