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

[Taylor R. Campbell]

   Date: Mon, 8 May 2006 15:12:03 +0000 (UTC)
   From: John Q Splittist <splittist at yahoo.com>

   Taylor R. Campbell <campbell <at> mumble.net> writes:

   > Right now, there's a bit of a hodgepodge of motion commands

   I think consistency is a great idea, and including the syntax in
   the signature is a win.

   I wonder whether it would be more useful for the functions (and
   quite possibly the commands) to return MARK on success, rather than
   T.

Any particular reason?  Usually you'll already have the mark anyway;
for those cases where you don't, the difference is between

  (LET ((MARK (COMPUTE-MARK-HAIRILY))
    (COND ((FORWARD-FROB MARK SYNTAX 1 NIL) ...)
          ...))

and

  (LET ((MARK (FORWARD-FROB (COMPUTE-MARK-HAIRILY) SYNTAX 1 NIL)))
    (COND (MARK ...)
          ...)),

except that the latter is less general, since it doesn't allow
references to the mark if the motion failed, so you'd have to go for
something longer or something identical to my current suggested idiom.

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

   In the case of CLIMACS-GUI, only because it's never really had any
   clients before. (That's why I split Swine into swine.lisp in the
   LISP-SYNTAX package and swine-commands.lisp in the CLIMACS-GUI
   package; it was a quick hack.)

So would you recommend just exporting (most of) them, then?

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

   I'd hate for this kind of thing to turn into the monster that is
   emacs syntax-tables just to save a bit of typing from having to
   reimplement the word motion commands in syntaxes with a different
   idea of what amounts to a constituent or a bracket.

Well, one property of GNU Emacs that I find to be very nice is that
all these motion commands work everywhere, with special meaning only
where appropriate (e.g., expression motion in Lisp).  It would be nice
to provide this property in Climacs, too, by reasonable defaults, I
think.

   The word motion commands in basic syntax should obviously use an
   'English' notion of what amounts to a constituent. I would then
   prefer that lisp-syntax implement a method that uses the lisp
   notion of constituent etc.

Actually, I disagree here.  While some highly syntax-specific
operations, such as the incremental parser should of course look at
the Lisp (or Prolog, or whatever) meaning of constituents, I still
want word commands to use English word constituents -- I frequently
operate on words within identifiers separated by hyphens, for example,
which is what made me think of this in the first place.

   I would favour this strategy over one that tried to create a
   super-generalised word motion function that depended on the method
   equivalent of regular expressions to come up with the actual
   movement for a syntax. (But that's just me.)

While one always can specialize on FORWARD-ONE-WORD and FORWARD-WORD,
I think it would be simpler to provide a default method that used a
simpler generic function such as WORD-CONSTITUENT-P.  Then, if the
meaning of `word constituent' is different in some syntax, but not the
meaning of `word' as a whole or motion over words, that syntax can
specialize WORD-CONSTITUENT-P without having to duplicate an entire
FORWARD-ONE-WORD method that differs only by the predicate of word
constituents.

As for brackets, I actually want something a bit higher-level, which I
need to think harder about.