I think the arguments in the abstract are proving futile. If people come
up with specific things they'd find useful, we can then consider each
concretely, in the context of the specific problems it solves and how it
does so. 

So I suggest - ideas now, critical eyes later ;-)

Just my 0.02NIS.

I'm going camping, talk to you all in a few days.

Daniel

Bijan Parsia <bparsia at email.unc.edu> wrote:
> On Tue, 15 Jul 2003, Lex Spoon wrote:
> 
> > 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.
> 
> But, Borgman, the trouble with piffles is that they reproduce so quickly
> but still remain EXTREMELY cute.
> 
> [snip]
> > > 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.
> 
> Nope. The system is my specific editor. Sometimes, at least. :) I'd like
> the mechanism to be uniform if feasible, reasonable, useful, etc. Why have
> two mechanisms if one works well? The current one doesn't work well if you
> want to dork around with them.
> 
> > 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?
> 
> No.
> 
> Well, sure. I guess. Finding out at run time would be great.
> 
> If I really use a feature, perhaps I should import it down into my keymap.
> but if the user has modified this how this feature gets used elsewhere,
> why should I ignore that? If I end up shadowing a key that the user has
> rebound, then they have an easy path to finding and debugging it. Which is
> what they'd want, I'd imagine. It's what I'd want.
> 
> > Well, if you'd like to know this, then there had better not be people
> > registering stuff in the system-wide keymap.
> 
> er...I don't see it following. "Event maps" with the ability to insert
> filters, alternatives, etc. on the event mapping seems just fine.
> 
> Having flexibility doesn't preclude not using that flexibility. Though, I
> can imagine several popular keymaps (an emacsy one, for example) just as
> there are several popular themes. If two keymaps are very popular, or even
> just one person uses it, then my app can have two keymaps, one tailored
> for extending each of the others. Sounds groovy to me.
> 
> > 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.
> 
> The question is how to have app specific keymaps/menus/etc. that *extend*
> or work with existing functionality without having to replicate the code
> everywhere. This is one direction of flexibility (how do I
> specialize/override maps for new contexts). The other direction,
> characterized by the open menu, is how do I specialize/enhance maps/menus
> in existing contexts.
> 
> Both seem useful. Both seem abusable. If there's a general mechanism that
> reasonably handles both, then I don't see that you have a reasonable
> objection.
> 
> > > >  (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.
> 
> Well, what if someone wants them? I find them occasionally useful.
> 
> Seems silly to forbid them.
> 
> >  They are a logical choice for emacs, but they seem
> > quite silly for a thoroughly graphical system like Squeak.
> 
> And if someone wants emacs like bindings in their Squeak editor? Which
> many folks do.
> 
> [snip]
> > 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.
> 
> Perhaps.
> 
> > 	2. Registries remove the chance for a human touch, and leave things to
> > be organized by an algorithm.
> 
> This is exactly one thing we've been discussing. E.g., the "depend on
> append" assumption kinda sucks. Doesn't mean we can't do better.
> 
> > 	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.
> 
> That's not clear to me at all. I'd love a hypercard or newtonscript like
> "container" inheritence for example, so I could intercept events and add
> or override functionality. Hacking the current system 1) sucks, 2) is
> hard, 3) tends to get clobbered by a) other hacks, 2) updates.
> 
> Boo to that, man.
> 
> > Thus, registries add a moderate amount of definite badness, and putting
> > them off costs nothing.
> 
> You presume that none of the bads of the current setup go away. That's
> most definitely false.
> 
> > 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.
> 
> And several of us find this useful. You find it abstractly bad. Note we
> aren't JUST talking about registries, but trying to find something that
> may be better.
> 
> >  Besides, it is good to put our feet down about a decision
> > every once in a while.
> 
> Like to be flexible.
> 
> >  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.
> 
> This is a non sequitur.
> 
> No one's saying don't make any decisions.
> 
> > 	http://c2.com/cgi/wiki?PrematureGeneralization
> 
> Given two independant implementations of a more flexible system, and
> interest in same, and my personal frustrations with the *status quo*, I
> hardly thing we're talkign Premature, here.
> 
> Cheers,
> Bijan Parsia.