() Barry OReilly <gundaetiapo@gmail.com>
() Thu, 18 Jul 2013 23:23:47 -0400

   The motivating idea is this: When reading Lisp, I find I pay
   attention to open parens (because foo is not (foo) is not ((foo)))
   and just the close parens whose opener is on the same line. When a
   sexp spans more than one line, I deduce the close paren from
   indentation.

I think this explanation might be clearer if you say "close paren from
the preceding sexp".  I only understood that nuance after playing with
the commands (which work fine, btw).

   If that's how we read Lisp, then why not edit Lisp that way: change
   the indentation and let the close parens adjust themselves to be
   consistent.

Well, here i have a different pov.  When i edit Lisp, indentation is the
last thing to fall into place (i.e., a "fixup" operation, via ‘C-M-q’);
i prefer to grok/munge whitespace-agnostic sexps first and foremost, via
the usual C-M-{SPC,k,f,b,n,p,u,d}, etc.  I include "grok" because i read
code actively, moving in and around it, watching what mic-paren bolds.

The commands you provide can be described as "(un)tucking the sexp at
point into the preceding sexp at the tail position", which translates to
adding-to /removing-from a function call an argument that happens to be
situated following that function call.  That's not something i do often.

But anyway, it is good to see hacking of this kind.  Don't stop!

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil