From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#23594: 25.0.94; Display errors on Linux tty Date: Sun, 22 May 2016 16:16:51 +0000 Message-ID: <20160522161651.GE2136@acm.fritz.box> References: <20160521104720.GA2987@acm.fritz.box> <83k2in72de.fsf@gnu.org> <20160521190110.GB2987@acm.fritz.box> <83d1of6xe5.fsf@gnu.org> <20160522093813.GA2136@acm.fritz.box> <838tz26rkh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1463933856 32603 80.91.229.3 (22 May 2016 16:17:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 May 2016 16:17:36 +0000 (UTC) Cc: 23594@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 22 18:17:21 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b4W42-00011H-IK for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 May 2016 18:17:14 +0200 Original-Received: from localhost ([::1]:43494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b4W41-0000u2-Ib for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 May 2016 12:17:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b4W3v-0000tj-Cv for bug-gnu-emacs@gnu.org; Sun, 22 May 2016 12:17:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b4W3q-0002EU-CH for bug-gnu-emacs@gnu.org; Sun, 22 May 2016 12:17:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b4W3q-0002EQ-8i for bug-gnu-emacs@gnu.org; Sun, 22 May 2016 12:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b4W3p-0006Si-VP for bug-gnu-emacs@gnu.org; Sun, 22 May 2016 12:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 May 2016 16:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23594 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23594-submit@debbugs.gnu.org id=B23594.146393381024818 (code B ref 23594); Sun, 22 May 2016 16:17:01 +0000 Original-Received: (at 23594) by debbugs.gnu.org; 22 May 2016 16:16:50 +0000 Original-Received: from localhost ([127.0.0.1]:32958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b4W3e-0006SE-LU for submit@debbugs.gnu.org; Sun, 22 May 2016 12:16:50 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:20690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b4W3d-0006S5-FV for 23594@debbugs.gnu.org; Sun, 22 May 2016 12:16:50 -0400 Original-Received: (qmail 95782 invoked by uid 3782); 22 May 2016 16:16:48 -0000 Original-Received: from acm.muc.de (p4FC467AB.dip0.t-ipconnect.de [79.196.103.171]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 22 May 2016 18:16:46 +0200 Original-Received: (qmail 4585 invoked by uid 1000); 22 May 2016 16:16:51 -0000 Content-Disposition: inline In-Reply-To: <838tz26rkh.fsf@gnu.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:118535 Archived-At: 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).