Re: [zzdev] Some smaller notes

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

Ok, finally a moment of time to do email.

> And... the width of the billowing text should be the width of the window
> the text is rastered into. That would make *much* more sense. (Also,
> up/down keys for last line/next line should be easy to implement: take
> the x coordinate of the current insertion cursor, use an y coordinate in
> the line above, and use the same code you'd use to translate a user's
> mouse click to a position in the text.)

Yes, the problem isn't that, the problem is rather the raster (or vizn-)
specific operations. There is currently no framework for that and that
needs to be resolved. Once that is in place, we can definitely start on
this.

> Here are some suggestions, which you can as well see as questions: is
> something like this implemented or planned yet, and where can I find out
> about it? And everything which isn't is a suggestion. :) They are
> requests for primitive operations, which should be really
> straight-forward: fetch cursor, and go to headcell. I've done
> implementations of both, but as I'm not really familiar with gZZ coding
> style yet (and not with diff, either -- I don't even have it here), it's
> probably easier for you to implement them from scratch than to use my
> code. 

Oh, I wouldn't be sure - it'd be great to get external patches. It's still
faster to apply a patch than to write.

> Fetch cursor (FETCH and CFETCH?) positions one view's cursor on the same
> cell as the other one's. This is helpful when you haven't used the
> Control view for some time, and want to use it for the '/' connecting op
> now -- you want to 'fetch' it from the distant point in the structure
> where it currently is. I use '<' and '>' as keys (< to fetch the control
> view, and > to fetch the data view; this is handy on the German keymap,
> where < is a non-shift key, as you need to fetch the control view more often).

Ted had a fuller spec of these kinds of ops earlier, these are most
welcome as a stop-gap thing.

> Go to headcell (HEAD and CHEAD?) takes a direction as argument and
> positions a view's cursor on the headcell in that direction. So, you
> could either have a binding like Alt-Up to go up to the headcell on Y-,
> or a headcell key like ö (probably nothing for US keyboards, but I'm not
> aware which US keys still are free :)), which is followed by a cursor
> key and then does the same (similar to the new cell, clone etc. ops
> which take a cursor key as argument). Go to headcell is very helpful in
> navigating lists, long or short; I use gZZ to take notes in an (almost)
> corner list structure, and go to headcell is great when I want to go
> multiple levels up fastly.

Yes, this is definitely planned too. We're just all too busy to implement
these so I'll gladly accept patches to do these. I think that the name END
would be right, since then you only need one operation for going to the
end of the direction you indicate.

cvs diff -u

is the best style of diff for us.

	Tuomas