Re: Fill column indicator functionality

[Alp Aker]

> That's a good question.  Indeed, it would be possible to implement
> this with a single thin line being drawn, but I think such an
> implementation would have several disadvantages:
>
>   . It will need to be implemented separately for each window-system
>     (X, w32, NS), and for TTY frames.  By contrast, the implementation
>     discussed here is in a single place, is independent of the display
>     kind, and is very simple and localized.

I believe a simpler implementation is possible:  Where Ergus's 
implementation uses a char glyph, it could also use a line-height image 
glyph.  That is, instead of a single window-length element, analogous to 
the window divider, the indicator would consist of many independently 
displayed line segments, one per line.  If we use an image type like XPM 
that's universally supported, this would allow a single implementation 
shared by all window systems, and the implementation for graphical and 
text frames would be the same except for the choice of glyph.  (This is 
the method used by the unfortunate fill-column-indicator package whose 
deficiencies have necessitated the current work.)

>   . Using a glyph makes it easier to support some fancy customizations.
>     For example, suppose that someone would like to have the indicator
>     be a dotted line, or to have a more prominent appearance -- all
>     they'd need to do is find a suitable character, such as ▍ or ▓, and
>     be done.  With the continuous line implementation, we'd need to
>     implement the corresponding textures in the code, before it could
>     be supported.

If we use an image glyph on each line, the customizations would apply 
only to the construction of that XPM image; the display routine that 
positions the image segments doesn't need to know how to construct the 
image.  Users could even supply arbitrary images to use, so long as 
they're of the appropriate height (or they could just be cropped to the 
correct height if necessary).  It's straightforward to define XPM 
bitmaps in code, so this would allow even more flexibility than using 
font characters.

>   . Using the continuous line would cause complications wrt redisplay
>     optimizations.  Redisplay of text is highly optimized in Emacs, and
>     frequently needs to update only a small portion of the window.  The
>     problem is what to do about the indicator line when only some
>     portions are redrawn.

Unless I'm mistaken, the method I'm describing would allow the same 
optimizations that Ergus's current implementation does (since it would, 
as far as display is concerned, be the same except for the choice of 
glyph to use).