NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/alt/lucidem/help/821

Text File | 1992-12-24 | 5.6 KB | 114 lines

x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 24 Dec 1992 22:26:20 EST
Message-ID: <[e-mail]>
Subject: Idea: graphical extents
Reply-To: [e-mail]
Date: Thu, 24 Dec 1992 17:47:38 -0800
From: [e-mail] (Dave Gillespie)
Newsgroups: alt.lucid-emacs.help
Path: sparky!uunet!wendy-fate.uu.net!help-lucid-emacs
Sender: [e-mail]
Lines: 102

I made this suggestion to the FSF's Emacs 19 people a while ago, and
they said it sounded interesting but that they wouldn't be ready for
it for quite a while.  It occurs to me that Lucid Emacs probably has
all the pieces in place right now.

The idea is to make another type of extent, a "graphical extent."
It would be characterized by the usual two markers into a buffer
and a face, plus a graphical type and two pairs (x,y) of floats
with 0 <= x < 1 and 0 <= y < 1.

The start-position of the extent identifies a character cell in
the buffer, and the first (x,y) pair identifies a position within
that cell, together identifying any pixel in the buffer.  The
end-position and the other (x,y) pair identify another pixel in
the buffer.

The two graphical types that come to mind are lines, where the
extent shows up as a diagonal line between the two points, of
the face's foreground color, overlayed over the text; and
rectangles, where the two points are the corners of an outline
rectangle of the foreground color.

The nice property of this notation is that, as far as I can tell,
the set of pixels on the screen that could be affected by one
of these graphical extents is strictly a subset of the pixels that
are affected by a regular textual extent.  So all the regular
optimizations still apply, e.g., if both markers of an extent are
off the beginning or end of the screen, the display routines can
ignore the extent.

Line extents would be useful for all sorts of things, ranging from
prettying up buffers containing forms or tables, to displaying
actual graphics in an Emacs buffer.  In principle, given nothing
but line extents it would be possible to write a decent little
graphics editor for putting figures in Emacs documents.  Line
extents would also be enough to let Calc draw simple graphs all
by itself, rather than relying on a hokey and fragile interface
to GNUPLOT as it does now.

Rectangle extents would allow a more appropriate kind of
highlighting for rectangle operations.  I posted a suggestion
along those lines a while ago here, but I was envisioning
some way of faking it up with a group of regular extents.
Imagine how easy it would be with a single rectangle extent
instead!

Another nice graphical type would be filled rectangles, or even
filled polygons.  As soon as you have filled objects you run into
the issue of drawing order, though, which the current extent data
structure probably isn't well-suited to handle.  (I haven't looked
at the code, this is just guessing.)  I guess even a filled rectangle
extent where the behavior is undefined if any non-whitespace text
or other graphical extents intersect the rectangle would still be
useful sometimes.

Another enhancement would be to allow the (x,y) offsets to go
beyond the 0..1 range.  For example, it would be nice to be able
to draw an arrow to the right of a line of text, even though the
endpoints of the strokes of the arrow would not be inside character
cells.  I wouldn't be surprised if it would be easy to relax the
range restriction on the "x" offsets, although relaxing the "y"
restriction would probably make clipping a horrible nightmare.
Relaxing "x" would be enough for most purposes.  In fact relaxing
just the upper bound on "x" would be enough.

Suppose you wanted to display a change bar to the right of a set
of lines in a buffer.  The most mangeable way to do this would
probably be to put the two markers on the *first* character of
the first and last line of the marker, then put the "x" offsets
at, say, (- (window-width) 0.5).  (The really right way to do
this would be to have a flag on graphical extents saying to
interpret the "x" offsets as absolute rather than relative to
the character position of the marker; then you can simply put
the extent around the part of the buffer that has changed, and
the bars will automatically wind up where you want them even as
the text is edited further.  One could call this creeping
featurism, I suppose.)  (But then, now that I think about it,
most of the ideas I had in mind would be served by having "x"
*always* be an absolute position, with the markers only used to
find the "y" baseline.  Hmm.)

It's not totally clear how to interpret the "x" offsets when the
font is proportional, or when the marker points to a character with
a "wide" display like a tab or a "^M".  If you let the "x" offset
go outside the character cell, you could just scale it so that 1.0
equals the width of a space in the underlying font.

The idea behind using floats instead of integer pixel values for
the offsets is to make it easy on programs that don't want to know
about the details of the font being used.  Putting a rectangular
box around some text, for example, is just a matter of using
(0,0) for the upper-left offsets, and (0.999,0.999) for the
lower-right offsets.  If you get the pixel position by multiplying
the offset by the character width or height, and rounding down to
an integer, then (0.999,0.999) will specify the lower-right corner
of the character cell in a nice, font-independent way.

Anyway, I may someday have time to work on this myself, but I
wouldn't be surprised if Jamie or another person who already knows
the lemacs internals could do it in an afternoon.  Hint, hint.  :-)

                                -- Dave