From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#23574: 24.5; Overzealous underlining in emacs-nox Date: Fri, 10 Jun 2016 09:16:02 +0200 Message-ID: <575A6932.70908@gmx.at> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1465543071 15971 80.91.229.3 (10 Jun 2016 07:17:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 07:17:51 +0000 (UTC) Cc: 23574@debbugs.gnu.org, john.b.mastro@gmail.com, cwoodbury@azavea.com, npostavs@users.sourceforge.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 10 09:17:41 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 1bBGh7-0000cS-O9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jun 2016 09:17:29 +0200 Original-Received: from localhost ([::1]:38776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBGh7-0004b5-0M for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jun 2016 03:17:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBGgp-0004Uy-Kv for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 03:17:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBGgh-0000xv-3c for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 03:17:10 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBGgh-0000xl-0H for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 03:17:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bBGgg-0003H6-Sy for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 03:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Jun 2016 07:17: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.146554298712538 (code B ref 23574); Fri, 10 Jun 2016 07:17:02 +0000 Original-Received: (at 23574) by debbugs.gnu.org; 10 Jun 2016 07:16:27 +0000 Original-Received: from localhost ([127.0.0.1]:35080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBGg6-0003GA-RC for submit@debbugs.gnu.org; Fri, 10 Jun 2016 03:16:27 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:54691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBGg5-0003Fw-G1 for 23574@debbugs.gnu.org; Fri, 10 Jun 2016 03:16:25 -0400 Original-Received: from [192.168.1.101] ([212.95.7.51]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lj4xG-1bix473j82-00dD8c; Fri, 10 Jun 2016 09:16:06 +0200 In-Reply-To: <83bn3ar1k3.fsf@gnu.org> X-Provags-ID: V03:K0:vI86+rVKmO5/7MvVdmzF73QW5Xn44EDcFtURp8b58QXE6IcOm9Q DFTm4ZgpBzLsFKV71pJTSjF6mr5WD5GxKTb352P4GduTdwypAqzQiGtQ+p2EWLHD82nkb1G 7hMj+XL0oaJ+o9IbqLqluyK84gIaM1Z+qMdwcwfefl7Cn3G86+pMvVMasg4Aej9AQrNqLTR ZIA5CjWRN21T60XYCFWXw== X-UI-Out-Filterresults: notjunk:1;V01:K0:BQOiHxgwmZ8=:CCV4aDoZOB7mvFpTvIIH6B Mk9vG+j0Cnr6U4TpWcVVN4C9xuj/cbPgbViMq+/Ufimt8jiHdFbSmoLI5XTV7aLL+lKOOm3TI 4N/msX7UwH7qeLWMboiYZcG4RQ/EPDJIkp1WrBzjGKl3Fx5IhBuQGn0RdL+tHfrRqpfBUDGYI 5fzeUGHovgrxe4erTmFbyxjgwC3Z55bNONI7A+MH/Nfz8avzvMRHIRLG2QCozW/TarvqmdMsX ys+URYWpdANP7/ntFdl6lpLHaNVJCcgW+nLOMw3uVNAsyiMQPvWUEEmBbQafMXiqPMwCj62wb s4/Btcsmk+GwU6zAGDVffArD1XFt5EwqDSxIq9dJ0qjavtuzrfDkEnBS9sqAVuRmes2psA+/3 U25FUBTD3B+gXYxhZwfxXtomNXYIm5/orb8wShd2CrRTB9rqK+NHWA0nlSrNTdRbgVY2044mb auyJlpjvE3mETdE8uohnfQSJJcOTIrZNgdDlRgBXr9zs3Sc4UyDyodJn/SOnn9NdMVOgyowHb 9xwkxX0hn3xdm3pwjg64hH850ttScw7keQtxAU2uBmla1OyObhNO4OcH4QWZS6S9AJE1bzPSe fY4gQDsKyfncg0skkCWIE0/4SXbaFGLyJD1B89P1PzCKK/I3/55DYx7q8QpPo+p6s0ymqoxU5 q8aEHAurgP2W6helNJC9uOQWqVq4jPRndpekh+tTVoqwtG48D2jaiIpfa3hOXFKipRPEhi9mI 2ZW91FED6BFnf/Im1C7qCZvMTJc9zboCIZt3dXuEJqH5RzXPgy83yO05Pi7btIHauZm6uUiK 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:119361 Archived-At: >> OK. But with my property list approach a once calculated bitmap woul= d >> have simply overridden the face of the iterator object. > > Your suggestion included a function, which could well return different= > values on each call. > > And creating new faces from arbitrary sets of attributes is no fun, > either. OK. I was not fond of my proposal anyway. >> 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 th= e >> 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. A more lazy solution would require to hook into =E2=80=98pre-redisplay-functions= =E2=80=99 or something the like in order to know which lines get displayed. Would =E2=80=98pre-redisplay-functions=E2=80=99 be a suitable place for that? martin 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? 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 =2E...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 =E2=80=98window-text-width=E2=80=99 minus row->pixel_width?