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: Fri, 10 Jun 2016 11:10:31 +0300 Message-ID: <83r3c5piq0.fsf@gnu.org> References: <83porxwg1f.fsf@gnu.org> <83d1nxudrb.fsf@gnu.org> <83wpm3tyvn.fsf@gnu.org> <83twh7tt83.fsf@gnu.org> <83r3cbt5l3.fsf@gnu.org> <83h9d6tl3j.fsf@gnu.org> <5755AACE.8030303@gmx.at> <831t4ataep.fsf@gnu.org> <57568F86.8040902@gmx.at> <83eg89roam.fsf@gnu.org> <5757BC3A.5070402@gmx.at> <83lh2fr4pt.fsf@gnu.org> <57592B18.2030808@gmx.at> <83bn3ar1k3.fsf@gnu.org> <575A6932.70908@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1465546287 32004 80.91.229.3 (10 Jun 2016 08:11:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 08:11:27 +0000 (UTC) Cc: 23574@debbugs.gnu.org, john.b.mastro@gmail.com, cwoodbury@azavea.com, npostavs@users.sourceforge.net To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 10 10:11:15 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 1bBHX9-0007TN-5C for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jun 2016 10:11:15 +0200 Original-Received: from localhost ([::1]:38944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBHX8-00043q-AO for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jun 2016 04:11:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBHWy-00042r-Qy for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 04:11:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBHWw-0006Rb-Pi for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 04:11:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBHWw-0006RX-MA for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 04:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bBHWw-0004Yj-FL for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 04:11: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: Fri, 10 Jun 2016 08:11: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.146554620517459 (code B ref 23574); Fri, 10 Jun 2016 08:11:02 +0000 Original-Received: (at 23574) by debbugs.gnu.org; 10 Jun 2016 08:10:05 +0000 Original-Received: from localhost ([127.0.0.1]:35095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBHW1-0004XX-Ei for submit@debbugs.gnu.org; Fri, 10 Jun 2016 04:10:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBHVz-0004Wx-RU for 23574@debbugs.gnu.org; Fri, 10 Jun 2016 04:10:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBHVt-0006Dw-Ic for 23574@debbugs.gnu.org; Fri, 10 Jun 2016 04:09:58 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBHVn-0006Bg-HM; Fri, 10 Jun 2016 04:09:51 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4278 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bBHVl-0007tj-Hd; Fri, 10 Jun 2016 04:09:49 -0400 In-reply-to: <575A6932.70908@gmx.at> (message from martin rudalics on Fri, 10 Jun 2016 09:16:02 +0200) 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:119363 Archived-At: > Date: Fri, 10 Jun 2016 09:16:02 +0200 > From: martin rudalics > CC: npostavs@users.sourceforge.net, 23574@debbugs.gnu.org, > john.b.mastro@gmail.com, cwoodbury@azavea.com > > >> Suppose a user wants to use the same background for all spaces at the > >> ends of all lines of a buffer regardless of "the last face used on the > >> line". How would she specify that? > > > > By putting the proper face property on the newline. > > Which gets me back to my initial concern: If our user does that eagerly > for the entire buffer, the overhead might be non-negligible. I don't see why. Redisplay only considers the visible portion of the buffer. > A loosely related question: Does for R2L text row->pixel_width for each > glyph row indicate the width of that row occupied by text as it does for > L2R text? row->pixel_width doesn't count text glyphs, it counts all of the glyphs in a glyph row, including the glyphs produced by the display engine for its own purposes. E.g., it always includes the space glyph produced at the end of a line, which is needed for displaying the cursor. In the R2L case the width includes the stretch glyph prepended on the left. > Suppose we have a L2R line with dots indicating the empty space at > the end of that line: > > TTTTTTTTTTTTT.... > > R2L this line would appear as > > ....TTTTTTTTTTTTT > > Would these two lines have the same row->pixel_width? Or, would the > length of the stretch glyph added at the left of the R2L line be that of > ‘window-text-width’ minus row->pixel_width? The latter. row->pixel_width is computed in compute_line_metrics, after the stretch glyph (and any other glyphs needed for line display) were already inserted. compute_line_metrics doesn't care about what glyphs are there, it counts them all.