[Top][All Lists]

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

Re: Fill column indicator functionality

From: Alp Aker
Subject: Re: Fill column indicator functionality
Date: Fri, 15 Mar 2019 09:00:59 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.3

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

reply via email to

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