Re: [RFC] Text Input Management System

[Nicola Pero]

> > In this context, the grammar of
> >keybindings files contains the symbol 'Shift'.  It's a programming symbol,
> >like 'for' or 'while' in C.  
> >
> Who said so?  The users will never consider Shift as a programming symbol
> until someone tells them so.

OpenStep itself defines programming symbols for key names.  
NSUpArrowFunctionKey, NSDownArrowFunctionKey, NSPageUpFunctionKey, etc.

And what about Shift ?  Well, the modifier flag is called NSShiftKeyMask.

Most programming environments do this, X11 for example does it too, it
uses symbols/pseudo-English names too to refer to keys -- take a look at
the X sources or headers and you'll find very long lists of key names.

The names used by gnustep-gui for keybindings are simply the names used by
OpenStep, after removing the 'NS' prefix and the 'FunctionKey' or
'KeyMask' suffix.

So, using Shift (with this capitalization) is quite consistent with the
rest of the system, and definitely with OpenStep.

 
> >You don't localize them.  They are the same
> >in all languages.  Yes, they are also English words, in the same way as
> >the C keywords 'float' or 'return' are also English words.
> >
> So you mean a sort of user-friendly programming language?  Did you write
> any document about it?  If it were written in BNF, I could precisely
> implement the parser from the outset.  The fact is, I couldn't find
> any document about it.  What do you expect me at the given situation?

Yes, it looks like there is no documentation available.  But the grammar 
is trivial.

Rule 1. The basic key description is a letter or something referring to a
button you can click alone on your keyboard.  In particular,
OpenStep-friendly names for the common keyboard buttons are allowed, such
as Home or PageUp or Function9 (full list available in the source).

Rule 2. You can obtain a more complex key description, describing a key
pressed in conjunction with a modifier, by prepending any key description
with any of the following strings:

 Shift-  (means to set the NSShiftKeyMask)
 Alternate- (means to set the NSAlternateKeyMask)
 Control- (means to set the NSControlKeyMask)
 Command- (means to set the NSCommandKeyMask)
 NumericPad- (means to set the NSNumericPadKeyMask)

I believe you can build a formal grammar from rules 1. and 2.  For
example, Shift-Alternate-PageUp is a valid key description.

Given that key descriptions in this form immediately map to the underlying
OpenStep C names (for example Shift-Alternate-PageUp means
'NSPageUpFunctionFunctionKey' pressed with a modifier mask of
NSShiftKeyMask & NSAlternateKeyMask), I find it simple, consistent and
user-friendly.

If instead of 'Shift-' you modify the grammar to use '$' (which is what
this Apple syntax is about), well you've changed nothing except that now
you need to know that '$' means NSShiftKeyMask and that if you want to
write NSShiftKeyMask you really have to write '$'.  It's an additional
(pointless) mapping to do in your mind to understand what the code means.


Now, I think you have a point in that the existing code is a bit
confusing/sloppy because for compatibility with Emacs and such, shorter
versions of the Shift-, Alternate-, etc strings were allowed, so that

S- can be used instead of Shift-
Crtl- or C- can be used instead of Control-
Alt- or A- or Meta- or M- can be used instead of Alternate-
Numeric- or N- can be used instead of NumericPad- 

If you want to remove those abbreviations for the sake of simplicity and
consistency, you have a point, yes maybe we should remove them.

If it means we can reach an agreement, I'm happy if you remove those, and
since you correctly said we need a comprehensive description fo the key
description format, some rearrangements of my comments above can be such a
description.



> If user-friendness is your point, why is Shift used exclusively?
> What's the reason for ruling SHIFT and shift out?

Because the OpenStep name is NSShiftKeyMask.


 
> >But programmers are very interested in keybindings usually, and they can
> >edit those files directly.  They benefit from a pseudo-English
> >syntax/grammar to specify key combinations.  Programmers are used to write
> >programs and code and lookup tables in pseudo-English.  And to be really
> >honest, it does make a huge different to write software using almost
> >binary encoding as in ~$D or using human readable pseudo-English text as
> >in Alt-Shift-D (obviously I think the human readable pseudo-English makes
> >enormously better software).
> >
> Don't exaggerate the things.  The symbol ~$D is a literal string, not a binary
> encoding at all. :-)  If one is really a programmer, she/he doesn't feel bad
> when she/he stumbles across ~$D (if she/he sleeps well everyday :-).

A *good* programmer feels very bad when she/he stumbles across ~$D. :-)


 
> >Doing five comparisons is certainly not a problem.  The difference in
> >performance is unmeasurable.
>
> I was talking about maintainability and extensibility, not about 
> performance.
> But if you really want to talk about it, think about accumulation caused by
> such sloppy attitude.  Actually, the current input system is much slower
> than mine (perhaps two magnitudes of order), though my purpose doesn't lie
> in tuning performance anyway.

I'm happy to hear that your system is much faster, which is excellent. :-)

But parsing the keybindings file is done only once at load time, so it
shouldn't affect input performance.


 
> >If you prefer ~$D, why don't you support both syntaxes ?
> >
> If there's really a defined syntax of the current key binding dict, why don't
> you put the specification in the source?  Trival?  How can other programmers
> make up anything out of nothing in a reliable way?

You are absolutely right in this and it's my fault if I've never
documented it.  Do you think some rearrangements of the rules at the top
of this email would be enough as a documentation ?



> My intention here is not to enlighten you.  Never.  I'm writing this way,
> expecting cross-checking by each other can works effectively in this list.
> So I'd be more than happy if you could have a look at my code a little bit
> and give some comment on it.

I'll try to do it.


> >I definitely prefer writing stuff like "Control-x" to whatever syntax you
> >have to write to get the same result on Apple.
> >
> I don't like to write any code like @"Shift" in the implementation
> of NSInputManager because I do believe making it free from any key 
> bindings is
> a right thing to do in order to guarantee the flexibility the Apple's 
> document
> promises.

But '$' is finally bound to ... NSShiftKeyMask.  So you could just write
'Shift' in the first place.  Using '$' doesn't add any flexibility.



> I said, it's a responsibility of an input server. In NSInputManager,
> I don't like to implement anything which makes it bound to particular,
> pre-defined key bindings. I'd like to write it in a neutral way. 
> In fact, my implementation of NSInputManager itself doesn't know
> anything  about particular key bindings.  What's wrong with this? 
> I do think this is a right thing to do.

I'm not sure I follow you here.  Do you mean that it is the NSInputServer
which is interpreting the key-bindings, not the NSInputManager ?

 

> >Btw, it's really nice that you are looking into this - I didn't mean to
> >discourage or disappoint you.
> >
> Really?  I wish I could hear it first, indeed. :-)

Sorry about the wrong approach then, I apologize, I do indeed encourage
you to go on with your work. :-)