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: Sat, 13 Jul 2019 18:49:54 +0300 Message-ID: <83tvbqylwd.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> 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="117775"; 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 Sat Jul 13 17:51: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 1hmKIm-000UWS-2e for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2019 17:51:08 +0200 Original-Received: from localhost ([::1]:56944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmKIl-0004N4-5Y for geb-bug-gnu-emacs@m.gmane.org; Sat, 13 Jul 2019 11:51:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38992) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmKIh-0004Mr-O0 for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 11:51:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hmKIg-00017u-MV for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 11:51:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34392) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hmKIg-00017n-J1 for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 11:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hmKIg-000537-Gm for bug-gnu-emacs@gnu.org; Sat, 13 Jul 2019 11:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jul 2019 15:51:02 +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.156303301719313 (code B ref 36550); Sat, 13 Jul 2019 15:51:02 +0000 Original-Received: (at 36550) by debbugs.gnu.org; 13 Jul 2019 15:50:17 +0000 Original-Received: from localhost ([127.0.0.1]:43206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmKHw-00051R-SK for submit@debbugs.gnu.org; Sat, 13 Jul 2019 11:50:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmKHu-000519-EG for 36550@debbugs.gnu.org; Sat, 13 Jul 2019 11:50:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hmKHo-0000Kx-Ub; Sat, 13 Jul 2019 11:50:08 -0400 Original-Received: from [176.228.60.248] (port=2360 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hmKHo-0004DZ-Ac; Sat, 13 Jul 2019 11:50:08 -0400 In-reply-to: (message from Linus =?UTF-8?Q?K=C3=A4llberg?= on Sat, 13 Jul 2019 15:38:05 +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:162913 Archived-At: > From: Linus Källberg > 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). 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. > I would expect it to end after the last character before the newline Can't do that, because the newline is also covered by the face. > 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. > 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? > However, due to the "bug" in question (if it is indeed a bug), when > hovering the mouse over a link, the whole line (up to the right edge > of the window) and the first character on the next line is > highlighted. I have been using Emacs, and the recentf package, for > only five years, but I always thought that this looked ugly and > somewhat "buggy". The other day I was a bit cranky and decided to > look into it :-) Indeed, the mouse-face should end before the newline. > 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: 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. Thanks.