Bijan Parsia <bparsia at email.unc.edu> wrote:
> On Mon, 14 Jul 2003, Lex Spoon wrote:
> 
> > IMHO, we should add hooks sparingly and as we need them.  We don't
> > really want everything to be customizable.
> 
> Piffle. What "we" can you possibly be talking about

We are all Borg.  The Bijan entity simply does not realize this yet. 
Squeak and its users move forward as a unified whole, always taking the
most logical step and never disagreeing.



> 
> [snip]
> > I don't see a good case for extensible key strokes in the text editor.
> > There shouldn't be many extensions, because Squeak only has 1-character
> > key combinations.
> 
> I've often wanted to change, augment, or override squeaks key commands for
> specific projects/editors/etc. All the time, in fact. It's horrifically
> painful as it stands.

Okay, I'm with you, but there's a big difference between adding
keystrokes for your specific editor, and adding keystrokes system wide.

Just consider: when you write your application, wouldn't you like to
know what keys are being used in the main, plain-vanilla text editor, so
that you don't hide a useful keystroke with one of your custom ones?  
Well, if you'd like to know this, then there had better not be people
registering stuff in the system-wide keymap.

Maybe I just misunderstand the proposal.  Having app-specific keymaps is
fine.  I wouldn't call that a registry, though.  Notice that the app
writer will know exactly what keys are bound to what.


> >  (Which seems fine, btw!  Do we really want multi-key
> > combinations in Squeak's text editor?!)
> 
> Sure. Why not.

Ack!!  Well, they take a long time to learn, and they're almost always
slower than menus.  They are a logical choice for emacs, but they seem
quite silly for a thoroughly graphical system like Squeak.


> > Let's be light on the hooks, *especially* in matters that pertain to the
> > user interface.  Generalization comes with a penalty.
> 
> You've been pretty light on what the penalties could be, and pretty strong
> on the idea that the only way to avoid them is to avoid improving things
> on the programmatic side of things. I find this uncompelling.
> 

Let me tie it together better.  Notice the following:

	1. It's extremely easy to add registries when a need comes up.  Thus
there is no hurry to do it.

	2. Registries remove the chance for a human touch, and leave things to
be organized by an algorithm.

	3. Registries add inertia and make a lot of simple hacks more
complicated.  Any code touching the registryized part of the system,
must now work under more general assumptions.

Thus, registries add a moderate amount of definite badness, and putting
them off costs nothing.


I guess in general you could sum up my stance as anti-flexible Squeak. 
:)  Don't get me wrong -- I'm glad that the sticky parts *are* getting
greased, in particular the open menu and some of the flaps.  But I want
the main Squeak release to only have generalizations that will actually
be useful.  Besides, it is good to put our feet down about a decision
every once in a while.  If we aren't going to make any decisions about
what goes into Squeak, then why don't we just give up and release an
empty file to the world?  Everyone can fill in the file with whatever
they want.

	http://c2.com/cgi/wiki?PrematureGeneralization


Lex