[climacs-devel] keybindings (was one-character patch to gui.lisp with-input-context call)

[Daniel Barlow]

Robert Strandh <strandh at labri.fr> writes:

> That would be great.  If at the same time you could think about what
> the Climacs equivalent of mode-specific key bindings would be, that
> would be even better.  

Some points arising from discussion on irc, and a few other things
that occured to me:

1) An emacs 'mode' is typically two things, really: it has a keymap,
and it also decribes the syntactic properties of the text in the
buffer being edited (at least as far as is necessary for colourising,
indentation etc).  Most emacs modes do the latter in a 'sloppy'
fashion with regexes instead of the full-blooded parsing that climacs
does, but nevertheless the intention is there.

It would probably help to separate these concerns in climacs.  If apps
like slidemacs or tabcode are typical, it's going to be a common
requirement that there are two different representations of the same
buffer shown simultaneously in different windows.  These windows are
both representations of the same buffer but will (in general) each
want their own keybindings.

2) I'd like to see if it can all be done with data structures that are
easily inspectable to find out what the bindings are.  A big part of
emacs learnability is that you can prod around in this way to find out
what your new mode does.  command-tables + accelerators meet this
requirement; clos dispatch from (gesture pane syntax) to command
doesn't.

3) I think I'd like to try a command-table associated with each
pane-in-which-editing-is-done.  This would usually inherit from
another table associated with the buffer syntax, which in turn would 
inherit global bindings.

This is probably going to mean that most of the
things-that-were-modes-in-emacs will need a subclass of
pane-in-which-editing-is-done as well as a syntax.  

4) The point was raised that if we go with (3) above, a
pane-in-which-editing-is-done may want to suppress bindings that it
inherits from a parent table.  For example, slidemacs slideshow mode
may not want to have lots of self-insert keys.

This is an interesting question insofar as many of the modes in emacs
that don't allow keyboard entry of characters (e.g. dired, gnus summary
buffers) are the kinds of things that are probably outside scope for
climacs and would be better implemented as clim apps of their own.  On
the other hand, climacs is a sequence editor not just a text editor,
and in any setting where the objects being edited are unlike
characters, self-insert is not going to be a really useful concept.

Maybe some of the need for suppressing bindings would go away if 
self-insert for "normal" keys wasn't part of the global command-table,
but was provided as an extra table that a pane-in-which-editing-is-done
can inherit from.  Remember that command-tables can inherit 
from more than one parent, so in principle we can have as many mixin
tables as we like, and in practice as many as we can cope with.

Perhaps also it'll be the case that a command-table for a syntax will
provide commands (com-goto-definition) but not accelerators, and leave
the pane-in-which-editing-is-done to say how the commands map to the
keyboard (M-.)

5) This may turn out to be insufficiently flexible or to be impossibly
over-flexible.  Without trying it I think it's going to be hard to say
which.

6) pane-in-which-editing-is-done needs a better name ;-)