From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Linus =?UTF-8?Q?K=C3=A4llberg?= Newsgroups: gmane.emacs.bugs Subject: bug#36550: mouse-face overlay calculation error Date: Sat, 13 Jul 2019 19:49:07 +0000 Message-ID: References: <87v9wc2t8p.fsf@mouse.gnus.org> <831ryu31fc.fsf@gnu.org> <834l3q132a.fsf@gnu.org> <83zhliyq5p.fsf@gnu.org> <83y312yony.fsf@gnu.org> <83tvbqylwd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="29150"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "36550@debbugs.gnu.org" <36550@debbugs.gnu.org>, "larsi@gnus.org" To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 13 21:50:09 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hmO25-0007TY-0k for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2019 21:50:09 +0200 Original-Received: from localhost ([::1]:57810 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmO23-0005D0-L6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2019 15:50:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48048) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmO1z-0005BU-Id for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 15:50:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hmO1y-0001p5-AA for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 15:50:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34590) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hmO1y-0001oq-4E for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 15:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hmO1y-0004xO-0n for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 15:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Linus =?UTF-8?Q?K=C3=A4llberg?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 19:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36550 X-GNU-PR-Package: emacs Original-Received: via spool by 36550-submit@debbugs.gnu.org id=B36550.156304735918995 (code B ref 36550); Sat, 13 Jul 2019 19:50:01 +0000 Original-Received: (at 36550) by debbugs.gnu.org; 13 Jul 2019 19:49:19 +0000 Original-Received: from localhost ([127.0.0.1]:43411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmO1G-0004wJ-Kh for submit@debbugs.gnu.org; Sat, 13 Jul 2019 15:49:19 -0400 Original-Received: from mail-oln040092067083.outbound.protection.outlook.com ([40.92.67.83]:56385 helo=EUR02-AM5-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmO1C-0004w1-0O for 36550@debbugs.gnu.org; Sat, 13 Jul 2019 15:49:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cCAkIj4xSd7sjoNI+PQq1j4c0oZ+p0KNiE7RwlsKKQM=; b=qXo+Wmo/BBHYgvfpS09UY9RtD/1HUc9UIlXQDkOvaoylmrcmOvTtGDTwA9ViNZhPsqztHwj02Omk50qc7gjob7+PGKQwi57+IBKpUWHtFfXpeRu4XFv6/T2VVangFHBEpW81IU8C8kXAysVR3xEkc1VMfVoYnaVcoFt1/if8W0x2fyNv7LskHzxIjHta5+ZmXTBg2K4HDCHl6LdrTTUVLoiROGJIy1skydy7mlLswlieFZGdMff8GxR/fG+YRBmFDHaKw+bF4aP8WUxhSPFp8YbansC+R20r2KVKFOPqKe9WBsxhNPKqkVg0DHt9OULgNKhLfEIew3djvjN/IoBxjQ== Original-Received: from VE1EUR02FT041.eop-EUR02.prod.protection.outlook.com (10.152.12.52) by VE1EUR02HT175.eop-EUR02.prod.protection.outlook.com (10.152.13.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.19; Sat, 13 Jul 2019 19:49:07 +0000 Original-Received: from AM0PR09MB2867.eurprd09.prod.outlook.com (10.152.12.57) by VE1EUR02FT041.mail.protection.outlook.com (10.152.13.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.19 via Frontend Transport; Sat, 13 Jul 2019 19:49:07 +0000 Original-Received: from AM0PR09MB2867.eurprd09.prod.outlook.com ([fe80::bc7b:8964:ba14:f6a2]) by AM0PR09MB2867.eurprd09.prod.outlook.com ([fe80::bc7b:8964:ba14:f6a2%3]) with mapi id 15.20.2073.012; Sat, 13 Jul 2019 19:49:07 +0000 Thread-Topic: bug#36550: mouse-face overlay calculation error Thread-Index: AQHVORJK1h+C6vMxBU6hzne99E+cCabIEqsEgABzzsSAAAOtSIAAB6shgAAHoW6AAAIcgIAABvVjgAAEILGAAAD+AoAACBUAgAADc+yAAEKwAA== In-Reply-To: <83tvbqylwd.fsf@gnu.org> Accept-Language: sv-SE, en-US Content-Language: en-US x-clientproxiedby: HE1P195CA0014.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::24) To AM0PR09MB2867.eurprd09.prod.outlook.com (2603:10a6:208:134::10) x-incomingtopheadermarker: OriginalChecksum:13C90370B233140F963F48FC2B8B04E39C4AA25BC998AB6D2E8A275AE0D21459; UpperCasedChecksum:AEAF75767ED45B2D375ED2369E87FE620E7C4FA86C3CCA3E601BCB10FC71623F; SizeAsReceived:8133; Count:49 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [c/zqQWJ4/SaIFfiKFJuKwQIuxnDqlQh0] x-microsoft-original-message-id: <6fe53262-9db7-d528-561b-3a355085fc84@outlook.com> x-ms-publictraffictype: Email x-incomingheadercount: 49 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:VE1EUR02HT175; x-ms-traffictypediagnostic: VE1EUR02HT175: x-microsoft-antispam-message-info: 2luit2QHSjDDtOUPcot9dpHvEn0ZCoRj2BHm97wNyQ/SogDpp3nLy7ZaWo1b1A7UvJvYD7qxbsLfSYEN82U/IcyMhZn4TwCSM61HdMBxB5ZyIhNRtPqpGBCudne9jRYZMBhqoiD2Zf2lx9ydzTcJbRI7BwxzFHH+Wxi0Yn1wb2192Pqoh2SOa5msBZFt+fqM Content-ID: <74A1D792E0E63B4EB093EECF694CFE78@eurprd09.prod.outlook.com> X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 3df12c30-3dd2-4ddc-135b-08d707cb2a93 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2019 19:49:07.2940 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT175 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: 209.51.188.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:162936 Archived-At: Den 2019-07-13 kl. 17:49, skrev Eli Zaretskii: >> From: Linus K=E4llberg >> CC: "36550@debbugs.gnu.org" <36550@debbugs.gnu.org> >> Date: Sat, 13 Jul 2019 15:38:05 +0000 >> >> I might have misunderstood the discussion, but just to clarify my >> opinion, if the overlay ends with a newline character, the mouse-face >> should *not* extend to the right edge of the window (and definitely not >> to the first character on the next line). >=20 > But that's not what mouse-face means and does. It highlights > mouse-sensitive text, and thus it should NOT include a newline, > because a newline does not have a glyph in the buffer text. That's > why you see the 1st character on the next line highlighted: it's the > next character after the newline, and since the newline is absent, it > gets highlighted instead, because when character positions are not > monotonous with screen coordinates, we have no alternative but > highlight that next character. Are you saying that the mouse-face property should not be used on=20 overlays that contain newline characters, period, or simply those that=20 have a newline character as their *last* character? I must say, it does=20 seem like a bug that the appearance of characters not even included in=20 the overlay (i.e., the first character on the next line) is changed when=20 hovering the mouse over it. I understand that a newline character cannot be clicked or highlighted=20 if it has no glyph in the text, but why can't it then simply not be=20 highlighted? Why must the first character on the next line be=20 highlighted instead? No doubt it is difficult to change this behavior=20 due to the complicated logic involved, but is it really intended, in the=20 sense that something else would break if it was "fixed"? >> or possibly one character further to the right (as if there was an >> imaginary space character inserted there). >=20 > Can't do that, because that imaginary character doesn't exist, and > therefore we cannot possible access its buffer position. But doesn't it already do that? I use an Emacs theme that underlines=20 highlighted text, and when an overlay contains a newline character=20 (anywhere, not necessarily at the end), there is always one extra=20 "imaginary" character underlined after the last character before the=20 line break. In this example, there is one extra underlined character after "foo": (progn (load-theme 'wombat t) (let ((point (point))) (insert "foo\nbar") (let ((o (make-overlay point (point)))) (overlay-put o 'mouse-face 'highlight)))) >> In recentf, the newline after the file name is included in each link so >> that if point is positioned right after the last character -- which >> happens, e.g., if one i-searches for a file extension -- one can simply >> press enter to open the file (as said in the commit message). >=20 > But pressing Enter doesn't require mouse-face, does it? It requires > an overlay with a suitable keymap property, right? Exactly, I guess the button widget simply uses the same overlay for=20 everything. >> As I said earlier, one way to fix the issue in recentf is simply to move >> the newline outside of the link, but put a space character after each >> file name. This way, the mouse-over highlights look okay, and one can >> still i-search for a file extension and then simply press enter. Here is >> a patch that does this: >=20 > If this fixes the issue, it's fine with me. However, I think we > should have a comment there explaining why we add this space > character. Yes, a comment should be added. However, I would prefer fixing the real=20 problem, which, if not in the display code, might be in the=20 implementation of the button widget. Best regards, Linus K=E4llberg