Re: [zzdev] Re: [zzdev] Raster-specific keybindings

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

On Thu, 10 Aug 2000, Benjamin Fallenstein wrote:
> Tuomas Lukka wrote:
> > 
> > On Thu, 10 Aug 2000, Benjamin Fallenstein wrote:
> > > WOW. This was easy.
> > >
> > > I've just put raster-specific keybindings in. They work in the following
> > > (I think quite elegant) way:
> > 
> > Would you care to explain it (preferably with diagrams) in Spec/ as well?
> 
> Will do, but without diagrams for now; I'm somewhat under pressure at
> the moment and learning how to use the figure editors you use would
> definitely make my deadlines impossible to meet. But you'll get the
> specs (curseling, too) until... well, Sunday latest.

No problem at all; I think something like two weeks is probably an
acceptable maximum delay between implementation and spec ;) So no hurry,
as long as they do get there eventually.
  
> > > ZZKeyBindings1 will search for an intersection between structparam and
> > > bindings mode cell on d.1 / d.clone. Thus, there's no string-based
> > > matching or anything; you can change the name of the mode and the link
> > > will still work.
> > 
> > Hmm, how efficient is that? How does it scale with growing number of
> > rasters? It need not be the *Most* efficient part since it's only done
> > once per keystroke.
> 
> I think of it as an experimental implementation, due to that it's a
> feature which is quite useful for many things now. On the other hand,
> when zz structure grows bigger and uses more serious, we'll definitely
> have to make intersections fast on a general level (with hashtables or
> whatever). Then, I think, this won't be much of an issue.

Intersections can't be made fast on a general level without other
penalties. How to do it needs a lot of thought.
 
> I'd say let's talk this through again when we actually have a
> performance problem: it might well be we need to change the current
> system out of design considerations before.

True. I don't like optimizing for performance too early but I do like
having a clear way available to optimize performance from the very first.
> 
> *nod*. Well, I think one thing we should keep in mind to try out at some
> point is shifting the responsibilty for the recursion needed in many
> rasters to a higher-level instance, so that a minimal raster only
> specifies a method that returns all connections of a cell in this
> raster.

I've thought about this but the problem is that defing that generally is
difficult but limited versions run into limitations very quickly.

	Tuomas