Hardcoding parameters into function names

Code seems to sometimes be slightly easier to read if information is pushed out of the arguments and into the function name.

I.e: Set(‘Color’, red) —> SetColor(red)

This has the nasty effects of making one’s APIs rather large, but if used sparingly it:

1. Makes APIs more discoverable – the naming of function now contains information which would otherwise be in the usage of functions
2. Makes code slightly easier to parse – Mostly just because we have removed an argument from the argument list
3. Make code using the API slightly easier to write

Bear in mind that this statement is heuristic and general… so is probably wrong most of the time. Also I kind of suspect that all of this may immediately become false when two arguments rather than on are pulled out of the argument list and into the functional name.

This statement is, however, particularly true when your different operations take slightly different data as one of the other arguments vary.

Emacs version control

I discovered how emacs version control worked today… and was duelly impressed. (Having previously thought that it didn’t work at all well – guess this means I should learn to read manuals).[1]

Regardless, emacs comes with a unified version control front-end which supports back-ends for most version control systems : I believe this includes git, svn and bzr).  This can do most of the things that one wants to do.

One of my only irritations is that one can’t revert individual lines of the diffs that it shows.

Summary for the impatient

Emacs version control is wonderful, I’m dim for not realising this earlier. To make it work do the following:

C-x v = in a file for a diff

To submit:

C-x v d <TOP LEVEL DIR> to get a list of all modifed files, then mark everything (hold down m) and press C-x v v.

If you want to see diffs for individual files press v=.

[1] As an aside, one of the reasons I hadn’t found this out earlier was because I was under the false impression the mode help (C-h m) would show all relevant keybindings… I’m not quite sure why, C-h b is (strangely!) better for this purpose.

Searching multiple buffers emacs

In the past I’ve complained about emacs not being able to search multiple buffers for regular expressions, and I’ve resorted to using the additional package moccur.el. This was pretty good but had the irritating (though understandable) caveat that if you changed the text in one of the searced files then all the links from the output pane became slightly wrong.

However, I take it all back. I’ve just found that the standard FSF emacs has two functions which do what I want to do without these caveats. These allow one to search several buffers simultaneously for a given regexp and maintain links even if context is chaged… I’m not quite sure how I managed to miss this before – since the first thing that one would think to do if you wanted to search multiple strings for buffers would be to type “C-h a o-c-c-u-r-<ENTER>” and then search for multi… but I guess I’m just dim.

Anyway:

Precis for the impatient

In FSF emacs, you can search several buffers for a given string

multi-occur: – Search specified buffers to a string

multi-occur-in-matching-buffers: Allows one to search a subset of one’s open buffers or files specified as a regexp:

Given .* as its first argument this allows one to search all currently open files for a given regular expression.

Given a prefix argument and .* as its first argument this allows one to search all currently open buffers for a regexp.

Also (occur-1 regexp nil buffer-list) can be usefully adapted to search for other things.