I used BRIEF for a few years until I moved away from strictly Windows development so I moved back to Emacs. Columnar editing was something I missed so much! But now that I've been away from it, it's hard for me to recall what I used to use it for.
Occasionally I do find that I wish I had it, but I remember feeling so crippled without it for a long time! So, can't wait to get back into it again now that it's available. I think it's one of those things that you start using it and find more and more things to do with it as time goes on. Just my $0.02 anyway.
I can already kill (C-x r k), yank (C-x r y), replace (C-x r t) text in rectangles, insert text after the rectangle (C-x r z) or at the beginning of all the rectangle lines (C-x r a) or their ends (C-x r e).
What else is there?
I'm curious to know which things are easier for you with 'C-x space'.
The annoying thing about C-x space, is that it used to do something completely different (set gud breakpoint), but I digress.
Really? Upon reading the release notes, I was excited that I'd probably be able to just use commands like C-w or C-x u to act on rectangles. Sad to see it won't be the case.
From the manual:
The command C-x C-k r (apply-macro-to-region-lines) repeats the last defined keyboard macro on each line that begins in the region. It does this line by line, by moving point to the beginning of the line and then executing the macro.
At one point there were only two web browsers in the world, one was Mosaic (Mozilla is short for Mosaic Killer) and one was W3 (the emacs web browser).
* Email (gnus)
* NNTP (gnus)
Come to mind offhand.
It's a surprisingly nice experience. You can really easily pull archives, nntp clients tend to handle threading well, etc.
I really prefer the keyboard navigation and all the niceties offered by Thunderbird than the web groups interface, each with its own set of allowed actions, mostly without keyboard navigation.
There was a project to integrate webkit into an emacs browser mode but not sure where that stands.
w3m is an external program, which Emacs has a wrapper for http://www.emacswiki.org/emacs/w3m
The problem is that it isn't a good enough Lisp engine to be very good at anything beyond the great text editor, which it has been since the early 1980's.
I use Emacs as a text editor, which means I use it to edit anything that has text. Granted that is a huge part of my computing needs.
I don't want Emacs to be able to do anything. I already have an operating system and a text editor.
"We used the same idea here (in the hybrid technique), that most of the editor would be written in Lisp, but certain parts of it that had to run particularly fast would be written at a lower level"
That's the beauty of Emacs. Considering that he built it in the early 80s, you have to wonder if the whole thing couldn't be written Lisp today.
I use emacs as a source navigation and exploration tool, even more than for text editing. Its ability to run code customized to the language and projects I'm working on is far more important than its ability to edit text.
I actually don't like a lot of its text editing functionality, and had to work hard to get things like selection, tab indenting, scrolling etc. to work in a way that didn't drive me up the walls. I had to give up on virtual space, one of the things that stopped me learning it 10 years ago. It's also very hard to record keyboard macros without accidentally cancelling (I tend to press C-g reflexively when I type a wrong shortcut); I use multiple cursors these days instead, even though that is much riskier / harder to use when you can't see the whole buffer / all edit locations on screen at once.
A browser, I don't really need that per se - unless it's linked to library documentation. But it's hard to integrate modern docs without at least understanding HTML, if not HTTP. So I can see the need for a browser implementation.
If you only use Emacs as a text editor, that's fine for using a subset of it. Just like a casual user uses Linux without never using its underlying tools in the terminal.
> saying that Emacs is only a Lisp interpreter implies that the entirety of the text editor is implemented in Lisp, which is clearly not the case.
With this argument, I guess Python is also not an interpreter because clearly it is not entirely written in Python.
I couldn't get logins to bitbucket work with eww, because it seems it is not sending the referrer headers. I couldn't find any way to turn it on..
Hah, seems like an argument for vim.
That will render the project a lot more accessible for new developers and ad-hoc bugfixing.
It is remarkably fast compared to the bzr repository. ESR's conversion takes 10 hours to complete.
1) Download from http://www.gnu.org/software/emacs/
gpg --keyserver pgp.mit.edu --recv-keys A0B0F199
gpg --verify emacs-24.4.tar.gz.sig
./configure --with-jpeg=no --with-gif=no --with-tiff=no
Easy-peasy!!! (But, clearly, not as secure as verifying the sources and compiling yourself.)
edit: So this did work, I used the .tar.xz with sha256 47e391170db4ca0a3c724530c7050655f6d573a711956b4cd84693c194a9d4fd. One thing to note is that the old 24.3 stable formula has a bunch of patches applied that are no longer required, so you need to edit those out as well (this area: https://github.com/Homebrew/homebrew/blob/master/Library/For...).
For 2 or 3 years now, whenever I have compared the two, the current version of "Mitsuharu" Emacs has always had fewer Cocoa-related bugs than the current (release) version of "FSF Emacs" (i.e., Emacs without the professor's patches applied). I am writing this comment because this Mitsuharu fellow seems very reticent about promoting his own (excellent) work.
Learning emacs won't automatically give you a huge productivity boost the way learning vim does. Vim is this blazing fast editor; it's been designed from the ground up to be good at editing text. If your goal is to increase your productivity, I'd say invest time learning vim advanced features, like jumps, macros, registers, and the plethora of other things I don't know about.
Emacs is not about speed. It's about control. It's a fully customizable environment to manipulate text. You can use it to edit prose, code, scientific formulas, but also emails, IRC/Jabber clients, clients for virtually anything with a REST API. Here are some of the use cases that make my work easier using emacs:
+ Evaluating pieces of code at once. I write a lot of Python. Most REPLs out there allow editing of one line at a time. emacs allows me to fire a python interpreter and evaluate regions (multiline function definition, or data structure) at once. Similar features exist for other "dynamic" languages.
+ Better code review workflow. I receive code review requests via email immediately inside emacs. I can play with the diff files, the source files. I can make modifs or run the code without leaving my editor. And since the code review system has an HTTP API, I can even post my comments and votes back.
+ Org-mode (http://orgmode.org/). I would use emacs for this module alone. It's a note taking system that can easily transform into an agenda, todo lists, memo, document markup, tables (oh, the org-mode tables!), ...
Basically, to answer your question: I think you'll get a lot of benefits from emacs if you enjoy customizing it and integrating it to your workflow. If you don't like spending time customizing and prefer something that will just make you write text (well, code and configuration files) faster, stick to vim and spend this time learning advanced commands.
Emacs allows you to use basic commands like any other editor, but to be blazingly fast you need to use the controls explained in the tutorial (plus some extra stuff that you can pick up later). The tutorial is not optional if you want to be blazingly fast.
It's probably true that if you come from vim to Emacs that you won't get a huge editing boost as such, but I think the reverse is probably also true.
And what do you use for code review workflows?
Vim or Emacs are really powerful tools that will serve you well over your entire career, so getting adept at them will pay dividends. It's similar to learning how to touch-type, or typing with a faster WPM, in that it's not a pre-requisite to becoming a good and productive developer but it certainly helps.
Emacs is my personal favorite editor, and I've found that the more adept I get at using it, the easier it is for me to get into "flow" and be productive. I don't use my brain's CPU cycles to fumble around trying to manipulate text as much, since through repetition and muscle memory I can work at it effortlessly (compare that to someone who has to two-finger peck while programming).
Similar to other powerful tools though, becoming good takes practice and a time investment. But I would argue that the initial upfront investment will pay off in the long run.
TL;DR: Yes, absolutely. Learning Emacs (or Vim/SublimeText/Eclipse if that's your choice) well will definitely boost your productivity in the long run.
The way you can refactor whole projects at once etc is amazing. (This is partly related to Java being static and uncool as well. : )
But it's also useful for things like bash or OSX interfaces too, since they use the same common keybinding scheme.
The emacs keybinding are used a lot of places eg: ^a to begining of line ^e to end of line is used everywhere (even the url bar of firefox/ chrome).
(verbose typing is uncool, though)
No. Although I first used emacs roughly 22 years ago so my memory might be rusty, the learning curve was extremely steep. Its not a GUI app with low maximum performance but very short learning curve, its more like something you'll have to mess with for a month to year to wrap your brain around. Its like learning dwarf fortress vs angry birds. In the very long run you'll probably like DF more, but not for the first day / week / month.
I beg to disagree. I learned me an emacs around the same time period (mid 90's). I don't remember the learning curve to be that steep. I started by doing the tutorial. If you download a GUI emacs (e.g. from http://emacsformacosx.com/ ), and open the program, you'll see a mouse clickable invitation to take a tutorial. Do this. Don't take shortcuts. Just spend the one or two hours and go through the entire tutorial complete with practice exercises.
Or if that's intimidating, start by reading this gist:
You can "rise above" by using emacs but its going to take a lot more than learning a different keystroke to scroll the screen. Learning all the features of your language mode, its debugger integration, integrated refactoring tools, project tool integration, it all takes time, and those are the areas where you get huge productivity gains when you put in the time.
I agree you are correct that the FIRST step is the tutorial but that won't provide any performance gains over any other bare text editor.
I also do a lot of iOS development, and, I do 95% of editing in Xcode, and 5% in Emacs. A nice thing about Emacs is, if you're on a Mac, is that Mac OS uses most of Emacs' movement keybindings, so even when I'm in Xcode (or any other app for that matter), I can still use my Emacs muscle memory.
I'm not that young; 6 years ago I was 30, and I'm very happy I decided to learn Emacs; no regrets. It's still paying dividends today and will continue to for the foreseeable future.
Also check my other guides, even just to see Emacs's awesomeness: http://tuhdo.github.io/
I'd agree that evil mode is quite nice, and emacs seems like something useful to know. It really depends what you prefer. I'm trying out emacs specifically for the formatting plugins as vim seems to fall behind in that regard.
What you should perhaps be more concerned about is whether you will be able to go back to a plain text editor, once and if you choose to go down this rabbit hole..
In Emacs 23 and below (for as long as I've used Emacs), I would change buffers by hitting F10-b (F10 brings up menu, b is shortcut for Buffers).
Then there is a nice little list of open buffers and the first letter of the filename is usually the shortcut to switch to that buffer.
This made it really fast to switch back and forth between multiple files (I want to go to index.html == F10-b-i ; now I want to switch back to about.html == F10-b-a), it was very simple.
Emacs 24 changed that behavior and so the quick switching between buffers based on the first letter of their filename went away.
Does anyone else know what I'm talking about? Is it possible to get the previous behavior in 24? I'm slowly finding packages that won't compile in Emacs 23 anymore b/c they depend on new Emacs 24 elisp functions. I only ever use Emacs from inside a terminal (emacs -nw), so that's why I'm navigating buffers by the F10 menu.
EDIT: Well, I may be an idiot. I just downloaded the latest 24 build and it seems to be working as before again! Not sure when this changed, but maybe this is now a non-issue. I feel a bit silly, but maybe this will help someone else?
It should be just an M-x package-install away at this point
Edit: Seriously, people? You take the time to downvote and not to point in a direction to contribute to make Emacs better? So much for the attacks on Stack Overflow and its strict policies and policing... And anyway, how off topic is this comment? Peace.
 -- http://emacsformacosx.com/
 -- http://emacsformacosx.com/builds
Short version: Lunaryorn: "I used to get them from Emacs for Mac OS X, but now I use Homebrew, because it supports more libraries, notably GNU TLS for encrypted network connections.
All in all: Use brew install emacs --HEAD --use-git-head --cocoa --with-gnutls --with-rsvg --with-imagemagick :)"
EDIT: Well, now that I've read that in full, I'm thinking of giving the author's conclusion a try:
> All in all: Use brew install emacs --HEAD --use-git-head --cocoa --with-gnutls --with-rsvg --with-imagemagick :)
What ! Anyone has screenshots of that?
Is there a windows release somewhere?
It's from an early version though (over a year old)
24.4 is not yet there though.
Also, is this display limitation a function of the OS? In which case, shouldn't Cocoa/GTK or other versions not have this issue and be able to actually embed nicer rendering in there with nice fonts?
Is it? I'd much rather have proper HTML rendering in another window than a kludge "in my editor".
On my Mac for example, the text in Emacs is just as good looking (and in fact is indistinguishable from) the text in a native Apple application like TextEdit or Terminal.app.
Either the resolution of this screenshot has been scaled down in a way that makes diagonal lines jagged, or this particular Emacs has been configured not to use anti-aliasing of text.
Some Linux users prefer or at least are used to it that way.
On X, anti-aliasing (in the form of XFT) did not become available in an Emacs release till the relatively late date of Jul 2009. (It became available in pre-release versions of Emacs about 15 months before then.)
I am not someone who tries to do everything within Emacs (yet?), but this seems like something that might be able to fit nicely with this kind of style, since I can restrict myself to only using Emacs and terminals for developing and reading online documentation. Does anyone enjoy working/developing like this?
 Yes, I see the slight contradiction in wanting to do things in simpler software, and then suggesting doing those simpler things within Emacs. :P
The browser is for looking up online documentation not available in your local machine. For example, sometime a man page is not available in my local machine. I can invoke a google query right inside Emacs and open it immediately without involving heavy weight browsers.
It is really nice to read online book like Practical Common Lisp: http://www.gigamonkeys.com/book/, and directly copy the code and paste to your REPL without ever leaving Emacs.
There used to be a bug in earlier emacs Versions requiring a Patch for proper fullscreen. Have not tried this for a while, but now it seems to work nice and smooth.
I want to start using Emacs, but starting with a blank slate leaves much to be desired. Especially when a someone new to Emacs doesn't know what's available or what can be done or how.
Here is some discussion about how scary starter kits can be too, and some advice on learning emacs: http://www.reddit.com/r/emacs/comments/1udtd1/starting_emacs....
If you're interested in Emacs for its extensibility then I would consider it a worthy investment. Go through the tutorial, find out how to query docs, extend keybindings and modes and things like that, and then I would recommend my Elisp programming guide: https://github.com/chrisdone/elisp-guide
One cannot easily run ssh from a shell in windows emacs. I have found that I cannot push to a bitbucket repo that uses http authentication too from the shell. But if I run them from a cmd window, these works fine.
What is the technical issue that is preventing emacs from fixing this?
Except they don't. File-name completion replaced all backslashes with forward slashes, thus breaking cmd.exe's built-in commands. I reported a bug; it started a short discussion; i was asked whether I had to use cmd.exe (YES, I have reasons for why I MUST use it); nobody really acknowledged it was a bug; the discussion died off in talk about some internal details. (The 24.4 binary package is not yet available for windows so I couldn't test it.)
See the thread here: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8132
And as far as I saw, none of them provides a working auto completion in the context of remote file system. Another thing is that I cannot push to a remote repo using http authentication.
1) Windows employs a very different model for console IO and shells in general. It's a job to do it right.
2) You haven't contributed a solution yet.
I wrote a few introduction guides to Emacs and its ecosystem: http://tuhdo.github.io/ . The guides do not include evil-mode though, as I use Emacs key bindings. But installing evil-mode is easy, and you can immediately use Vim key bindings for editing.
The HTML rendering engine (shr) was originally written as part of the Gnus project for exactly that task: To render HTML in RSS and email. The browser (eww) just adds http support via url.el and a user front end.