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.
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.