I love EMACS, partially because of those zippy the pinhead quotes that can be evoked with the 'M-x yow' command
Why GNU Emacs?
111–120 of 317 posts
Re: Why GNU Emacs?
#112I enjoyed this; I moved from Vim to Emacs a couple of years ago and indeed the most important thing to recognise is this: Emacs does have a great text editor, and it's Vim! With evil-mode you can use all the Vim bindings you're used to (including sed commands with ':'), but with the added benefits (and drawbacks) of Emacs! I've also found that fiddling with my .emacs is really fun, fiddling with .vimrc was usually qu…
I tried this, but found that the issue is that most major modes use a "grammar" that make sense to native-emacs user, and ended up fighting with them.
After a day of editing on Emacs on a MacBook Pro, my hands felt like they were going to shrink and stick into a contorted state.
So I tried Evil which does work fairly well for editing text. In some ways it's better than Vim--the :substitute is really nice as it shows all pending substitutions in the buffer. But as you said, some major modes work with Evil and others don't, so I'm never sure what I'm going to get.
Ironically a modern laptop is well-suited for Vim, as vi worked on primitive terminals--laptop keyboards don't have a lot of keys and they are poorly positioned. The MIT lab for Emacs probably had nice keyboards.
So these days I am back to Vim and have been finding plugins to make up for the things that Emacs has that Vim doesn't. vim-dispatch is a decent replacement for M-x compile.
Re: Why GNU Emacs?
#113Earlier 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…
make sure you're using the stable melpa repository. The unstable (default) melpa repo is just builds direct from the master branches of the projects. melpa stable is builds from release tags. since switching from unstable to stable melpa, I've not had anything break.
Agreed. Regular melpa is practically a parody of a package repo - sometimes it seems it took the worst option at every possible decision. Building directly from HEAD, using insane version numbering that causes package.el to prioritize it over every other repo (someone more cynical than I might think this was intentional), and yet somehow managing to be by far the most popular way to distribute packages, even more so than melpa-stable (which is actually quite tolerable).
Re: Why GNU Emacs?
#114Earlier quoted context omitted.
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 m…
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.
Re: Why GNU Emacs?
#115Earlier quoted context omitted.
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.
Fine, sure, but I think his point is just: Emacs users don't run Emacs on files; they run Emacs once and then open files with it (or with gnuclient/emacsclient).
Re: Why GNU Emacs?
#116Many 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 may have a tradition of small, composable tools. But Unix at the same time has a tradition of large, non-composable and long running tools. The X11 server is such a thing. Many GUI applications under Unix are working that way. From Framemaker to the big gui-based CAD applications.
Don't let them tell you that Unix was developed to ONLY run small composable tools and that this is the only true way to use applications under Unix.
If you look at Mac OS X as a Unix, the typical application has a GUI, only one instance is running, it works for multiple documents and often users keep them running for a long time. When browsing the web, one would not leave Safari/Firefox/Chrome after each web site visit...
Re: Why GNU Emacs?
#117I enjoyed this; I moved from Vim to Emacs a couple of years ago and indeed the most important thing to recognise is this: Emacs does have a great text editor, and it's Vim! With evil-mode you can use all the Vim bindings you're used to (including sed commands with ':'), but with the added benefits (and drawbacks) of Emacs! I've also found that fiddling with my .emacs is really fun, fiddling with .vimrc was usually qu…
I tried this, but found that the issue is that most major modes use a "grammar" that make sense to native-emacs user, and ended up fighting with them.
Yes, that's a problem. I actually have redefined all they keybindings of certain major modes so they play nicely with evil.
Re: Why GNU Emacs?
#118This article seems to assume that people who criticize Emacs don't understand that Emacs isn't a monolith, and that the various features are modules. I'd guess the majority of people who say "Emacs is bloated" do get this. The author fails to understand what people really mean by this criticism.
I'll just speak for myself here, because that will make phrasing easier; the point is that for me a text editor doing most of the things the author describes (running shells, handling email, todo lists, etc.) makes no sense. For me, a text editor should first and foremost be a great text editor. Secondarily it can be nice to have integration with Git or other tasks that are intimately related to the files I'm going to be editing with the editor. But why would I ever want my editor to do all those other things? I have a window manager for that. Or at least a shell.
The comparison of Emacs to a shell kind of illustrates my point; a shell only exists to facilitate managing of files and processes. It being able to run any command you want is its whole purpose. Emacs was originally an editor, and the community grew its capabilities from there. (I'd argue that it grew during an era where it having so many modules with so many capabilities made more sense than today, but that's another conversation.)
The comparison of Emacs to a web browser is better than the comparison to the shell. But this comparison still misses the mark, because browser based apps have several advantages (and disadvantages) over native apps, they are fundamentally different because of the technologies involved.
Using Emacs to do things like email, manage your shell sessions, etc. is a bit different from running another mail client, or running separate shell processes, etc. but they are not fundamentally different from each other in the same way. Whether you're running Emacs locally or remotely, you can run separate mail clients, etc. the same way.
Anyway, my point is not that Emacs has no reason to exist, but it comes down to this; personal preference. The only reason to use Emacs the way the author does is because you like it.
Re: Why GNU Emacs?
#119Given the whopping size of Atom, I really wonder why anybody would call Emacs big. Emacs was just ahead it's time.
Re: Why GNU Emacs?
#120I use both Emacs and Vim and Emacs is slow. Often I would issue commands too fast for Helm to pick it up. It has rich environment and a lot going for it, but it is slow. Excuse to have "full featured" environment does not stand because Sublime Text is very much full featured and very fast.
Anyhow, while Vim is still my goto editor, Emacs has a lot going for it and I fire it up when I work on Elixir because of superior support. Org mode is nice.