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.
Unix has a big flaw: through the pipes pass random data. It's up to the receivers to interpret it. Lisp gives you the possibility to easily structure your data and pass it around, plus the ability to pass programs around. Other than this, the unix way and the lisp way are nearly parallel, though in lisp "command line utility" is called a "procedure".
As funny as that comparison sounds - browsers are an amazing environment/system. If we ever abandon the Browser for more opaque systems I'm sure it will be remembered the way we remember Lisp machines today.
The xwidget_mvp branch has been merged into the emacs master branch about a month ago.
It allows you to embed GTK widgets INSIDE an emacs buffer, effectively allowing one to create actual GUIs inside of emacs.
This also allows you to embed a full webkit-based browser (with javascript support!) right into emacs, and use it like a regular browser.
Just clone the emacs repo, build it with gtk3 and xwidget support, and run 'M-x xwidget-webkit-browse-url' to get a full-fledged browser with proper rendering right inside emacs.
Browsing through an environment that's integrated nicely, deeply configurable, and completely programmable. What else would you want as a programmer and an pc user?
You just need to have a standard data structure marshaling format. Lisp gives you the ability to easily structure data, but it doesn't enforce any single way to structure it.
Emacs has a big flaw: It's just too fucking complicated and inconsistent. Unix, otoh, can do everything emacs does AND it has a half-decent text editor (vim).
Your comment has a big flaw: it assumes that the grandparent comment is comparing emacs and unix, whereas lisp and unix were compared. If your reading skills are like this, anything is complex for you. And afaik emacs is not a sexual being. And if you think that unix is simple, easy and consistent, your unix fu is probably just adding a fancy prompt to your bashrc. Try ls: how do you sort dirs before files? The first thing you ask is whether it is gnu ls or sth else. Try man, the first question is which format. Make? Same story. I want to get notified for changes in a directory: each unix has its own incompatible thing. And these are the very basics.
No, every UNIX shell is a poor Read-Eval-Print-Loop when compared to what Xerox PARC machines allowed in terms of interaction with the running OS.
UNIX shells don't allow to call functions declared in .so, execute scripts applied to elements selected with the mouse, apply functional algorithms over data.
Well, you can write external commands in another programming language, but then it isn't a REPL anymore.
A lisp repl is not any repl. First, the homoiconicity of the lisp syntax allows you to sumbit structures of arbitrary complexity to the listener, and reuse output from it, even submit it back as code to execute. Second, the error handling mechanism allows you to interactively choose how to resume, and the way the repl and the image work, allows you to redefine the ill code before resuming, which is incredibly useful and intuitive. Say I have an url, and a loop that reads some data from that url, suddenly an error happens, the resource url is changed and I have to update. If I was using slime through emacs, I would be taken to the debugger, which shows me the options to resume. While that debugger is there, I can switch to the source file, tweak the variable for the url, evaluate it, switch back to the debugger, and hit the key for retry. I would have fixed the code without having to stop the program (not even behind the scenes, like with tools that watch the program and restart it). And also within the debugger, in either of Elisp debugger and Slime debugger, I can do many things, among which peek into the locals, copy stuff from there and use in my program to explore the problem. I have heard that in a space mission, NASA programmers were able to fix a spacecraft that was in space, from earth, via connecting to its lisp image over the network.
What do you do when you have to debug a pipeline? You do not have direct access to the data that flows, you need special tools to examine core dumps, and you have to have had enabled saving the dumps beforehand, you need to verify that the command syntax is correct, you have to understand what each program emit, and make sure you filter out all irrelevant data like logging etc., you don't know which part of the pipeline failed, where, you don't know if it is a wrong parameter or the program has a bug. And in order to fix bugs in programs that make up the pipeline, you have to know in whatever language the buggy one was implemented:
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...
I think what makes a tradition is the work that is in the original spirit of the project [1], not the exceptions to it.
I would argue that the original developers of Unix over at Bell Labs were horrified at X and the "monolithic" applications that were being developed for Unix.
So much so that they wrote an entirely new operating system, Plan 9 that pushed composability to a new level and also included its own windowing system called 8½ (which was rewritten later as Rio).
Rob Pike had this to say about 8½ [2]:
> The entire system, including the default program that runs in the window — the equivalent of xterm pasting between windows — is well under 90 kilobytes of text on a Motorola 68020 processor, about half the size of the operating system kernel that supports it and a tenth the size of the X server without xterm... The small size of 8½ does not reflect reduced functionality: 8½ provides service roughly equivalent to the X window system. 8½’s clients may of course be as complex as they choose, although the tendency to mimic 8½’s design and the clean programming interface means they are not nearly as bloated as X.
Plan9 is not that successful and not a good representation of actual Unix use. Doesn't GNU Emacs run on Plan 9? Wait, there is Acme.
What about Acme's architecture?
> Acme is about 8,000 lines of code in Alef, a concurrent object-oriented language syntactically similar to C [Alef]. Acme’s structure is a set of communicating processes in a single address space. One subset of the processes drives the display and user interface, maintaining the windows; other processes forward mouse and keyboard activity and implement the file server interface for external programs. The language and design worked out well; as explained elsewhere [Pike89, Gans93, Reppy93], user interfaces built with concurrent systems can avoid the clumsy top-level event loop typical of traditional interactive systems.
That does not sound like Unix philosophy. Communicating processes in a single address space application. On Plan 9. Written by Rob Pike at Bell Labs.
We've seen companies like SUN, IBM, HP, DEC/Compaq/whatever they are called now/..., etc. earning zillions on big fat applications. Big fat GUI applications and big fat server applications.
From any Oracle DB, to any Java application, to basically every desktop application - none follows the so-called 'UNIX philosophy'. Thus tools like GNU Emacs have zillions of similar applications under UNIX and GNU Emacs is nothing special at all.
Plan 9 is more Unix than Unix. First, Acme is no longer written in Alef, but in C (on Plan 9) or Limbo (for Inferno). Second, I don't think you understand how Acme works; try reading the Acme paper or watching Russ Cox's introductory screencast.
X was designed to replace W, which ran on the V System (which is not related to System V or UNIX in general). It does not come from the UNIX tradition - it is a port.
Plenty of monolithic software runs on modern Unices, but very few can be traced back to a tradition of monoliths.
What did the Unix tradition of composability though pipes produce though that was more complex than grep, to put it in an exaggerated form? It sorta seems that the classical Unix approach breaks down for big tasks, hence in practice big programs do not follow it. "...and the eulogy was delivered by Perl", as Pike put it.
It's a bit crazy to call Emacs bloated these days; vim is big, too, so is Eclipse, so are most useful programs. I don't like Emacs one bit, but its size is the last thing that bothers me.
> What did the Unix tradition of composability though pipes produce though that was more complex than grep, to put it in an exaggerated form?
netpbm?
Actually, once upon a time, there was a web browser called "Chimera", it used external commands to handle many types of files. For example, it used djpeg to load inline JPEG images.
...and it's an unstable and/or insecure way to develop an application, which is why Mac OS X has things like XPCServices and browsers tend to run multi-process tabs.
Just because a program has the illusion of being monolithic doesn't mean that it should shed the lessons of combining smaller, more stable parts.
You practically took the words out of my mouth. I was about to say that for gainful emacs usage, all I need is a Lisp machine. But since Unix is the reality, I'm staying with vim.
I 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 quite frustrating.
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.
I had this problem a few years ago when I switched from Vim to Emacs. You could try writing your own evil-leader shortcuts for common commands + major mode commands. It initially takes a day or two to set up basic commands (like buffer switching, commands for your favourite programming language, and REPL stuff) but after that there's minimal tweaking to do.
For less commonly used commands you usually can do M-x [command-name] or just memorize a random Emacs keybinding.
In the end I thought it was 100% worth it for working in LISP dialects like Clojure, Scheme, and Common LISP. The good REPL integration and the ability to control everything makes Emacs pretty fun.
Reconfiguring OS X to substitute control for caps lock really helped me. Yes, many keyboards had them swapped physically some time ago. Here's an example of a keyboard from a Sun workstation:
I used vim for 20 years before switching to emacs. I'd actually tried switching twice. Firt time with viper (I think), which didn't have good enough vim emulation. Second time evil-mode finally convinced me to switch completely.
Then I ran in to the same issue as you, that a lot of emacs modes had native emacs keybindings. So what I wound up doing was re-binding those to be more vim-like. I didn't rebind everything, just the things I most used, and it's worked great for me. I'm still a happy emacs user.
It did help that I already knew lisp and scheme, so getting up to speed with elisp was relatively painless. And it helped a lot that at the time I made the switch I was out of work and had a ton of free time on my hands. Don't think I would have been able to do it without that time, as it did take a ton of time to customize emacs enough to compete with the vim setup I had cobbled togather over 20 years.
It was totally worth it for me. But I'm not sure I'd recommend it to every veteran vim user, unless they have lots of time on their hands. On the other hand, I've heard that Spacemacs has a lot of sane defaults for vim users. So maybe Spacemacs+evil is the answer. I haven't tried it myself yet, since I have a ton of custom vim bindings of my own in emacs now, and very little free time to experiment these days.
You're absolutely right that it takes a bunch of time to set Emacs up initially. I took a week off work for unrelated reasons and spent a few evenings of that time to set up Emacs with evil-mode and it was totally worth it. However, I did put off doing it for over a year before that, because I didn't have the time to spend.
An important realisation was that I only need my Emacs to do the basic Vim things and then some extensions I commonly use. At that point, I can survive using only Emacs and building onto it as I feel like I need something.
Take a look at spacemacs (sorry, no link, I'm on mobile). It's got a lot of cool features, but most importantly the "layers" (an abstraction on top of modes and packages) all have evil-ified keybindings.
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.
The features just aren't there for me in Atom. I have a feeling they are if you're a web developer, but us non webdevs are left out in the cold (at least for now). Compare LaTeX and R in Atom to AUCTeX and ESS in Emacs and it's like night and day. Every time I switch to Atom I get frustrated within a day due to lack of features for the things I use.
I use an approach similar to this [1] to automatically install missing packages on startup. This means that when I move to a new machine I just have to clone the repo with my emacs configuration to have everything ready, settings _and_ extra packages.
Not everybody needs that. Even I as a sysadmin just use TRAMP from within my graphical Emacs to edit remote files and don't open Emacs in an SSH session over a terminal emulator.
> 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.
It's not really large in terms of memory on any remotely modern system.
But it is large in terms of learning curve. Emacs has a ton of concepts and interface quirks that don't transfer to or from other common software. It has it's own keybindings, even it's own way of documenting it's keybindings, that shares no similarity with what the OS considers standard.
So there's a huge amount of pain in switching too or from Emacs.
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.
Emacs has a different usage model. Instead of starting a new Emacs for every file you want to edit, keep one running and edit all your files in it. If you're working on multiple projects, have one Emacs for each project and switch between them.
It isn't actually as bad as all that. I confess that I do this in system admin mode. On my big workstation it takes about five seconds for emacs -nw to start up. And lately, I have begun using 'mg' for such quick tasks Startup time is less than a second. It is probably on the order of VI for size and speed, and uses the emacs keybindings. It is an upgrade of the MicroEMACS editor.
But normally I do open emacs on a per-project basis and keep it open, likely for days. Those do take a little while to start up. And with .emacs.desktop, it is easy to end up with an accumulation of a couple hundred files at startup time.
(Compare the size of a single tab of Chrome to emacs, or even Microsoft Word. Both are swamped by the chrome size. And we think nothing of spinning up a new tab, no problem.)
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).
Oh, thankfully someone told me that emacs does not have framebuffers and filesystems. It doesn't have wireless drivers too!
My grandparent comment was an analogy, for illustrating how it's not the optimal way to use emacs, as a command line program invoked to operate on one file and then closed and reopened.
The analogy wasn't that great. Booting a machine has nothing to do with typical uses of Emacs. There are many applications which are long running and are working on multiple documents - it's just another mode of working with an application.
One can use GNU Emacs just fine as an editor which starts and quits on a single file. 'emacs -q' starts in a few milliseconds on my Mac. I use single file edits with Emacs on the terminal all the time. Though I usually also have a long running instance of Emacs - but then it is used as a Common Lisp IDE, not just as an editor.
Then one can setup an Emacs editor server.
Or start the Editor and leave it running. This is no different from, say, a CAD program or any typical application on the Mac, where usually a single instance of an application keeps running, editing multiple documents.
The default behaviour is a bare emacs which starts damn near instantly. If you start adding stuff then it takes time to load, but at this point you should know the daemon is an option.
I think that the best default approach would be to start as a normal emacs process but revert to emacsclient behaviour (i.e. just open a new frame) if a running instance of emacs is detected.
This is what web browsers do, for example.
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!
I use the GNU Shepherd init system as an unprivileged user to manage my emacs daemon, and other things like gpg-agent.
The real benefit of 'emacs --daemon', for me, isn't the faster client startup time, but the unification of the many programs that may spawn $EDITOR. Rather than each one spawning a new Emacs process, these programs spawn a client in the window I already have open where I can access everything else I was working on. On top of that, I use the ItsAllText extension for Firefox to edit text fields inside of that same Emacs instance, too. Very convenient.
The first line of my ~/.emacs is (start-server). /usr/bin/emacs is launched once and runs forever. I spend nearly all my time in emacs, so there is nothing to maintain/monitor. If emacs dies, it is rather obvious.
I start emacs once every few weeks, and that's mainly just to do a reset when I finish a project or get to a safe point and want to get a clean slate. The startup time for Emacs is never an issue for me.
well, that's for terminal mode. With a window manager, most application has similar start up time which I assume is caused by similar xorg routines being run.
However, running Emacs in daemon mode does reduce this to instant. Not sure why this is.
On my current machine (OSX w 16 GByte RAM), Emacs built with Homebrow as native GUI application (HEAD, lots of bells and extras enabled) with 10+ buffers Emacs consumes 127 MBytes.
In comparison, Finder consumes 300+ MByte, Firefox 2+ GBytes and Slack(!) 500+ MBytes. And the Activity Monitor utility supplied by Apple I used to check these numbers uses 130 MBytes.
Yes, Emacs consumes 8 MBytes and more. But Moore's law has really fixed that problem. And in comparison with a lot of other SW, Emacs is not the SW application I would accuse for being bloated, quite the opposite in fact.
Slack uses so much memory because it's carrying around the baggage of its own webkit session. It's little more than a web browser that just connects up with slack, and thus has all of the bloat and ugliness of javascript.
To be honest, I very rarely seen 8mb or more back then, when I ran Emacs on a VAXstation with 64mb of ram. Usually it was much less, but, OTOH, org mode did not exist.
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. However my experience was, the more I learned the more crap appeared. One layer of crap after the other. At first everything could somehow be fixed with a lot of configuration and scripts. I needed several hundred lines of Lisp code in my init.el just to be able to work normally.
But then the lowest emacs layer of crap appears which can not be fixed. It includes issues like lack of multithreading, elisp being the least capable and at the same time by far slowest lisp dialect. Stuff like the lack of ability to move the cursor off screen. Inherent jumpiness while scrolling which can not be fixed and really strains my eyes. And don't even try to look at the C source, it is the worst historically grown ifdef hell you will ever experience.
And finally there is the community which lacks disposition to unify or work together. It is more like a community of loners where each of his own produces personal "modes" which are inconsistent to use and most of the time conflict which each other. The most important reason for this might be lisp itself. It is inherently hard to read other peoples lisp code. So everybody writes his own.
Calling Vim my "editor" is really doing the rest of the programs that actually make up my development environment a huge disservice. Vim might be what I use to edit text, but the rest of "Unix" is my IDE of choice. Being able to tab between an IRC/chat client, my email client, a shell, and an open instance of Vim is a huge advantage for me. So up until recently, I never had a need for Emacs...looking at it as too much of an investment into re-building all the features that are in my shell configuration. That's when I discovered Org Mode.
I love Org Mode. It's become my primary note-taker, todo list, and general idea dump. I've used it to plan out projects for work, tours for my band, and to write down essential things I need to get done each week. Syncing to MobileOrg over Dropbox, and keeping my Org files in a synced documents folder, means that all of my computers have access to the same information at all times. I tried using vim-orgmode for a long time but most of the features that seemed the most useful to me just weren't supported. Why screw around with VimL when I could just download Spacemacs, configure Solarized and Monaco to at least get it looking like Vim, and then use that just for Org Mode? That's what I've been doing, and I have to say I've fallen in love with how fast I could get packages up and running and with how many great features seemed just "built in".
...Click a button, or invoke a command and an empty, unremarkable rectangle appears. Little you know that it is a relic from an age long past...
Emacs to me, first and foremost, is a doorway to another dimension, a place you can escape to from the absolute drudgery of the contemporary software development.
...A relic, yes, but it seems as alive as ever, a dark block inside it, blinking, like a pulse on a medical instrument...
It is also a glimpse into what professional tools might be like, if they were not so obsessed about beginner users. [1]
...You wonder what the hell you should do with it...
What I think is funny is people making fun of me for reading email in Emacs. I use my own filtering system built on top of MH-E, which is layered on top of nmh command line tools. MH-E uses GNUS for MIME handling and I'm able to view HTML messages just fine.
Why I think it's funny: people laugh that I'm using 20-30 year old technology and new tech would serve me better. To each of them I say: I challenge you to an efficiency dual/bet. Pit your system against mine. When I show them actually what I use, they don't take the bet.
Yes, what I'm using was first written almost 30 years ago, but I've tuned the crap out of it (with my own tweaks) and so have others, improving the tools themselves.
The only thing that would make my life easier would be if nmh could use IMAP. There have been many discussions of this, but it's just not a natural fit. I don't know if it will ever be done.
<rant>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 standard user interface meanwhile the Unix world is anchored to Vi and Emacs. It seems like they've managed to starve out a good chunk of innovation on this front.
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 happier. But if Emacs lost Helm or Magit, I'd be devastated.
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 version (melpa is another rant for another time - standard melpa is totally brain-dead)
- 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)
- The default helm-mode (what they recommend using for completing-read, which controls execute-extended-command, i.e. M-x, and such) is unsorted. Not badly sorted - unsorted.
- Doesn't use a lot of the standard layout functions, instead replacing them with its own stuff that can't be customized in a standard way.
- Dictatorial maintainers that only allows options and features that they deem the "right way" to do it. This is fine for some projects, but total control of my editing experience is the primary reason I use Emacs in the first place.
ido with a few simple plugins is vastly better, less buggy, more compatible, faster, has better matching, and is easier to customize. I recommend against using helm for completing-read unequivocally.
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.
helm-flx sorts results by the "closest" match to your typed in characters. For me, typing "tetri" has "tetris" listed first, with the next result matching all of those characters in a different command, and each of the following results being less and less accurate matches. There is no alphabetical sorting, though.
Popwin is very annoying for me, too. I'll look into trying out shackle.
There is also a less-popular completion system for emacs called ivy. I don't know how it stacks up to ido or helm, but perhaps that one is also worth checking out.
> 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 will not find it. In ido one would have to do "file<C-SPC>rename"
> Dictatorial maintainers that only allows options and features that they deem the "right way" to do it.
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).
> Constant bugs
This is because helm is constantly changing and improving. ido is not changing, and most extensions to it are very hacky.
I prefer ido, but helm is a good tool that's perfectly usable that tons of people like and does a lot more than ido.
ido would really benefit from being spun-out as a package. People would actually fix bugs and add functionality in a reasonable way rather than hacky extensions (like ido-hacks)
> 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 "file<C-SPC>rename"
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.
For M-x I like smex. Like fuzzy ido but without the bugs and purpose built for M-x - it just works. smex persistently remembers how often you use different commands, and uses this to sort the initial list of completions - very handy.
(require 'smex)
(smex-initialize) ; is this needed?
(global-set-key [(meta x)] 'smex)
(global-set-key [(shift meta x)] 'smex-major-mode-commands)
I think both built-in completing read and helm/ivy have their uses. ido is best for when you know what you want and want to get it to it with minimal number of keystrokes. helm seems better for when you want to review many (but not too many) options before deciding on what you want.
I find ido unusable for find-file, because of how it splits up directory from filename. So I use the builtin completion.
But I rarely open files using find-file anymore. ido-use-virtual-buffers is magical. For commonly opened files it let you use switch-to-buffer whether the file is opened or not.
I love ido's find-file, but I think that's because I've made it behave much differently than the defaults. The ability to use backspace to go up one full directory, jump to home with ~/ at any point, jump to / with // at any point, and navigate folders quickly with fuzzy matching and RET is really, really nice.
To be fair, most of my file opening is done with projectile, which, when you exclude the right files and use ido, works fantastically well. I can get to nearly anything I've been working on in two commands - projectile-switch-to-project (C-c p p) and projectile-find-file (C-c p f).
I'm not sure what you mean by "how it splits up directory from filename" - could you clarify?
ido-use-virtual-buffers is indeed awesome - I really love it.
Ah, I see. This is actually one of my favorite features of ido-find-file. I love the fact that I can treat the current path section I'm writing as independent of the path I've already navigated to. To each their own.
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).
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 will complete to actual command name. It will ignore case in completions if these variables are set:
;; Ignore case when completing file names in minibuffer.
read-file-name-completion-ignore-case t
read-buffer-completion-ignore-case t
completion-ignore-case t
Also an indispensable config:
enable-recursive-minibuffers t
What does them tools provide that can't be easily done by these? And ido fails when entering a TRAMP file name, so one has to hit C-f in minibuf to drop to the original prompt.
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.
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.
"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.
I went from Emacs to Sublime and back to Emacs. 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.
But beyond that, I find that a lot more stuff Just Works in Emacs. I spend my days working in Python, and both major Python modes for Emacs are miles ahead of ST's equivalents. Things like linters work as expected and there are lot more packages available for niche things. Emacs is subjectively better, even if the UI doesn't feel as platform-native as other editors.
I don't use Emacs because I'm a graybeard afraid to learn something new. I use it because I've tried every new hotness to come along and I've yet to find something as powerful, well-supported, and ubiquitous.
Meanwhile, if you're used to Vi's modal editing or Emacs's elisp, you're basically going to hate the other tools forever if for whatever reason. For example if you need IDE features for your project or the Vim/Emacs extensions for language X are no stable/flexible enough.
Once you're past the basic navigation cluster + cut/copy/paste/undo/save (which tend to be more Windows-style, I'd say, than CUA!) every editor is different.
Ctrl+F for Find is a common standard, for example, but it's hit or miss whether this is Ctrl+F for Find (and that's your lot! Find & Replace is something entirely different), Ctrl+F for Find (and you have a checkbox for Replace), Ctrl+F for Find (and you have a checkbox for Replace... and this is how you search across multiple files as well). And there are multiple standards for all of these additional options. Your muscle memory will be useless no matter what you're used to. You're welcome to describe emacs as unusual... but don't assume everything else is a nirvana of UI consistency. The process of "just" switching can be a bit more inconvenient than you might think ;)
When I'm working on Python code, I'm in PyCharm. My C++ work on Windows is in Visual Studio. When I ssh into the Linux machine that serves our in-house documentation to make changes, I'm using vim. On OSX, I use BBEDit most of the time. When I'm writing a letter, I'm usually in Word or Google Docs.
I think if I spent all day every day in one environment, I would get bored.
> I think if I spent all day every day in one environment, I would get bored.
The opposite perspective: It's extremely frustrating constantly switching between significantly different environments with different UIs, different hotkeys, subtly different jargon, etc.
Maybe that's the difference. I'm not a productive multitasker. When I have some Python to work on, that's all I'm doing for the next day or two. I'm not jumping from Word to PyCharm to Vim all day.
Nearly every IDE of importance has either a full VIM plugin or is working hard on it. Not having to take your hands off the keyboard line to hit the arrows or mouse is a big deal to a lot of devs. Having easy and powerful regex is nearly as important. And having buffers is probably a close number three.
Personally, mapping Caps Lock to Ctrl (which I do anyway) and using Ctrl-C works best. I use vim and IntelliJ's vim emulation on an international keyboard where Ctrl-[ won't work.
So the entire argument about not moving one's hands is moot then, since in emacs you get navigation via control-key for free, and in vi you need to remap the most important key to something near home row.
I'm not interested in a war either. I'm only interested in both sides presenting fair arguments. If one side says "but the other side has to move their hands" and leaves out "oh, my side does too, unless I rebind keys", then that's unfair, and I'll say something.
If you think that places me on the other side of the argument (it doesn't), that's on you. It simply puts me in the middle.
> 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 next year.
You're probably getting at the fact that development may stop on it next year, and that's true, but the product is still pretty polished and useful now.
I also don't have your confidence that Emacs will always be there. I don't have statistics - but have contributions been increasing or decreasing in the last decade? In any case, I hope that Emacs fades away: text editing is great, but I think there's still plenty of room to advance our craft. Things like Lamdu and Eve (nee Light Table) are interesting explorations.
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.
All you need to do is to set up a couple of hotkeys for things that Emacs cannot do (yet), like (start-process "" nil "xdg-open" "http://some.flashy.javascript.website")
I tried it very early and it was unstable, but I'm following its development, and it seems that it'll be stable shortly. I'm using ratpoison nowadays, though I'll switch to it when it's stable enough and emacs gets multithreading.
> 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 next year
This is not "being there." Popular architectures change, as do operating systems. Unless you intend to freeze your current computing environment for posterity, a working executable means nothing.
Not trying to be confrontational, but conversational --
I'd say that both vi and Emacs have solid fundamentals and have stuck with a model that works, to their credit. I must admit that I shop around for editors occasionally (I'm a long-time emacs person, who swapped back to vi a few years ago to re-develop his vi-fu), but I haven't seen anything so compelling that I've switched to anything else.
It may well be that I'm looking in the wrong place, or that I don't realize the true awesomeness of something that does cross my desk.
In the spirit of advancing text editing, what would you say is missing from vi or Emacs that you've found in other editors (even if the advancements aren't present in one singular other processor)?
My primary issue with Vi and Emacs isn't really about lack. They are quite powerful tools. The primary problem is that they impose a certain amount of mental overhead. Emacs was a bit worse in that regard since many of its key bindings are actually sequences. Sublime Text is rather powerful but in terms of features it's probably the one that is lacking of the 3. The win was in unloading the overhead from my normal work patterns.
I think that mental overhead is the steep learning curve that everyone talks about. I remember when I first started learning Emacs it was hard. I just had to think in this new way (I was used to cua style keystrokes), but after a month or so my muscle memory developed and I started not having to directly think about what I was doing. Once you get to that point, the overhead is gone and things become very nice.
But I'll grant you it's a hard sell to say "this is great, but you're going to be unproductive for a month". Nonetheless, I think the payout is very much worth it, and if you are interested, make sure you are prepared, and stick with it for a good long time before giving up.
This is going to sound a little misguided, but bear with me. If you want to see what you're missing: Take a look at the IDEs of the moment. Try something like eclipse on java code or maybe devstudio in the windows world.
In general, vi/emacs are missing support for editing above the level of text (eg. refactoring) and support for UI above the level of a text terminal. I know add-ons exist for both editors that do some of these things, and of course, you can run both in a graphical terminal with custom fonts, etc -- but if one is being honest, it's not very well integrated in either of the old standbys.
I'm a vim user, but not really an advocate. I'm just used to it, I like the way it works (mostly) out of the box[1], and I think it's text editing facilities match the way I edit better. It's a great generic text editor -- as is emacs (for some others, not me). But all they do is understand text...
I had to do some Java development recently. So I tried eclipse (with a vim keymap plugin). Now, eclipse kind of sucks in many ways, but one thing it definitely has is the ability to refactor code. Something like variable rename over multiple files that would have me concocting a sed-ish script for vi, or doing query-search-replace, next,next,next,skip,next in emacs was literally two keystrokes and bang, done. Forget about actually moving language constructs from one file to another or to another package, etc. And the UI for it was very clear: inplace modification, and popping up a warning about where the refactoring would break, if it would.
And then we have modern UI. Eclipse isn't even very pretty (or modern) by modern standards, but it still highlights properties of code (warnings, unused variables, etc) by actually drawing symbols or boxes on the screen rather than attempting to wrangle indications into the world of VT220 terminals. Among other things...
One could put this all making up for deficiencies in Java, I suppose. Except, again, if one is honest, one realizes that this kind of thing is highly useful no matter what language you're developing in...
Neither Vim or Emacs has very good support for any of this at all. There are examples of add-ons that do it kinda-sorta, but they aren't very good. Emacs is better than vim at this, of course[2], but it's still not very common for language support to get to this level. It's not a standard thing, and it should be. Such is history, and the pragmatics are writing a substantial piece of software inside another piece of software in a crappy language :-). Emacs still crappier (and slower) than eclipse at just highlighting syntax (and barely does the highlighting of semantics).
Emacs & vim have real issues as code editors because they are stuck in the past -- and not the recent past either. Vi was never meant to be anything but a text editor, for good or ill. And Emacs... well emacs lives in it's own little world reminiscent of a half-baked lisp machine crossed with a VT220 terminal. And while the capability is there somewhat to do the above, there is a lot of historical baggage and historical code to overcome.
So, is eclipse my editor of choice now? :-) :-P Well, no (except for java code). :-) It's a shitty editor, it's slow to start, it crashes or gets into a funky state too often, and it's really a Java-editor, not a generic text/code/anything editor (although it tries to be, and fails). But I think eclipse and tools like it show clearly "what is missing" in an old-school editor like vim/emacs, or indeed any new editor which uses either of these as a model.
[1] I also think key-chording, which emacs uses (and others influenced by emacs use) is actively physically harmful.
[2] A better scripting language helps. I'm sure emacs is somewhat passable at refactoring lisp code. :-)
> 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.
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.
Symbolic renames are one thing, but sometimes you really want to do textual renames. When you have names like fooFrobnicator, barFrobnicatorFactory and quuxFrobnicatorController, and you want to rename Frobnicator to Twiddler, symbolic rename won't help you.
Also, you can create quite a lot of code indirectly by few well-placed keystrokes that utilize multiple cursors / keyboard macros, regexp-replaces and things like this. Think of it as chiseling out an entire block of code at once. Spend little time mastering those features, and you can do things like this on the fly, without much conscious focus.
I think they come with quite a lot of baggage, yes. But if you get past the initial steep learning curve, there's a lot of productivity gains waiting for you.
With regards to simpler editors, the problem is that they come and go. Learning an editor is a big investment, so I'd rather stick to something that will still be around next decade.
Who really cares about whether something is "certified" UNIX? Certification is not some seal of quality. "Unix" is commonly understood to denote "functional" unix systems as well for lack of a more convenient term.
What is true is that Vi and Emacs are deeply tied to the Unix tradition. Whether they are 'antiquated' or whether there are 'better' alternatives is a matter of opinion. Personally I haven't seen any other editor that comes close.
Maybe GNU Emacs, because it was originally written for Unix. Emacs itself came from ITS/Teco. Lisp-based Emacs came from the MIT Lisp Machine (using Lisp Machine Lisp as implementation language) and Multics Emacs (using Maclisp as implementation language).
While on the other hand, I use it because I can open a shell from within Emacs.
I can also use tramp to ssh onto another machine from within emacs, and so don't have to bother installing my favourite editor on headless servers and Raspberry Pis.
`ansi-term` works well in most cases. The only time it really breaks down for me is when I run commands that combine really long lines and complex escape sequences (like npm's new progress bar which you can thankfully disable).
I'm quite content with shell-mode for most of the things I do (took me a while to get used to some of its quirks, but now I like them). For curses applications (like alsamixer) I use ansi-term.
Given that all these editors are cross-platform, I don't see how the continued development of Emacs could be starving out innovation in the Unix world.
Well, if those quad-cores and 16GB of RAM would actually be put to good use in the "modern"/"hot" IDE world, we could talk. If anything is starving out innovation, it's sticking to CUA, mouse-driven development and rewriting nano in JavaScript...
When those IDEs are able to achieve what was possible in Xerox PARC workstations, as demoed occasionally by Bret Victor, then we can talk about moving forward.
> PDP-11 command line experience is not even there.
Are you saying the modern unix command line is not as good/better than the "PDP-11 command line experience"?
Also, which PDP-11 command line? RSTS? RT11? Unix? or maybe that awesome front panel where you had to manually input your boot loader in binary every time you started the machine?
> Are you saying the modern unix command line is not as good/better than the "PDP-11 command line experience"?
No, I am saying that it isn't even close to the Xerox PARC REPL experience from Interlisp-D, Mesa/Cedar and Smalltalk environments.
> Also, which PDP-11 command line? RSTS? RT11? Unix? or maybe that awesome front panel where you had to manually input your boot loader in binary every time you started the machine?
The VT-100 interface some people seem to keep living on.
Why have my IDE or developer tools take up all that? Instead, I like to save it to run a 4-node Kubernetes cluster running 8+ Docker containers to have a self contained distributed application locally during development (hey, it works on the airplane too when totally disconnected from a network).
On standard UI: The kind of unity of UI I want is a bit more than common cut/copy/paste/save/open shortcuts---for example, using the same incremental search or mark-and-kill-ring-save keystrokes on items in the long pull-down menu or labels in property-editing dialogs...
You simply don't grok vim. Don't know about Emacs, I'm not a Emacs user, but chances are pretty good you don't grok it either. To begin to grok vim, please refer to the following StackOverflow answer: http://stackoverflow.com/questions/1218390/what-is-your-most...
I was a Vi(m) user for years. I love vi as a concept, but extending it always felt very wrong and cumbersome for me, whereas in Emacs it all feels natural as it truly is the extensible, customizable text editor.
org-mode and slime made me pull the trigger and kept using it for half a decade.
Then I lost my Emacs config. Installed Spacemacs and never looked back. It gives you better defaults, a good community and a framework that lets you easily extend it in a more modular way using layers.
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.
I switched from vim to spacemacs a few weeks ago and I don't regret it. The fact that you can run a shell in a buffer, have on the fly syntax checking and so on makes coding much more comfortable and you feel like you're using a full blown ide instead of just a text editor. Would recommend
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.
"how have times changed before the enemies were Emacs vs Vi.
Now Emacs and Vim are allies against visual studio and eclipse." read long ago in Hnews comment.
"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 like top/ps aux. So it's time to get rid of gnome terminal and screen :)
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.
All of emacs' terminal emulators have been resoundly awful for me. This was probably my biggest disappointment with emacs. I was so looking forward to having the shell be useable from inside emacs, but it's really not.
Now I just use a regular terminal with tmux inside it and emacsclient inside that.
Emacs doesn't really have a terminal emulator, and terminal graphics are mostly unusable in emacs. Shell and ansi-term are there for when you cannot avoid some shell-fu. I use it mostly for VCS operations that cannot be done with VC, and nowadays building Emacs 25 pretests. I use dired instead of ls, proced instead of h?top|ps, but for a sysadmin these are not viable, I understand.
I do not use magit because I do not only use git, and VC allows me to use Git, RCS and CVS easily without learning different emacs interfaces for each.
All of those pseudo shells are extremely buggy. Try something simple like tab completion in fish in ansi-term, and it's a little difficult to claim it's a true terminal.
Well, it's about how one approaches computing. I try to do most without a shell, using async-shell-command and elisp tools in general. But if you're a sysadmin I use shell iff I have to. tmux has many things to offer, which you should use.
I'm a Emacs user and use it everyday. I've seen a post like this from time to time. Most of them make sense, and I indeed agree on it. But from my personal experience, I prefer Clion to write C/C++, prefer IntelliJ to write Java. I will not recommend Emacs for these coding job. A modern IDE is doing a much better job. I still love the org-mode of Emacs though.
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. :(
I found http://vim-adventures.com/ (no affiliation) to be the best way to finally learn vim in the sense of actually developing automatic muscle memory. It teaches you how to use vim using a 2d game. It's worlds better than the built in vim tutorial, to say the least. :)
lisp is beautiful. The crown jewels of computer science. getting to spend time with it reminds you that programming can be fun (and profound) while you are being paid to work with some awful drudgery language solving some stupid problem. Being close to lisp, in this way, is like being at the same party as Audrey Hepburn. It reminds you of grace.
Joel Moses has been credited with coining the phrase in the 1970s
APL is like a beautiful diamond - flawless, beautifully symmetrical. But you can't add anything to it. If you try to glue on another diamond, you don't get a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball of mud - it still looks like Lisp.
That would be pretty difficult to make a diamond from mud.
> Writing a macro that understands forks and hooks is an exercise for a beginner – if the operators covered are strictly monadic and/or dyadic as are those in J. However in Lisp all those optional auxiliary and keyword arguments immensely complicate matters. In order to make it operational within a month or so of effort a tacit macro could be implemented to work just on a subset of Lisp operators.
I find it interesting that we as programmers love to base a lot of our technical decisions on hard data, but somehow the choice of editors seems immune to this. Has anyone ever done an analysis of the actual objective benefits of these editors? I got suckered into the 'religion' of vi and have spent countless hours learning it to a fairly high level of proficiency over the years. I don't think I've ever recovered all the time I spent. Maybe it requires a special use case. Most of my time is spent outside of the editor - reading specs/docs/code, debugging/tracing/analyzing existing code, or just thinking about code.
> Most of my time is spent outside of the editor - reading specs/docs/code, debugging/tracing/analyzing existing code, or just thinking about code.
Most of my time is spent inside the "editor" (Emacs). Reading docs is in Emacs, debugging is in Emacs, too. Thinking about code is assisted by `M-x zone`... :)
To be able to stay in the same application in which I can use my home-grown features on everything that can be mapped to text buffers is an advantage; a subjective advantage, maybe. I don't need to switch contexts as often any more, and my brain thanks me for that.
I grew up on vim and got very comfortable with it, but elisp, interacting with inferior processes, and the overflowing kitchen sink in general slowly replaced my combination of vim+xmonad+tmux+terminal.
For me, most of the material that I need to reference is PDFs/Slides from talks/Books/Web pages/My own hand written notes/etc - basically stuff that is not plain-text. Luckily I have a multi-monitor setup, so I don't really pay any penalty to switch contexts.
But keeping all that aside. As far as just the editing is concerned, all the advanced features in vi and such do help if you're typing out reams of code - something which I never find my self doing.
I suppose the obvious unstated thing here is that people have been productive in all sorts of environments, from notepad to pico to visualstudio to vi. From personal experience I find my self agreeing a lot more with people who say it doesn't matter _that_ much.
I'm not one to argue about productivity. It's a term I never found very meaningful, so I cannot be sure other people mean the same that I understand when I hear the term.
For me it's not about lines of code per unit of time, but about what feels right, and that's very subjective. Dependent on the task I can probably make a decent amount of progress without Emacs, too, so I wouldn't argue that my productivity depends on it. But this Emacs environment is molded after my habits, so it's a really comfortable place, an extension of my body, much like a good tool for wood working that fits your hand just right and lets you work directly on an object without having to think of the tool as a mediator between your body and the work piece.
I wouldn't work with computers if I didn't feel comfortable. Thanks to the flexibility and hackability of Emacs I'm a lot more comfortable doing computer work than I would be without it, meaning that I'll become a gardener a couple of decades later than I would without it.
I was looking for a TODO list application that would work on plain text. This led me to org-mode. Fortunately, I discovered Spacemacs when trying to find a plugin that would emulate Vim keybindings in Emacs.
All I can say is WOW!.
I get to keep all the modal editing goodness of Vim while getting the excellent, well documented functions of Emacs. I also like it that the commands are Vim-like(doing a sequence of keys using a leader key instead of key chords).
Emacs grabbed my attention soon [1], I used to spend a huge amount of time on almost all aspects of it. Now, I don't care[2]. Turns out editors are a waste of time, at least if you consider them so[3]. Brilliant algorithms are short in characters.
That said, Emacs is a full fledged system giving you a lot[4], if you're willing and able to use that lever you'll be happy. Lastly, Emacs survived for decades, it can swallow most interesting ideas that comes (ligthtable ? checked https://github.com/Fuco1/litablehttps://www.youtube.com/watch?v=mNO-vgq3Avg).
----
[1] It's syntactic system is powerful enough to feel different and more solid (important) than other editors at the time (before Eclipse and IDEA). It was repl-friendly, another factor that talked to my mind.
[2] It's still the 2nd most used program on my machine after chromium .. maybe even a tie.
[3] Learn hard things, fundamentals (parsing, compilation, optimization, paradigms), learn how to help yourself (see G.Bernhardt talk about unix chainsaw[3]) in all possible ways.
[4] its open keybinding trie is still something that I miss in most programs and I try to port a subset of it everytime I design a UI. It's also based on a lisp, so enjoy using alien tools from the future. Btw, its git interface (magit) blows Eclipse one out of the water for instance, most people wouldn't suspect how efficient it is compared to heavy 'pro' tools.
Emacs have been my main editor for 15 years soon and while it definitely got some rough edges, once you learn all basic key-combinations for editing and buffer management (which often is even more uncomfortable with a non us keyboard layout) I feel that nothing else really compare. Text editing is great but as many have pointed out the extensibility and all the high quality community projects/modes out there make emacs something unique. I don't think it's wrong to regard emacs more as an elisp environment than an editor.
The biggest problem with emacs right now as I see it is the lack of multi-threading.
I've used all sorts of text editors with a shell inside them, and I can't quite fathom why you'd want to do that. What's wrong with bash running in iTerm? Then it's a first-class citizen of your desktop instead of a subprocess of a subprocess of a thing running inside another thing running in the one terminal window you're using for everything.
I've tried using vim and emacs a few times, but I can't quite get to grips with the whole modal editor thing. Feels like a whole huge learning curve just for the sake of it, getting in the way of actually getting things done.
My operating system is a perfectly good operating system, I don't need emacs for that.
On the odd occasion when I need to edit something on a remote server (this is very rare, cos ansible/puppet) I'm quite happy using nano. It has zero learning curve (no modes) and the few shortcuts you do need are marked on the bottom of the screen. Yes it's kind of featureless, but you shouldn't be editing things on your servers anyway.
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
I switched to emacs a year ago and I love it. I feel a lot more productive when everything I need is in single window. However, just recently, I started feeling what used to be minor RSI to be a major discomfort. There are days where I can't type at all. I don't know if emacs' key bindings is mainly to blame here, but it seems like it. evil-mode have been recommended to me but I'm hesitant because I never liked vim's key bindings.
The first thing every Emacs user should learn is how to customize key bindings. With global-set-key you can assign arbitrary keys (function keys etc.) to arbitrary commands. Of course you have to learn Elisp for that but that's not too hard. It is worth the effort to learn the basics of Elisp if you want to become really productive in Emacs.
Emacs is the most advanced programmable editor ever, and that's the reason why it is still alive. I use it every day for almost thirty years. Of course I don't use the default configuration but a very conventient custom one.
In Unix you just need to know just two editors - Emacs and vi. Vi because it is the default editor on every Unix platform. At first vi's key bindings looked crazy but after a while they felt just natural.
I recommend God mode. On my Thinkpad X200S I bind the mode switcher key to the right mouse button, which is easily reached by the right thumb. With God mode you don't have to relearn key bindings, you just no longer need to hit Control and Alt.
Why should people use emacs to run applications when the shell already does that just fine? Just use the shell and you can run applications in any language you want rather than having to stick with elisp. If you want to constantly switch between applications, you can use tmux or simply your terminal emulator's tabbing functionality. You can even switch between GUI applications instaneously if you use a tiling window manager like XMonad.
Emacs is my shell. You don't have to stick to elisp either, you just need a little elisp glue. (The Emacs interface for the GNU Guix package manager, for example, is written in Guile Scheme for the most part.)
Emacs is trivially extensible and whatever I make it do can be used in other sub-applications. I can evaluate code wherever I want and change the system at runtime. It's quite a different feel compared to having "unglued", ununified applications.
Emacs is a fine editor to use until you write your own. It's the only way to make your primary interactive tool work exactly the way that you think it should.
Live coding environments typically include a text editor. Sometimes as in the case of Praxis, its possible to change the behaviour of the text editor while you use it.
I wrote it for myself mainly, so a lot of the features are undocumented and hidden away. But you can have a look at fnkeys.lua, editor.lua and keymap.lua to get a general idea. These are in prods/syntax2015continued. You can bring these up in praxis and make whatever changes you like to the live system.
I like the idea of making it keyboard and buffer driven to an extreme, like the Commodore 64. For example, one simple technique I like is to "inject" code into the current buffer to place objects:
function makeCamPosSaver()
local x,y,z = getCamPos()
x = math.floor(x)
y = math.floor(y)
z = math.floor(z)
local s = "setCamPos("..x..","..y..","..z..")"
print2(s)
end
Then calling makeCamPosSaver injects a bit of code that will move the camera back where it was when you called it.
Another example: pressing F3 creates a new buffer where you are supposed to fill in a string with what you are searching for. When you run that buffer, it will switch to the old one that spawned it, and move the cursor to the next occurrence of the search string.
There are more creative ways to use this that others could come up with I'm sure.
I am glad that you have enjoyed your use of emacs, but no, I was being literal. A text editor is not a complicated piece of software to write from scratch.
Writing a text editor for a POSIX system with an xterm-compatible terminal took up about 7100 lines of C and was entirely straightforward. I made it very easy to interact with shell pipelines so I didn't need any features that are already present in the surrounding environment.
I 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.
This entirely depends on the set of packages you configure. I was able to make vim plenty slow by running too many plugins over too many files. I made vim lightning-fast by keeping things simpler. I did both of the same to emacs.
Actually, advanced IDEs like Idea only feel fast because they do most of the stuff asynchronously. Afaict neither vim nor emacs are excessively good at it.
I also love Emacs. I bought an original Emacs Manual for Richard Stallmam (late 1970s?) and still spend a ton of time inside Emacs every day.
I do,use other editors like TextMate and GEdit and the JetBrains IDEs sometimes. Right tool for the job. Emacs really excels for Lisp languages, for me that is Haskell, Common Lisp, Clojure, and Scheme.
http://www.sachachua.com is the blog of an avid Emacs user who promotes its use, and the plus is that there's a lot more interesting information there too as she documents her journey.
I try Emacs around once per year. The problem is it's so slow under OSX. It's much faster on my 2007 iMac running Linux than 2013 mbp. I even tried to run it under X-Quartz but still performed poorly. What can I do?
Just fyi, I also have huge issues with helm performance on my system. I tried the (setq gc-cons-threshold 100000000) from your init.el, and it didn't help at all.
I'm running emacs 24.5.1 with a recent helm on a 2-core 64-bit Linux system with 8 gigs of RAM. Bringing up helm-mini takes about 7 seconds for me, as does getting a response from helm-apropos when I type a single character or even type control-g to close it.
The rest of emacs runs fine. It's only helm that has anything remotely like this severe performance problem.
I've never used helm, so I don't have any experience there. I can't say that I've felt like I'm missing anything by not using it though.
I'll give it a try on my system, maybe that will give some insight.
--
update
--
I installed a bunch of helm stuff, it didn't slow anything down for me. try doing a clean pull from my repo and then adding your helm packages and see if that helps.
What is the "end result"? Is it just a text file containing characters in the desired order? Is the journey at all important or is all that matters reaching the goal?
I have a feeling that most people commenting here have not actually read my blog post; or maybe I failed to get my point across. Comparing Emacs with other text editors is a different topic. I hardly even mention text editing in the blog post.
Using Emacs for text editing is what I do because I'm already using Emacs for everything else (or was it the other way around?). It makes a difference for me because I can use the same malleable system for everything that can be mapped to some text representation. Emacs modes enhance that text representation, make it alive (e.g. hyperlinking in man pages, shells in Emacs, REPL interactions, M-x compile, etc).
It depends on what you want to do and what you expect. As I wrote in my blog post, Emacs is more to me than just a text editor, just like a browser is more to many people than just an HTML viewer.
I don't use Emacs on the command line; I use a graphical instance. I usually only have two programmes open: Emacs and a graphical browser (eww still needs some work).
Being able to use my very own Emacs that has been molded according to my habits for pretty much every task is a great feature, but it only becomes obvious after some time of continued usage.
You are missing some things, yes. A more capable editor is well worth some time invested.
I'd recommend learning whichever of vi and emacs is better represented amongst those you can easily go to for guidance.
If you choose vi, I also recommend http://vim-adventures.com/ - I have only played through the free bit, but if the quality is consistent I expect it's worth paying for if you want to learn vim and have a bit of fun while you're at it.
This 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.
There are some instances where dynamic scope actually is not as insane as it may seem. Although the paper is probably dated and opinions have changed since then I can still understand that there are practical reasons to dynamic scope in some instances:
All my own Elisp code uses lexical scoping by default and I don't trust myself enough to use dynamic parameters liberally in my code. But I don't think it's entirely unreasonable to have the ability to dynamically override internals.
Oh, definitely. Even extremely statically minded Haskell offers a dynamic scoping construct: the reader monad. (As Haskell is wont to do, this monad infects every user of it with a `tag', just like IO does. No silent surprises from dynamic scoping here.)
Indeed! I was actually raised by a pack of vims, and I like both editors. I used to use evil-mode in Emacs for a while until I reset my muscle memory by switching to dvorak.
I have no interest in old flame wars. Our generation has its own set of flame wars to fight ;)
