[climacs-devel] paredit.lisp, regularization of motion commands, and more

[Taylor R. Campbell]

I started working yesterday on a paredit.lisp for Climacs.  This is
the first time I've ever looked very deeply into it, and I've
encountered a number of small issues which I discussed briefly on IRC.
The most prominent of these is the irregularity of the motion
functions and commands, such as FORWARD-EXPRESSION; there are a few
other minor things, too.

Right now, there's a bit of a hodgepodge of motion commands, scattered
throughout different packages, with different parameter conventions
and such.  Some accept a syntax instance parameter; some accept a
parameter for the number of motions; none, I think, actually accept
both.  Some examples are:

  (CLIMACS-BUFFER:FORWARD-OBJECT <mark> &OPTIONAL <count>)   [generic]
  (CLIMACS-BASE:FORWARD-WORD <mark> &OPTIONAL <count>)      [function]
  (CLIMACS-SYNTAX:FORWARD-EXPRESSION <mark> <syntax>)        [generic]

Based on Edwin, MIT Scheme's Emacs clone, I've thrown together a much
more regular pattern for these operations and couple macros for
automatically generating generic functions of the signature

  (<mark> <syntax> &OPTIONAL <count> <limit-action>),

where the <limit-action> specifies what to do if the motion cannot
proceed due to the buffer or other limit.  For more details, see
<http://mumble.net/~campbell/tmp/motion.lisp>, which is a collection
of what I have started to build into the rest of Climacs locally.

Another problem fixed in motion.lisp is that UP-LIST (there called
FORWARD-UP) doesn't work correctly if it is at the limit of the
enclosing list, since it will take the parent of *that* list and go to
its end offset.  The fix in motion.lisp is rudimentary, and it ought
to be done better, but it works for the purposes of paredit.lisp, the
first two operations of which (Open Parenthesis and Close Parenthesis)
I got working last night after my initial foray into Climacs.

In order to implement these, I also wanted to use several functions
whose symbols are only internal to CLIMACS-BASE and CLIMACS-GUI.  Is
there any reason that these are not exported?

  CLIMACS-GUI::BACK-TO-INDENTATION
  CLIMACS-GUI::DELETE-INDENTATION
  CLIMACS-GUI::INDENT-CURRENT-LINE
  CLIMACS-GUI::CURRENT-POINT              (These two are unnecessary,
  CLIMACS-GUI::CURRENT-BUFFER              but convenient.)
  CLIMACS-BASE::FORWARD-TO-WORD-BOUNDARY  (Motion.lisp uses these two,
  CLIMACS-BASE::BACKWARD-TO-WORD-BOUNDARY  not paredit.lisp.)

The last two, and the current definitions of FORWARD-WORD &
BACKWARD-WORD, also posed a bit of an annoyance as I was using
Climacs: they skip over hyphens, because hyphens are constituents in
the sense of CLIMACS-BASE:CONSTITUENTP, which is really a predicate
for written Lisp symbols.  Would it not make more sense to have
several generic functions that take objects from buffers and syntax
instances to classify the objects?  I'm thinking:

  WORD-CONSTITUENT-P
  SYMBOL-CONSTITUENT-P
  LEFT-BRACKET-P
  RIGHT-BRACKET-P
  MATCHING-BRACKET

Any thoughts & comments on any of these ideas?  (Give me another week
to hack and I can have patches to implement these within Climacs's
source rather than in my ephemeral Emacs buffers.)