bug#23594: 25.0.94; Display errors on Linux tty

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sun, May 22, 2016 at 06:27:42PM +0300, Eli Zaretskii wrote:
> > 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.

I mean (insert "\n") works without problems, even though it's more like a
command, and isn't a glyph.

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

OK.

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

It's a "success" in contrast to the failure on a Linux virtual terminal,
where text in the other window ends up displayed where it isn't situated.

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

I suppose one answer would be that glyph with a tiny "L" in the top left
corner and a tiny "F" in the bottom right corner.  But we couldn't use
that, since we don't know that the current terminal can display it.
Another answer would be some standard substitute character (like an
inverse question mark, or whatever).

But the real point seems to me to be that `insert'ing the above string
(with the composition property) completely fouls up the display in the
other window.  I'm guessing here, but could it be that the display engine
is actually outputting a raw 0x0a byte rather than handling it sensibly?

-- 
Alan Mackenzie (Nuremberg, Germany).