From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23574: 24.5; Overzealous underlining in emacs-nox Date: Mon, 06 Jun 2016 18:04:16 +0300 Message-ID: <83h9d6tl3j.fsf@gnu.org> References: <83porxwg1f.fsf@gnu.org> <83d1nxudrb.fsf@gnu.org> <83wpm3tyvn.fsf@gnu.org> <83twh7tt83.fsf@gnu.org> <83r3cbt5l3.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1465229766 27363 80.91.229.3 (6 Jun 2016 16:16:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jun 2016 16:16:06 +0000 (UTC) Cc: 23574@debbugs.gnu.org, john.b.mastro@gmail.com, cwoodbury@azavea.com To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 06 18:15:55 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 1b9xBy-0005Yg-Qq for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jun 2016 18:15:55 +0200 Original-Received: from localhost ([::1]:43452 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9xBx-0002ZL-W4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jun 2016 12:15:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9w4S-0005om-Rn for bug-gnu-emacs@gnu.org; Mon, 06 Jun 2016 11:04:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b9w4Q-0004V4-Mk for bug-gnu-emacs@gnu.org; Mon, 06 Jun 2016 11:04:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9w4Q-0004Uz-JT for bug-gnu-emacs@gnu.org; Mon, 06 Jun 2016 11:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b9w4Q-0008W3-9F for bug-gnu-emacs@gnu.org; Mon, 06 Jun 2016 11:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jun 2016 15:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23574 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 23574-submit@debbugs.gnu.org id=B23574.146522543732722 (code B ref 23574); Mon, 06 Jun 2016 15:04:02 +0000 Original-Received: (at 23574) by debbugs.gnu.org; 6 Jun 2016 15:03:57 +0000 Original-Received: from localhost ([127.0.0.1]:56900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b9w4K-0008Vi-Ph for submit@debbugs.gnu.org; Mon, 06 Jun 2016 11:03:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51735) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b9w4J-0008VV-Fi for 23574@debbugs.gnu.org; Mon, 06 Jun 2016 11:03:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b9w4D-0004Sj-CF for 23574@debbugs.gnu.org; Mon, 06 Jun 2016 11:03:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9w49-0004OO-5C; Mon, 06 Jun 2016 11:03:45 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4038 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1b9w46-0007dk-Tj; Mon, 06 Jun 2016 11:03:43 -0400 In-reply-to: (message from Noam Postavsky on Mon, 6 Jun 2016 07:42:37 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:119156 Archived-At: > From: Noam Postavsky > Date: Mon, 6 Jun 2016 07:42:37 -0400 > Cc: John Mastro , 23574@debbugs.gnu.org, cwoodbury@azavea.com > > > When the newline does not have the underline attribute, the underline > > is not contiguous, so you are radically changing the use case. > > Yes. However, I believe that this is what the original ensime code > intended to do; it only underlines the newlines themselves because > it's easier to make 1 overlay for all the lines at once and the > programmer didn't notice it was wrong because it happens to give the > desired effect in GUI mode. I don't see how the effect on GUI frames could be considered "desired". What about the fact that the underline extends one space beyond the line's text? So on GUI frames we see the same problem, just of smaller dimensions. Or am I missing something? > Regardless, by experimentation I find that the space at the edge of > the screen takes the face from the final newline, not the last > displayed glyph character in the line. Is this documented anywhere? That space at the edge of the line is not a space at all, although it looks like one. It is a special glyph produced by the display engine, primarily so that we could display the cursor at the end of the line. Its attributes are invented by the display engine out of thin air for its own purposes; for example, the buffer position recorded in that glyph is zero, not the position of the newline. As for your conclusion, I believe there's a misunderstanding here. You are talking about the face of a buffer position, while I was talking about the glyphs on the screen. Other that this minor disconnect, I don't see any contradiction between what we say. Also note that the display engine doesn't examine each character's face when it produces glyphs for display, it only examines the faces where they change. Which in this case means that the face of the newline is immaterial; what matters is whether it is identical to that of preceding characters. To be precise, the face used for extension is the one loaded into the iterator object when it hits the end of the line. As there are too many ways to specify faces in Emacs, I won't risk confirming that your conclusion is 100% correct ;-) My description is correct, but perhaps less useful to a Lisp programmer. As for documentation: these all are fine details of the display engine that are not documented anywhere except in the code comments. Even the face extension itself isn't mentioned anywhere, I believe simply because the effect is natural and expected, whereas its accurate documentation is not simple at all. Does it really make sense to document just this specific subtlety? IOW, if you are interested in these details, you should be hacking the display engine code long ago ;-) Going back to the bug report, there's still one issue to consider: should we add underline (and then also overline and strikethrough) to the list of face attributes that cause face extension on GUI frames. The logic behind the current code seems to be to extend attributes that are related to background of the text. The above 3 seem to be a kind-of background, so maybe we should add them.