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

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

[Drew Adams]

Prior to Emacs 21, truncated lines are indicated by an overlay with a
`$' symbol shown on each line at the right window edge, i.e., within the
window & buffer - not in the fringe.
 
This is a reasonable indication of whether a given line is truncated.
 
In Emacs 21+, this representation was lost AFAIK, replaced by adding a
symbol to the right fringe.  That representation is reasonable ONLY when
a user chooses to show the right fringe.  Otherwise, it is useless: it
does not tell you which lines are truncated.
 
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.
 
A third distinguised non-nil value, `fringe-if-shown', could use the
right fringe if it is shown and an overlay if not.  That too would be a
reasonable default value.  It could in fact be the behavior for an
undistinguished non-nil value, i.e., any value other than `right-fringe'
and `overlay'.

In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-06-18 on MARVIN
Bzr revision: 108646 michael.albinus@gmx.de-20120617185439-jfcgwwbr97nbflkz
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
 

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sun, 1 Jul 2012 07:13:47 -0700
> 
> Prior to Emacs 21, truncated lines are indicated by an overlay with a
> `$' symbol shown on each line at the right window edge, i.e., within the
> window & buffer - not in the fringe.

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.

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

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

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

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

[Drew Adams]

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

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

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> Pre-fringe Emacs (18...20) had it right.

It didn't have variable width fonts.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

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

The truncation glyph always occupies one column, even if not shown.  If
you configure your fringe to only show on the right you get (or lose)
exactly the same amount of space.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Drew Adams]

AS> The truncation glyph always occupies one column, even
AS> if not shown.  If you configure your fringe to only show
AS> on the right you get (or lose) exactly the same amount
AS> of space.

Fair enough; good point.

The real point of the bug report, however, is that unless a user turns on fringe
display s?he has NO indication of which lines are truncated.  That's not good.

EL>>> However, if someone finds a clever solution to this 
EL>>> dilemma, patches or ideas are welcome.
> > 
> > Just sacrifice 100% perfection.
> 
EL> I understand the principle, but not the particulars.
EL> What do you suggest that the display engine do when it
EL> bumps into the case I described? not display the truncation
EL> glyph in that case? something else?
EL> 
EL> IOW, what is the solution you suggest, exactly?

I reported the bug (from enhancement request to regression, depending on your
point of view).  I do not claim to have a solution, let alone the best solution.

However, if nothing else, i.e., if you cannot find any way to let users with
fringe turned off see which lines are truncated, then consider adding a user
option that has a value that turns fringe on automatically for any frame
containing a window that shows line truncation.  IOW, let users choose to have
line truncation automatically display fringe.

(Even better would be to have an option value `show-minimally' that shows the
minimal fringe as needed - e.g. `right-only' if all text shown in the frame is
left-to-right, `left-only' if all is right-to-left, etc.)  Obviously, such an
option should have an effect only if fringe is not already displayed - they
would not cause fringe to disappear when no truncation, if the user asked for
fringe.

