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 10:24:30 +0200 Message-ID: <575A793E.7090302@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> <575A6932.70908@gmx.at> <83r3c5piq0.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: 7bit X-Trace: ger.gmane.org 1465547191 14382 80.91.229.3 (10 Jun 2016 08:26:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 08:26:31 +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 10:26:19 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 1bBHli-0008QO-4m for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jun 2016 10:26:18 +0200 Original-Received: from localhost ([::1]:39015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBHlh-0000hV-9Q for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jun 2016 04:26:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBHla-0000ft-Hy for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 04:26:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBHlS-0001mV-2X for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 04:26:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBHlR-0001mP-Up for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 04:26:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bBHlR-0004xZ-Q7 for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 04:26:01 -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 08:26:01 +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.146554710218990 (code B ref 23574); Fri, 10 Jun 2016 08:26:01 +0000 Original-Received: (at 23574) by debbugs.gnu.org; 10 Jun 2016 08:25:02 +0000 Original-Received: from localhost ([127.0.0.1]:35106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBHkP-0004vo-1e for submit@debbugs.gnu.org; Fri, 10 Jun 2016 04:25:02 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:52902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBHkN-0004va-Cl for 23574@debbugs.gnu.org; Fri, 10 Jun 2016 04:24:55 -0400 Original-Received: from [192.168.1.101] ([212.95.7.51]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MCwbX-1bJmCW0rgZ-009gDC; Fri, 10 Jun 2016 10:24:35 +0200 In-Reply-To: <83r3c5piq0.fsf@gnu.org> X-Provags-ID: V03:K0:lz3oALff6mYD6zUlrTOe/qiBeqmrMMXU/mKmd+P3NCLYCAgU09z 3ZySD1XoXzlZjMvJTh5gED4QVdfEPi8JGaNb83dJsse4EuQdBY2JU3fMhxTYfpHq7xdQh+y 1SdAxFkN+xJ4PE1d8pjwr33c0gCmopvvQeDEGA9ATMXJdS0nFvaciC7H3gceeiI23aYcDWa 28a2fJsxf5/zDmjcf/UpQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Vf4lR3FC3f0=:Mda+dfs588KMtLPj4T3FR+ nklDXrdF1J0Y9VkwsRU+ELpVLG1hP8djTFwI6xJBs7PPEMLA3uXjWC3Ev/dE1vzy/0UI0/BPI GfBDd9013p9rYjlz6YtL0XQaUXYnfJ5SDc68wGRih60ChlV/7ANvCX6NUVcLsC7peSlAYPNRc rhabz/4xoZFjAc5gnxAwwR7E3T6iroJVM8cPgNMK3gSyhjT60uFSHJItcsQubNH+7IO+VeP7j ZbRnn+35mpD+PmOe4zVnL2zz2zTGZ/g4N6G37k8REZMUFzJzRuu8PV7yfBjMnnsqKyVgOEfzg 12dlsy7j765HvHY2b7mjGyr+iix/quMmGIEmNb19fAbT5t6QqAi60juRmk9TW4WJ1ENlkVnuK 0pzn0u+6oangMp5tmTnSek8qfM5NurqIf4EC9LO64iZ/0j3jF8wC7VhL8zCXEG7TAf/t0Mxcq aN/JFaJvJBRhPQvE/fSR49ygSjVpPd4RqsSCd2+77knK+c+HlxLkWZxrSkQ4M03fX3NfAJh6L zoUgWXMAVm8G1hwfwJ68G/C4Qizm8laPZOVoY4hOq8KgapitnIcKB6ZRd+QBHwH/hGUr9baPs IANaP3dg3mVINVsxWbbm8ADkVonxh5YenSPtaphrXLxfyXWnojVHUWa9mkPGaDiNuLp+5wfan Uc7tFDMiwaSqllr+FebYsIQpxr6mf7E9AoNcURkWqG1QCItHKRT/WZ94lCRXM5aWq1UYrkwMD DZoFt1Dx8AdyPttHQ2zXKI7nU/Fxt/ZO0kGveUg3k94lK+d2lfynjvRJ2xGxD2/MIG0PKGyd 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:119365 Archived-At: >> 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. I meant the overhead for adding the text property to every newline character in the buffer. > 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. Are there any other significant objects but that space glyph? Is there any other way to get the size of the empty space after text on each row? > 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. Hmm... How would I get the width of that stretch glyph then? martin