bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#11832: 24.1.50; enhancement request: line truncation not dependent o


From: Drew Adams
Subject: bug#11832: 24.1.50; enhancement request: line truncation not dependent on fringe
Date: Sun, 1 Jul 2012 09:52:48 -0700

> Just for the sake of accuracy: those are not overlays (in the Emacs
> sense).  They are special glyphs inserted by the display engine as
> indication of line truncation.

Thank you.  I wondered about that.  I even searched the C code, but I didn't
find any occurrence of "$" or its char number.  I just guessed that an overlay
was used, as it did not seem to be just text in the buffer.

> > In Emacs 21+, this representation was lost AFAIK, replaced 
> > by adding a symbol to the right fringe.
> 
> Only in GUI sessions.  If you invoke "emacs -nw", you will still see
> those truncation glyphs.

OK, it was lost only in GUI sessions.

And the fact that it is kept for non-GUI, instead of simply truncating the text
with no truncation indicator, argues strongly in favor of it for GUI too
whenever the right fringe is not shown.

> > Please let users choose the representation to use.  One way 
> > to do this would be to let option `truncate-lines' respect
> > different non-nil values, e.g. `right-fringe', `overlay'.
> >  
> > Since the fringe representation is not general (is useless 
> > unless fringe is shown), the default should be the pre-Emacs
> > 21 behavior of using an overlay.  But I won't argue about the
> > default.  Please provide users a way to get the pre-21 behavior
> > - that's the main point.
> 
> Unfortunately, it is very hard (a.k.a. "impossible") to do that.  The
> problem is that, depending on the font and the characters on a line, a
> line can be truncated in the middle of a glyph, and in that situation
> inserting a truncation glyph will not work, because for that you need
> a character cell that can accommodate the truncation glyph "$".  There
> are clear comments about that in the display code.

You seem to be saying that the result will not look good in 100% of the
situations users will encounter.  Still, some user choice in the matter is a lot
better than none.  If a user does not like what s?he sees she can revert to the
more limited display - IOW, s?he can _choose_ what is today a non-choice.

Turn off fringe display and you will quickly see what I mean: there is _nothing_
to distinguish a truncated line from one that is not truncated.  That is not
good.  Imagine if that were the choice for non-GUI Emacs - what would your
reaction be?

> However, if someone finds a clever solution to this dilemma, patches
> or ideas are welcome.

Just sacrifice 100% perfection.  Give users the choice, at least.

We should not wait for someone to "find a clever solution to this dilemna".
That sounds like a recipe for doing nothing forever.

Pre-fringe Emacs (18...20) had it right.  As soon as someone added fringe we
lost this (baby...bathwater).

Even if Emacs now handles glyphs or whatever differently than it did in Emacs
20, and even if the partial solution you describe will not be perfect, it will
be a heck of a lot better than having _no_ indication of which lines are
truncated.

This is all the more important because line truncation can be used to reduce
horizontal real estate, whereas showing the fringe increases the real estate
used.  The Emacs 18...20 display used a minimal amount of horizontal space (like
the non-GUI display does still).  That should be an option for users.






reply via email to

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