Hi-lock lets you specify regexes to highlight anywhere in a file; it's like domain-specific font-lock.
It's astoundingly useful in code review. For instance, given a giant blob of J2EE web handler code, I can eyeball one handler, recognize the annotation mapping the method to URL syntax, and then punch in a hi-lock regex to light up similar annotations everywhere in the file, then glance through the whole file looking for color patterns. I can read any of those functions and recognize the code that checks "am I an admin", hi-lock it, and then quickly spot any function mapped to a URL that doesn't check admin credentials.
That's just one tiny use case. I used hi-lock so much I ported it into our web-based code review tool. I converted one person to Emacs just to get that feature (my office would be thrilled if someone could point out the vim package that does the same thing).
CUA column editing (CTR-SPC arrow-arrow-&c type-type-&c) is probably my #2.
Late edit:
Holy hell how do you forget magit! Magit is a near-complete UI for git; it figures out what git repo you're working from, and then gives you up-to-date status on the contents of your checkout, spots untracked files, allows you to visually stage your commits, gives you single-key revert and a browsable repo history.
Magit is one of the rare Emacs extensions that not only improves Emacs but also the external service it integrates with. I am actually a better git user (or, git is just better) when I've got magit running.
Occur also works nicely for this use case, as you can visit each place in order with C-x `. Actually, something like eproject-grep is even nicer, because you can visit every occurrence in the project that way.
I didn't know about occur, which is awesome and thanks. The benefit of hi-lock is that I can "read" code without actually having to "read" it.
Instead, I can either set myself up to look for patterns of colors (function --- red line --- shit no blue line!), or set myself to serendipitously discover things as I actually do read code.
I have never, ever, ever, ever figured out an Emacs "grep" that I liked enough to stop using find/xargs/grep from eshell.
I haven't, but I don't have a problem with grep, so much as I find there's exactly enough friction with Emacs grep integration to prevent me from ever taking advantage of it.
Presumably the friction involves the fact that you have to tell Emacs the command to run before entering the search you want to do, making sure that you type exactly the find | [e]grep command you want. Then, grep, egrep, perl, and emacs all use different regular expression syntax, so you're never really sure what to type, and you are bound to have to try a few times. (Quiz: how do you search for a literal paren?)
Ack solves this by using Perl regular expressions and a built-in include/exclude list, which is annoying because you'll have to tell Emacs to tell Ack which one to use.
eproject-grep abstracts away having to type any commands or enter an include/exclude list (since the whole point of eproject is to maintain that information), but you'll still have to guess whether it's going to use grep or egrep and type the regular expression right.
multi-occur will use Emacs regular expressions, but only on open buffers.
So I guess the solution is to use eproject to open the correct buffers, and then use multi-occur on them. I will implement that and see if I like it. Perhaps you might too.
I've been trying to figure out a good way to do this for a while in vim, and can't say I've found much. The best i can figure is something to this effect:
highlight LowVis ctermbg=233 guibg=233 ctermfg=240
syn region LowVis start="\s*log_" end=";" contains=LowVis oneline
Out of curiosity, do you use usually emacs for J2EE code?
I am an emacs user, but have been doing some J2EE stuff for the last few months, and have been getting really annoyed by the IDE's lately, and I was wondering if it was a wise choice to go with emacs for Java too.
I don't build J2EE apps; I just break them. We built our own code reviewing tool internally, which is what I use now, but I spent a few months reviewing things in Emacs deliberately once I learned about hi-lock mode.
I still do all my real dev in Emacs and have more than once put hi-lock to good use there.
Indeed. Java is only different from the rest of the world if you use Eclipse and think its defaults are sane. For everyone else, you write some sort of build script that builds your project, and that's as easy to run from Emacs as it is from anywhere else.
El-get can install and update elisp from git, svn, http, and EmacsWiki. (It also wraps ELPA and apt-get where packages exist.)
If el-get doesn't have a recipe for your favorite Emacs extension, please consider adding the recipe and pushing to GitHub. (It doesn't take long - most recipes are only a few lines long.) Don't forget to issue a pull request for the rest of us.
It takes about five minutes to take a library that isn't packaged and publish it on Marmalade, and then anyone can depend upon it.
el-get made lots of sense back in the day when package.el only supported tromey.com, but now that there's a community repository I don't see the point.
OK. My old complaints against package.el were as follows:
1. Packages need to be updated manually by maintainers. I can't use package.el to install the master branch of my favorite project on GitHub, or an old snippet on EmacsWiki.
2. Marmalade (the community repository) has licensing requirements for package inclusion.
> 1. Packages need to be updated manually by maintainers.
Yes, but considering uploading new versions can be done with M-x marmalade-upload-buffer, generally Marmalade encourages short release cycles. So there's not much reason to ever work from master unless you're hacking on it yourself, in which case you already have it checked out.
> 2. Marmalade (the community repository) has licensing requirements for package inclusion.
This is not specific to Marmalade since Emacs itself has licensing requirements. Every elisp library is a derivative work of Emacs itself, therefore it must be distributed under the same license.
EDIT: Perhaps you're thinking of elpa.gnu.org? That repository requires copyright assignment for libraries to be included, but Marmalade does not.
I think you're slightly confused about el-get's purpose: it isn't to replace package.el. el-get supplements package.el and provides options for people who want to run the latest and greatest versions of libraries, or who can't be bothered to monitor the odd elisp snippet and update Marmalade every time it changes.
Personally, I find el-get recipes so easy to install and create that I never use package.el at all, but that isn't the goal of el-get developers.
Here is an example recipe for el-get. I haven't tried creating uploading anything to Marmalade yet, so I can't compare the ease of use.
One last note: You may find that el-get lowers the barrier for contributing to libraries. If you find the odd bug in a mode you use, the source code is always checked out in ~/.emacs.d/el-get and it would be practically criminal to not fix it. With package.el, you have to reinstall the library first.
You're right, of course, but only because the Emacs community chose an inferior solution to begin with. Let the better package manager win. Don't tell people not to use el-get because it is so convenient that they wont use package.el anymore.
I love how every post on Stack Overflow that gets popular on Hacker News always gets closed by SO admins as "not constructive". It's like they really are annoyed when their stuff gets noticed by the world outside their walled garden. What are they - hipsters? "I was a fan of internet startups before they got popular, dude." It's bad enough on Wikipedia, which appears to operate on the principle that a megabyte of hard disk still costs $100, but on Stack Overflow it's just plain foolish.
Less cynically, Stack Overflow is about specific answers to specific questions. Any question broad enough to be interesting to a site like Hacker News is too broad for Stack Overflow, apparently.
Not always. The only question that the linked StackOverflow page can answer is "What Emacs features did a self-selecting set of StackOverflow users find particularly useful as of early December 2011". While it's quite possible that somebody might someday want that very specific piece of information, I can't blame Joel and Jeff for preferring that particular database-space had been used to record a workaround or explanation for some uncommon error message.
I've "only" been using it since 1998, but I always skim threads like this -- even lots of short articles -- because there's nearly always something new to discover! Sometimes it's hard not to gush, but it's just such an amazing and organic piece of software.
Org-mode is what finally converted me to being an emacs user.
I'd been searching for a lightweight, console/cli-mode outliner/task-manager when it occurred to me "surely emacs has something for this". It did, of course.
For several weeks I used emacs only for org-mode. Slowly but surely emacs started to take over my more and more of my editing tasks. Now I find myself not even bothering to launch X, but simply emacs from the Linux console (run level 3?). It's amazing how responsive a computer is when you're not using any gui at all.
I've since discovered that org-mode is pretty common gateway into emacs.
TRAMP. Being able to seamlessly remotely edit files and run remote modes.
At work I regularly edit files on 10-15 remote machines. But I never ssh to them and run an editor. Instead I'll just visit them through TRAMP, run Magit to commit stuff that I've done etc.
My coworkers often don't even realize I'm editing a remote file or working in a remote shell. It's really that seamless.
Of course, sometimes I forget I'm working remotely, and hilarity ensues. The worst episode was in a recent school project. I thought "oh, I'll just finish this on the train". And then, when I got on the train, realized I had actually been working remotely. Oops.
I use tramp as well, but can't say I like it. Blocking whole UI because of network problems, leaving garbage in the shell history on the machines I'm connecting to, getting confused (and hung-up) by different prompts. It's nice, but too volatile.
The single most useful Emacs feature is the design of Emacs as a platform for hosting ELisp. Without ELisp, and the OS and text editing services provided by the Emacs run-time, none of these extensions would be possible.
`ansi-term` is probably is for me. Integrating your terminal closer with your editor is really amazing. Using `multi-term` to make it easier to handle multiple terminals, and you've got a really nice integrated environment.
I wish the Windows Clipboard would implement a version of the kill ring. I really, really hate not having previous cuts and copies available. As a rather clumsy work-around I keep an emacs scratch file open on my task bar and copy stuff I might need more than once to it.
I haven't used Emacs, but I've worked with people who have, and the one thing that made me think 'wow' was this. So many times have I yanked something, deleted some white space or some such, and then lost it.
Oh yes. The only thing I wish vi had was a key that let you traverse these so you don't have to remember exactly how many yanks ago you yanked something.
plays the macro until it rings the bell (e.g. runs out of buffer space or tries to forward-search for a name that doesn't exist. This is great when you don't know how many times it needs to be run.
on a side note, whenever i asked such open ended question on stackoverflow, it would quickly get closed by some other user claiming that "there is no right answer" and the question must be closed. But there are so many great open ended questions on there that score so high among users. i guess it's a matter of luck that some anal retentive person doesn't get to it first?
It's not exactly luck. Until today this question hasn't been active since 2009, when opened-ended questions were permitted. Now that it's been bumped it'll be closed shortly.
I personally don't think that default is silly. I've noticed that some (usually less important) questions use y or n already; the yes/no is reserved for important ones. I don't mind having to type a bit more before recursively deleting a directory, for example.
For newcomers, C-g is a delight (it certainly was for me). Especially with the arcane reputation of Emacs, it was awfully reassuring to know how to get out of whatever unfamiliar function I'd fat-fingered myself into.
Well, it won't get you out of recursive edits. I remember visiting a coworker's machine before telling him about those, and the modeline was something like [[[[[[[[[[(CPerl)]]]]]]]]]].
ESC ESC ESC is a much better "get me out of here!" command to remember.
It's interesting that it's hard to explain, because the fingers will play the chord by themselves and I need to stop and think to know what I am actually typing.
C-x r k to cut a rectangle, and C-x r t to add one filled with, for example, the comment symbol:
Holy crap, thank you very much! Looks like cua-mode rectangle select might actually be the equal of Visual Studio's very straightforward rectangle selections...
`C-u SPC` which pops the mark. This allows you to go back to different places in your buffer quickly. For example, if you are editing a program and need to add an import statement, you could do it like this: `C-SPC M-< [add your import] C-u SPC` and you'll be back to where you were editing.
If you are using transient-mark-mode, you can use `C-SPC C-SPC` to active and deactive the highlighted region. That'll still leave a mark.
for me it has to be comint mode and every mode that wraps comint. I run M-x shell all the time, being able to use all my favourite editing commands to go back through shell history is just killer.
I like idomenu, which lists variable/function definitions in your file. When you combine it with ido-menu, it's magic. Bind it to C-c s, and you get a list of symbols you can navigate extremely fast.
The downside is that if the symbol locations change in a file, you'd have to refresh it. :(
Too hard to pick one, it depends on the task.
Maybe I'd go with M-x Occur.
Other candidates are regex i-search, registers, yasnippet, kill/copy/(insert)string-rectangle, etc etc.
It's definitely up there for me, which I find amusing as I thought it was such an odd action to mention early in tutorials - and yet it's so damn handy once you get get it in muscle memory.
I can't switch away from Notepad++ to any editor that lacks instantaneous, no-hassle (no extra key presses), buttery smooth current buffer word auto-complete.
Hi-lock lets you specify regexes to highlight anywhere in a file; it's like domain-specific font-lock.
It's astoundingly useful in code review. For instance, given a giant blob of J2EE web handler code, I can eyeball one handler, recognize the annotation mapping the method to URL syntax, and then punch in a hi-lock regex to light up similar annotations everywhere in the file, then glance through the whole file looking for color patterns. I can read any of those functions and recognize the code that checks "am I an admin", hi-lock it, and then quickly spot any function mapped to a URL that doesn't check admin credentials.
That's just one tiny use case. I used hi-lock so much I ported it into our web-based code review tool. I converted one person to Emacs just to get that feature (my office would be thrilled if someone could point out the vim package that does the same thing).
CUA column editing (CTR-SPC arrow-arrow-&c type-type-&c) is probably my #2.
Late edit:
Holy hell how do you forget magit! Magit is a near-complete UI for git; it figures out what git repo you're working from, and then gives you up-to-date status on the contents of your checkout, spots untracked files, allows you to visually stage your commits, gives you single-key revert and a browsable repo history.
Magit is one of the rare Emacs extensions that not only improves Emacs but also the external service it integrates with. I am actually a better git user (or, git is just better) when I've got magit running.