I usually use Murky, dvc or some other shell for Mercurial. Not always though, for various reasons, and when running hg status I'm always frustrated when copy and pasting file names. bzr provides neat, non-cluttered lines that can be copied whole to get a file name without a hassle, but hg takes the traditional one-character prefix approach to status display and as a result makes you manually select a part of a line instead of just grabbing a whole line.

So I wrote a small extension to help. Meet hg-status-sections.

The biggest problem with Objective-C's @synthesize directive for properties is how difficult it's to augment the synthesized code. You often need to add logic to a property setter, but while you're adding it, you're losing the probably correct implementation Apple's code creates for property flags like atomic and retain.

At the moment, when you synthesize a readwrite property called foo you get a setter method called setFoo. If you need to add logic around it, you can either store the value in a private property and add a public property with a different name or use a subclass. Both are a bit of a hassle. Usually I just end up writing my own method, including the logic for implementing the modifiers correctly.

In an ideal world the language would support something like around/before/after methods in CLOS, but those features are rare. There's a simple way @synthesize could make things easier without requiring massive changes to the runtime. It could give you for both the getter and setter two methods. There would be the public methods they create in the current implementation, but there'd also be methods with names like __synthesized_property and __synthesized_setProperty. The public methods would rely on the semi-private methods to actually implement all their logic. Then if you needed to add logic around the accessors, you could override the public methods and call the semi-private ones to get access to the synthesized accessor logic without jumping through hoops or risking getting the implementation wrong.

There are several small things Emacs could be doing to make it nicer to write code. One I was missing was making it possible to go with one press of the return key between braces in a C derived language from this:

if (test) { }

to this:

if (test) {
   <-- insertion point here
}

That is, pressing return before the closing parentheses, brace or bracket should move the closing character two lines down, indent it properly, and move the insertion point to the new empty line in the middle and indent it property. The way TextMate does it.

Here are a few of elisp functions to accomplish this:

(defun char-isws (c)
  "Is character c a whitespace character?"
  (or (char-equal c ?\ )
      (char-equal c ?\t)
      (char-equal c ?\n)))

(defun line-next-non-ws ()
  "Return the next non-whitespace character on the current line or nil."
  (let ((cc (char-after)))
    (if (and cc (char-isws cc))
        (save-excursion
          (if (re-search-forward "[^[:space:]]" (save-excursion     (end-of-line) (point)) t)
              (char-before)
            nil))
      cc)))

(defun newline-and-indent-extra-for-closing-paren ()
  "Insert a newline and indent. If the next non-whitespace character is a closing paren, insert two newlines and indent the two  new lines correctly, placing the point on the first of the two new lines."
  (interactive)
  (let ((nc (line-next-non-ws)))
    (if (or (null nc)
            (not (= (char-syntax nc) ?\))))
        (newline-and-indent)
      (progn
        (just-one-space)
        (newline-and-indent)
        (newline-and-indent)
        (previous-line)
        (indent-for-tab-command)))))

Now you can bind return to newline-and-indent-extra-for-closing-paren in a suitable language keymap. I've been using this with scala-mode and it works well there.