Re: [zzdev] Re: Clasm keybinders, 0.8

[Tuomas Lukka <lukka@xxxxxxxxxx>]

On Wed, Feb 13, 2002 at 02:17:18PM +0100, B. Fallenstein wrote:
> 
> Hiya!
> 
> Tuomas Lukka wrote:
> > > The goal is high flexibility, which will be realized by separation of code
> > > from the data. The keybinder clasm-routine essentially traverses through a
> > > list of cells that contain strings that match with keys that the Java JVM
> > > feeds it. Those cells have their correspondent actions (clasm code
> > > implementing that certain key) connected on a dimension. (Probable problem:
> > > we bind ourselves to Java by doing this)
> > 
> > Why? Because of the key strings?
> > 
> > We should standardize those ourselves so that we don't need Java, since
> > also different Java versions handle some events differently so we should
> > have a common reference case.
> 
> 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.

> > > This can be found also at
> > > http://vegai.cjb.net/projects/gzigzag/keybinder.txt and a drawed/scanned
> > > version at .../keybinder.jpeg as soon as I get myself near a scanner.
> > >
> > >
> > > Shared
> > > keybindings
> > >                    PP Specific
> > >  |---|
> > >  | a |-{clasm for  |--|
> > >  |---|\ "a}        |PP|
> > >    |   \           |--|
> > >  |---|  \            |
> > >  | b |-..\|-| |-| |-||
> > >  |---|    | |-| |-| ||     Client specific
> > >    |      |-| |-| |-|\
> > >  |---|           \   |\    |------|
> > >  | c |-..         \  | \   |Client|
> > >  |---|             \ |  \  |------|
> > >    |                \|   \    |
> > >    .                |-|   \   |
> > >    .                | |    \  |
> > >    .                |-|     \ |
> > >                      |       |-|
> > >                      |       | |
> > >                      |       |-|
> > >                      |        |
> > >                      |    |------|
> > >                      |    |Ctrl-H|--{clasm code for
> > >                      |    |------|   Client-specific
> > >                      |        |      "go home"}
> > >                      |        .
> > >                  |------|     .
> > >                  |Ctrl-H|--{clasm code for
> > >                  |------|   PP-specific
> > >                      |      "go home"}
> > >                      .
> > >                      .
> > >                      .
> 
> 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.

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

This would be much nicer than putting more and more special cases
into the keybinding-reading code: just allow the binding writer to plug
in a little code and everyone'll be happy.

> > Also, Japanese is going to be interesting...
> 
> Yes. For the moment, we probably want to stick with AWT for inputting Japanese?

Yes.

> > The 0.6 version did
> > 
> >  2. If there is something on step(A, d3, -1):
> >         - do algorithm X on headcell(A, d3, -1)
> > 
> > I don't see the use of the additional complication.
> 
> Agreed.
> 
> 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?

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

	Tuomas