Re: [RFC] Text Input Management System

[Kazunobu Kuriyama]

Hi Nicola,

I'm afraid this discussion gets missing the point.  Nonetheless, let me 
go on,
for I think it might somehow help others get some ideas to evaluate the 
proposed
text input system. ;-)

Nicola Pero wrote:
<snip>

> 'Shift' is as much as a semantic symbol as '$' is, but it's easier to
> remember. :-)
My argument on English was a sort of joke, you know. :-)

> Everyone has to lookup ~$D in the documentation to understand it.  
> Instead, maybe not all but many people (particularly programmers who are
> the ones who more likely will edit such keybindings files) understand
> Alt-Shift-D without the need to look it up in the documentation.
Look at StandardKeyBinding.dict.  You don't need to refer to any document
all the way.  Although I admit it somewhat cryptic, but I don't think
it's not so unreadable as you claimed.

> So I think that it is more user-friendly.
Really?

> > Above all, the code of the current implementation strongly supports my
> > argument.  To interpret the key denoted "~" in the Apple's document above,
> > you need five comparisons, namely, @"Alternate", @"Alt", @"A", @"Meta", and
> > @"M".  How do you deal with localized strings?  As you already notice,
> > it's just a style OOP deprecates. (Said that, I must admit I'm often temped
> > to write such code. ;-)
>
> You should not localize this stuff. 
Why not?  I thought user-friendness is your way.

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

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

> End-users will only interact with this stuff through a Preferences
> application, which will be localized, so they will never see no matter
> what symbol is used.
Then, in this particular case, we don't need Shift-Alt-D, right?

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

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

> 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?  Use source?   You said
the five comparisons don't matter.  Yes it doesn't matter if our interest is
confined to that piece of code.  But think again about accumulation
of such pieces of code.  It does matter when someone else tries to make out
something from the code. (But who really takes care of someone coming after
him while he's writing some code?  Almost none. I myself is not an 
exception.
So it's understandable, but not a good excuse, though. ;-)

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

> > > > For the format, take a look at StandardKeyBinding.dict. Nested 
> > > > dictionaries
> > > > are allowed to use. "One key binding for dispatching multiple methods" is
> > > > not supported.
> > > Why not ? It was quite a nice feature, and easily implemented. You can
> > > just use the code/implementation which is already there, can't you ?
> > I didn't say it's not nice nor deprecated.  It's a responsiblity of an
> > input server in the proposed input system.  Once you write an input server
> > for that particular functionality, you can write anything you want in
> > the server's key bindings dictionary.  You lose nothing. ;-)
> >
> > By the way, why is that *nice* feature disabled in the current
> > DefaultKeyBindings.dict?  If it were not, I would implement that
> > functionality as default.
>
> I don't know.  But even if DefaultKeyBindings.dict is not using it, at a
> quick look it looks like the functionality is currently there.
>
> I suppose it's not really important ... but it looks so easy to do that 
> it's probably not a huge change to add it to your changes. :-)
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.

> ===
>
> 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. :-)

Regards,
- Kazunobu Kuriyama