gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] New PEG: containment--benja


From: Tuomas Lukka
Subject: Re: [Gzz] New PEG: containment--benja
Date: Tue, 29 Oct 2002 22:08:43 +0200
User-agent: Mutt/1.4i

On Tue, Oct 29, 2002 at 05:56:13PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >On Tue, Oct 29, 2002 at 05:33:02PM +0100, Benja Fallenstein wrote:
> > 
> >
> >>Tuomas Lukka wrote:
> >>
> >>>The keys work even if you don't view those dims, right?
> >>>     
> >>>
> >>Sure. They put one cell into another cell; the result the user expects 
> >>is that the one cell's text appears *inside* the other cell. The 
> >>d.contain etc. connections are internal-- like the clone dimension when 
> >>you use the 't' key.
> >>   
> >>
> >
> >About that also: it's vital to show that that text is somehow "specially"
> >inside there; it behaves so differently from the rest.
> >
> 
> Ted has suggested showing the first character of each cell in inverse 
> video. Since we don't use a console interface, we could show a vertical 
> bar at the boundaries. But I don't like this as a default: I don't like 
> having vertical bars around everywhere.

To me, that doesn't tell too much. How about emulating little cells
inside, i.e. very faint lines surrounding each separate contained region.

> >That might be a good enough reason, actually, to make these keys optional
> >and non-default, until the user interface is polished... Such that they
> >are on when -Dgzz.containment=1 is used.
> 
> I don't know, I think -Dgzz.containment=1 is really an antisocial way of 
> enabling this kind of thing. 

Well, the point is that as a whole it's not yet ready for prime time.
We can figure out a better way to turn them on at some point.

> (You could say that currently only the 
> developers are supposed to use the beast anyway, but then again, they 
> should not freak out over these keys, either.) 

No, the opposite: if we want non-developers to be using it, it needs to
be so that no experimental features are enabled by default.

And I'd definitely label containment as an experimental feature; I hope
that doesn't bother you.

I'd see the argument going the other way: for the time being, only developers
should be using containment and they can deal with -Dgzz.containment=1

> I dunno, I'm ok with the 
> keys being optional for now, but I don't like your way to activate them...

Oh, that was only a suggestion. Feel free to suggest something better.

> Also, there's the point that Ted has said he wants these bindings like 
> that, even though in the Perl client, too, Ctrl-K (or what it was) 
> edited only the text in the cell itself, not the contained cells.

I'm not saying that we shouldn't have them; I'm saying we need to be
careful about them.

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]