bug#23594: 25.0.94; Display errors on Linux tty

[Eli Zaretskii]

> Date: Sun, 22 May 2016 09:38:13 +0000
> Cc: 23594@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> On Sat, May 21, 2016 at 10:09:38PM +0300, Eli Zaretskii wrote:
> > > > This bug exists since we started showing the 'decomposition' of
> > > > characters in Emacs 24.1.  With LF, we send a literal LF character
> > > > to the screen.
> 
> That's only half the story.  The literal LF doesn't seem to be the
> problem.

What do you mean by "literal LF"?  A newline ends a line, and is never
displayed at all, the display engine "swallows" it so it disappears
without a trace, and instead instructs the terminal to move to the
next line.

> Rather, it's got a 'composition text-property attached to it.
> The string we're trying to display is
> 
> #("  decomposition: (10) ('\n')\n" 24 25 (composition (0 1 [9 10 9])))
>                            ^
>                          |
>                          24
> 
> What is this composition trying to do?  The [9 10 9] is [\t \n \t].

It tries to prevent the character from being composed with surrounding
ones, so that we could display there combining marks and other similar
stuff.

> Under X-Windows, the same string is displayed, this time successfully.
> The call
>     (inseert #("  decomposition: .... [9 10 9])))
> works on X-Windows, the "\n" with the composition property being
> displayed as a square box.

Why is that a "success", exactly?  Is the user supposed to guess that
the box represents a LF?

> > > OK.  The next question is is it easy to fix?
> 
> > Yes.  We should not send control characters to that buffer.
> 
> It seems to me there is a bug in the display engine here: the same
> string which is displayed successfully in X-Windows goes badly wrong on
> a Linux tty.
> 
> Comments?

IMO, there's no such thing as a successful display of an unadorned LF
(or any other control character), on any kind of terminal.  What would
be the graphics for that?