[IIUC, the presence or absence of fringe is frame-specific at best, and not
window-specific, which means that the entire frame would need to be affected for
truncation-provoked fringe display.  

That, in spite of the fact that the Emacs manual presents fringe in a node
entitled `Window Fringes', and it speaks of windows having fringes and not of
frames having fringes.  It is true that the fringe symbols used can be different
depending on the buffers displayed in individual windows, but IIUC all of the
windows in a given frame either have or do not have fringe along the same
edge(s).]

Let me be clear BTW about my motivation: I use Emacs with fringes turned off.
And I use it with line truncation turned off (although it gets turned on
automatically in contexts such as the debugger).  I am not asking for a fix to
this bug for myself but for Emacs.

I simply recognize that something was lost for users in moving to Emacs 21.  It
seems wrong that users who choose not to show fringe have no way of knowing
which lines are truncated.

I hope that at least the same subset of use cases that existed prior to Emacs 21
can have truncation indication restored in some way.  I do not know exactly what
that subset is (only fixed fonts in a given frame?).  But in the context of that
subset, which I imagine is not a rare context, Emacs should be able to DTRT, one
way or another.

---

BTW, I looked for index entries matching `.*bidirect.*' and found only one:
`bidirectional editing'.  There are 2 other entries for `bidi*', aimed at the
same node.  In that node it mentions that individual paragraphs that are r-to-l
show text continued or truncated on the left.  But I do not see any explanation
of what happens wrt truncation indicators (e.g. no mention of the fringe).  

Presumably, if a frame shows text (e.g. a paragraph) that is r-to-l and other
text (same buffer or another) that is l-to-r then both left and right fringes
would need to be displayed to see the truncation indications.  Maybe that should
be pointed out?  Seems like there should at least be cross references here to
nodes `Line Truncation' and `Continuation Lines'.

There is a cross-ref link to node `Bidirectional Editing' from node `Window
Fringes', which is good.  But maybe nodes `Line Truncation' and `Continuation
Lines' should also have a cross ref to `Bidirectional Editing'.

And maybe node `Continuation Lines' should be updated to not just say that
truncation is indicated in the right fringe?  (The two other fringe nodes have
already been updated in this regard for bidi, it seems.)

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

[Stefan Monnier]

> The truncation glyph always occupies one column, even if not shown.  If
> you configure your fringe to only show on the right you get (or lose)
> exactly the same amount of space.

While I think this is true for truncated lines, it is not quite true in
all cases: the tty truncation glyph area can be used to display the
cursor and current Emacsen can usually also show the cursor in the
fringe, but not when word-wrap is enabled.


        Stefan

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <11832@debbugs.gnu.org>
> 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.

Search for "truncation_glyph".

> > However, if someone finds a clever solution to this dilemma, patches
> > or ideas are welcome.
> 
> Just sacrifice 100% perfection.

I understand the principle, but not the particulars.  What do you
suggest that the display engine do when it bumps into the case I
described? not display the truncation glyph in that case? something
else?

IOW, what is the solution you suggest, exactly?

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

As Andreas points out, the reason was not the fringe, it was the
variable-width fonts.  Emacs 20 only supported fixed fonts, so it
essentially worked as a TTY display.

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

[Eli Zaretskii]

> Date: Sun, 01 Jul 2012 19:09:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 11832@debbugs.gnu.org
> 
> However, if someone finds a clever solution to this dilemma, patches
> or ideas are welcome.

Actually, I might have an idea.  Not sure if it's a clever one, but I
will try to see if it's workable when I have time.

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

[Drew Adams]

> Actually, I might have an idea.  Not sure if it's a clever one, but I
> will try to see if it's workable when I have time.

Good to hear.  Thx.

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

[Eli Zaretskii]

> Date: Mon, 02 Jul 2012 22:16:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 11832@debbugs.gnu.org
> 
> > Date: Sun, 01 Jul 2012 19:09:00 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 11832@debbugs.gnu.org
> > 
> > However, if someone finds a clever solution to this dilemma, patches
> > or ideas are welcome.
> 
> Actually, I might have an idea.  Not sure if it's a clever one, but I
> will try to see if it's workable when I have time.

The idea turned out to be workable, so I committed the necessary
changes in trunk revision 108938.  You should now see truncation and
continuation glyphs when the respective fringes are disabled (via
fringe-mode).  Please test.

I'm not closing the bug report, because I'm quite sure people will
find subtle bugs in this mode, especially with proportional fonts,
variable-size fonts, images, and any other feature that causes lines
to differ in pixel size.  The issue _is_ somewhat tricky; it's not an
accident that this feature was not available in Emacs since v21.1.
Subtle bugs probably still lurk.

Please report any such problems here, and please try to come up with
the simplest possible test case for each problem, preferably starting
with "emacs -Q".

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

[Drew Adams]

> The idea turned out to be workable, so I committed the necessary
> changes in trunk revision 108938.  You should now see truncation and
> continuation glyphs when the respective fringes are disabled (via
> fringe-mode).

Excellent.  Bravo, Eli.

> Please test.

Will do when I get the next Windows build.

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

[Drew Adams]

> > You should now see truncation and continuation glyphs when
> > the respective fringes are disabled (via fringe-mode).
> 
> Excellent.  Bravo, Eli.
> 
> > Please test.
> 
> Will do when I get the next Windows build.

Done - looks good.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <11832@debbugs.gnu.org>
> Date: Wed, 18 Jul 2012 08:25:57 -0700
> 
> > > You should now see truncation and continuation glyphs when
> > > the respective fringes are disabled (via fringe-mode).
> > 
> > Excellent.  Bravo, Eli.
> > 
> > > Please test.
> > 
> > Will do when I get the next Windows build.
> 
> Done - looks good.

Thanks.

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

[Juanma Barranquero]

On Sat, Jul 7, 2012 at 6:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I'm not closing the bug report, because I'm quite sure people will
> find subtle bugs in this mode, especially with proportional fonts,
> variable-size fonts, images, and any other feature that causes lines
> to differ in pixel size.

Ding dong!

> Please report any such problems here, and please try to come up with
> the simplest possible test case for each problem, preferably starting
> with "emacs -Q".

;;;;;;;;;; test.el ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(require 'bs)
(add-hook 'bs-mode-hook (lambda () (set-window-fringes nil 0 0)))
(setq bs-attributes-list '(("Buffer" compute-buffer-width  nil left
bs--get-name)))
(defun compute-buffer-width ()
  (- (window-width)
     1))  ; one empty column at the end
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;,,,,,,,,

emacs -Q -l test.el -f bs-show

Result: there's a spurious blank line at the end which wasn't there in
24.1, nor the trunk of few days ago.

    Juanma

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

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 10 Jul 2012 21:59:41 +0200
> Cc: drew.adams@oracle.com, 11832@debbugs.gnu.org
> 
> ;;;;;;;;;; test.el ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (require 'bs)
> (add-hook 'bs-mode-hook (lambda () (set-window-fringes nil 0 0)))
> (setq bs-attributes-list '(("Buffer" compute-buffer-width  nil left
> bs--get-name)))
> (defun compute-buffer-width ()
>   (- (window-width)
>      1))  ; one empty column at the end
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;,,,,,,,,
> 
> emacs -Q -l test.el -f bs-show
> 
> Result: there's a spurious blank line at the end which wasn't there in
> 24.1, nor the trunk of few days ago.

Fixed in trunk revision 109069.

It was a problem with vertical-motion, which affected
count-screen-lines, which caused bs--set-window-height resize the
window one line too tall.