[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: [zzdev] Re: Clasm keybinders, 0.8

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

Urgh, no, no, NO.

That's unacceptable because it couples the default and the inheriting bindings
very closely; adding one default mode-changing keybinding will wreck the
inheriting ones.

I'd rather do it by allowing the bindings lists to branch by the modes
from the current view. This would allow new views to separately override
edit and motion modes, or also just override in both.

So maybe allow a branch to be made using CLASM code at a certain cell;
like with the CLASM for detecting the patterns, using

   move - BRANCH - edit
    |               |
    .               .
    .               .
    .               .

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

Yes, I'd think. Of course, we have to make sure that 0x65535 doesn't make
it up to there (it has, sometimes, been inserted in the streams...!!)

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

Yes, sounds reasonable.