Re: Fill column indicator functionality

[Eli Zaretskii <eliz@gnu.org>]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 14 Mar 2019 14:58:07 -0400
> 
> Sorry for jumping in late without having followed the whole discussion.  Here's a naive question: is there any reason to use an actual glyph from a face to draw that line, rather than just a continuous line?

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.

 . 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.

 . 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.  A naïve idea of redrawing the entire line
   would cause it to flicker on each keypress.  (The divider avoids
   this problem because it is drawn where no characters can ever
   overwrite it, so it only needs to be redrawn when the window
   dimensions change, something that is rare and causes a complete
   redrawing of the entire window anyway.)  We could instead arrange
   for redrawing only portions of the line that overlap the glyphs
   which are actually redrawn, but then we'd need to write code for
   detecting those portions.  By contrast, using the glyph-based
   implementation we get this for free, because the redisplay
   optimizations already know how to avoid redrawing glyphs that
   didn't change.  We also get for free support for R2L text,
   something that would again require separate code with the
   continuous line idea.

The continuous line idea does have one advantage: it seamlessly
supports lines of variable height.  But that use case is rare, and I
think we will be able to support them with the glyph-based
implementation as well.

Does this answer your question?