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 15:59:41 +0200 Message-ID: <575AC7CD.1030506@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> <575A793E.7090302@gmx.at> <83k2hxpe3a.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 1465567291 11977 80.91.229.3 (10 Jun 2016 14:01:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 14:01: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 16:01:20 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 1bBMzv-0008K5-UM for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jun 2016 16:01:20 +0200 Original-Received: from localhost ([::1]:41273 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBMzv-0003dr-CR for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jun 2016 10:01:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBMzk-0003d3-Cf for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 10:01:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBMze-0007VU-D6 for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 10:01:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBMze-0007VJ-9R for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 10:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bBMze-000198-35 for bug-gnu-emacs@gnu.org; Fri, 10 Jun 2016 10:01: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 14:01: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.14655672114334 (code B ref 23574); Fri, 10 Jun 2016 14:01:02 +0000 Original-Received: (at 23574) by debbugs.gnu.org; 10 Jun 2016 14:00:11 +0000 Original-Received: from localhost ([127.0.0.1]:35898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBMyp-00017q-1V for submit@debbugs.gnu.org; Fri, 10 Jun 2016 10:00:11 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:61387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bBMyn-00016r-L4 for 23574@debbugs.gnu.org; Fri, 10 Jun 2016 10:00:10 -0400 Original-Received: from [192.168.1.101] ([212.95.7.51]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MHH3P-1bFXhy3Mvb-00E350; Fri, 10 Jun 2016 15:59:45 +0200 In-Reply-To: <83k2hxpe3a.fsf@gnu.org> X-Provags-ID: V03:K0:0DauoN2nVTg6Yu1Ejag1fl/igdriIM44JCIvz7tSbkkacnaW73B 1z2wGSW0XnU0OxQqXp2P6WY+yvKBnFIu/j5sWKQRHTRfNIhp3CDYSOjHWU9NMEbat0TMUyF MbXIr1JuQLivoy9lVcsVF9m4ltVY1k6Q36lHWDQrpXZoTlGy2hM4xlHjeLAkncZ4/+131kn hmcN270kcll13cy8v67tA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Hw/6FTHyD/A=:WwAAeBud8BuUwCnNBDRseS 8EsgRjYq6w1utwqQ+0uqAhmuJBqt7HJW2wB7AhdBLPc0SGZ5ccGwDBegeua/Cn5FfaWJkyZy9 ciVFLWG9OLIKdTmoq7xl9yD4FfUCbgtyyXZQJb8CFCY3K5yZIZiCCIpJCi6TzK0Qdo8968Vjl v0H0jnXpLmh9+g8sSvv6jw2oRDYBboNnzp5lYxFuWNj5u7NnLxrzJyOE0lyt+9BAx+7D+hOiW HGe+nwIS+b3jdd/gMJrRUEuEuWybF7t/g8JvUxA0eAZgEZVYX17o0CTeDSok4hjBt6NVEPQqZ zH15hlr9rWX2Edp0COOZlVfwIm4bD/NuKvgpWEXtSubJCZaaMEPGswoZoTkKJBtAXrc9luzVq 5/GrAVdGBooHlKEJ71+SSGMmwFxI41DtVu23dfbbK1IuSoDSXhbXOtJUVBijnC9+s9gmzCL4H mxxJT25rstCmJg9v2fKsZQ0A+dMAcWHy/UjKxcNZUvJyGDrxRPdsNi7kREp0QGqJE/JHKhv2S guvgk8NtJJ+vXX4T0LK+eIySNPvxlj5qfOnrLrRvhYlEPyKOl5qrcq1S4S7v0R9rtFy/ZcG5B SlrNbbr5Hi3Y10SQm4KKfwWhdH1oU7Mvl9t3gqMdPz4+7eTYBCtyv87SuSWsHXeNdkgg4nXmZ FJOtfjLAVjCK94SWA4vL9I0M11XWMG0RqYTUa21M0RvaVUIiRzaTdiio6bTCcHLx2qUtgP7BL 0TSWd9seKRFZJIS1NAzCqzMxwe2+WBw5f9CsVSfxl+6YmCR7Mf2N0A4wr4OCfNH+13BJvtoj 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:119381 Archived-At: >> I meant the overhead for adding the text property to every newline >> character in the buffer. > > You mean, memory overhead? I don't think it's significant. I meant the time overhead to find each newline (or the character before it) in the buffer and put the property on it. > Yes, a few. Look at the comments at the beginning of 'struct glyph' > definition in dispextern.h. These ones glyph standing for newline at end of line 0 empty space after the end of the line -1 overlay arrow on a TTY -1 ... ? >> Is there any other way to get the size of the empty space after text >> on each row? > > "Other way"? other than what? Other than subtracting the pixel_width from the window text width. I obviously want to just retrieve a calculated value, not recalculate it. >> > 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? > > It's recorded in the glyph's pixel_width. So for R2L text to get the width of the empty space on the left of a row I have to calculate the pixel_width of the leftmost character on that row. Something like the following for a given row? struct glyph *glyph = row->glyphs[TEXT_AREA]; width = glyph->pixel_width; > Or maybe I don't understand > the problem you are trying to solve. I want to put a mini-frame in the empty space on the right side of a L2R window and accordingly on the left side of a R2L window. I more or less know how to do the former but have not yet tried the latter. martin