From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36550: mouse-face overlay calculation error Date: Sun, 14 Jul 2019 08:30:22 +0300 Message-ID: <83ims5yyhd.fsf@gnu.org> 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: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="181630"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36550@debbugs.gnu.org, larsi@gnus.org To: Linus =?UTF-8?Q?K=C3=A4llberg?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 14 07:31:10 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 1hmX6L-000l6s-3L for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Jul 2019 07:31:09 +0200 Original-Received: from localhost ([::1]:59018 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmX6J-0005n2-DB for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Jul 2019 01:31:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46607) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmX6F-0005lW-IT for bug-gnu-emacs@gnu.org; Sun, 14 Jul 2019 01:31:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hmX6E-0003Bl-6L for bug-gnu-emacs@gnu.org; Sun, 14 Jul 2019 01:31:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34904) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hmX6E-0003BX-26 for bug-gnu-emacs@gnu.org; Sun, 14 Jul 2019 01:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hmX6D-0003kA-UB for bug-gnu-emacs@gnu.org; Sun, 14 Jul 2019 01:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Jul 2019 05:31: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.156308224714370 (code B ref 36550); Sun, 14 Jul 2019 05:31:01 +0000 Original-Received: (at 36550) by debbugs.gnu.org; 14 Jul 2019 05:30:47 +0000 Original-Received: from localhost ([127.0.0.1]:43725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmX5y-0003jh-S0 for submit@debbugs.gnu.org; Sun, 14 Jul 2019 01:30:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34165) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmX5x-0003jU-0q for 36550@debbugs.gnu.org; Sun, 14 Jul 2019 01:30:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47750) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hmX5r-00032K-72; Sun, 14 Jul 2019 01:30:39 -0400 Original-Received: from [176.228.60.248] (port=4559 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hmX5q-0001pV-E0; Sun, 14 Jul 2019 01:30:39 -0400 In-reply-to: (message from Linus =?UTF-8?Q?K=C3=A4llberg?= on Sat, 13 Jul 2019 19:49:07 +0000) 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: 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:162964 Archived-At: > From: Linus Källberg > CC: "larsi@gnus.org" , "36550@debbugs.gnu.org" > <36550@debbugs.gnu.org> > Date: Sat, 13 Jul 2019 19:49:07 +0000 > > > 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 > overlays that contain newline characters, period, or simply those that > have a newline character as their *last* character? The latter. > I understand that a newline character cannot be clicked or highlighted > if it has no glyph in the text, but why can't it then simply not be > highlighted? Because the algorithm to find what is the last glyph to be highlighted is very complicated (since it cannot rely on buffer positions changing monotonously with screen coordinates) and in this case it yields a result that looks wrong. If someone wants to find how to change the algorithm so that it also covers this niche use case, feel free. > is it really intended, in the sense that something else would break > if it was "fixed"? It depends on the fix. I cannot tell until I see a proposal for such a fix. The existing code relies on some properties of glyphs as they are laid out for display, and one of those properties is that the screen line's end position is the position of the first character on the next line. That's why you see what you see in this case. > >> or possibly one character further to the right (as if there was an > >> imaginary space character inserted there). > > > > 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 > highlighted text, and when an overlay contains a newline character > (anywhere, not necessarily at the end), there is always one extra > "imaginary" character underlined after the last character before the > line break. This is something specific to mouse-face, because unlike other faces, it works with characters on display, not in the buffer. > 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)))) Yes, as expected. > >> 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). > > > > 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 > everything. Yes, I suggested to use a separate overlay for that. > > 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 > problem, which, if not in the display code, might be in the > implementation of the button widget. Fine with me, if someone wants to work on that.