emacs-devel
[Top][All Lists]
Advanced

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

Re: Fill column indicator functionality


From: Eli Zaretskii
Subject: Re: Fill column indicator functionality
Date: Fri, 15 Mar 2019 15:54:41 +0200

> From: Alp Aker <address@hidden>
> Date: Fri, 15 Mar 2019 09:00:59 -0400
> 
> > 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.

How do you produce a line-height tall image glyph?  Maybe I'm missing
something, but I think we can only display image glyphs whose height
is fixed and determined by the image, or by its slice whose dimensions
are determined by a suitable display property, i.e. computed in
advance of redisplay.

But in any case, if such an image with dynamically computed height can
be produced reasonably easily by the display engine itself, what you
propose is a trivial extension of the code presented here: we just
need to replace the character glyph by an image glyph.

> the implementation for graphical and 
> text frames would be the same except for the choice of glyph.

No, the implementation for the text-mode frame will always need to be
(slightly) different , because it doesn't support images and it
implements the stretch glyph as a series of space-character glyphs.

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

Maybe I'm again missing something, but how can a Lisp program
(i.e. user customizations) produce an XPM image of unlimited height?
If the height is fixed, the image will be unable to produce vertical
lines taller than its height, in order to support tall lines.

Btw, I don't think we can assume universal XPM support: Emacs can
support platforms that only provide monochrome bitmapped images, no
XPM.  E.g., if I remove or rename the XPM DLL, Emacs on Windows still
shows the tool-bar icons, albeit ugly monochrome versions of them.

> It's straightforward to define XPM bitmaps in code, so this would
> allow even more flexibility than using font characters.

I'm sure users will find customizing a character much easier than
customizing an image.  In any case, I wouldn't give up on allowing a
character, even if we do support images, because there's no reason to
restrict users to images.  For example, a suitable selection of a
character could produce identical displays on GUI and TTY frames,
something that an image could never do.

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

Yes, but I was replying to a completely different idea.  What you
propose is just a trivial extension of the code posted here, so all of
the effort that went into that will still be valid, and most of my
message is not really relevant.



reply via email to

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