[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: Clasm keybinders, 0.8
- To: Tuomas Lukka <lukka@xxxxxxxxxx>
- Subject: Re: [zzdev] Re: Clasm keybinders, 0.8
- From: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Date: Wed, 13 Feb 2002 14:40:41 +0100
- Cc: zzdev@xxxxxxxxxx
- References: <20020213142524.A9591@xxxxxxxxxxxxx> <20020213125156.GE16453@xxxxxxxxxxxxxxxx> <3C6A675E.D4EEDF3A@xxxxxx> <20020213133309.GF16453@xxxxxxxxxxxxxxxx>
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.
> > 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
> > 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
Which is a point in case for doing it through modes...