Re: [zzdev] Re: Clasm keybinders, 0.8

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> On Wed, Feb 13, 2002 at 02:17:18PM +0100, B. Fallenstein wrote:
> > Yes, we should, but I don't think it's an immediate problem. The
> > immediate problem IMHO is: Make the 0.6 keybindings work! When we
> > standardize the key strings then, we can easily change the strings in
> > the space.
> 
> Well, I think our standard is: the key itself for insertible chars,
> then shift-XXX, etc. Just like in 0.6.

Ok.

> > One important thing from 0.6 is modes. We need these, because we have to
> > have a movement and an edit mode right from the start.
> 
> Right... very good point. To be set by whom? Here's a possible inheritance
> problem: I inherit from the default 0.6 keybindings and then, after switching,
> the user is in the plain 0.6 mode, without my overrides for some bindings.

For the moment you can work around it: create your own edit mode,
override the key that switches modes.

> > Same opinion here. There were two special key strings in 0.6, INSERT and
> > DEFAULT: INSERT matched all insert characters, DEFAULT all characters.
> > What we did was calling the code that's going through all the bindings
> > three times: first, for the key string; then, if we don't have a match
> > and it's an insertable character, for INSERT; then, if we still don't
> > have a match, for DEFAULT. (At least it was like this IIRC.)
> >
> > I would like to use the same conventions in 0.8, if possible.
> 
> Actually, I'd like to be able to connect CLASM into the cell that is checked
> for the keybinding, so that I can put an arbitrary routine there if I happen
> to want to.

Okay. Question is whether clasm can detect insertion characters well,
but I think it can... (we check for length==1, don't we?)

This means we'd have to put INSERT at the end of the list... but we can
do that.

> > Also note that the headcell itself should probably be ignored, as it
> > will likely contain a label for the list of bindings, and maybe be
> > connected in some other structure itself.
> 
> Ok, so speccing that on d1 the headcell is never a binding?

Speccing that algorithm X always does a step first thing before checking
any bindings, I'd say.

> > > > I'm not sure how the choice of the keylist (in the example, PP/Client) will
> > > > be made runtime. From Java or Clasm? Would a clasm-solution there be
> > > > unnecessarily complex when compared to a java-solution?
> > >
> > > Window and view-specific. Clasm shouldn't be too complicated.
> >
> > Could we then also do the PP/client keybindings as different modes?
> > (Maybe the Java code could change the mode on startup if necessary and desired?)
> 
> I'd like to be able to just change the view and bindings between
> PP and client easily. I don't want to go back to the prison-like
> applications...

Which is a point in case for doing it through modes...

- Benja