unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Linus Källberg" <linus.kallberg@outlook.com>
To: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>
Cc: "36550@debbugs.gnu.org" <36550@debbugs.gnu.org>
Subject: bug#36550: mouse-face overlay calculation error
Date: Sat, 13 Jul 2019 15:38:05 +0000	[thread overview]
Message-ID: <AM0PR09MB2867DE510C195B176FC680AC87CD0@AM0PR09MB2867.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <m3ims6nf9b.fsf@gnus.org>

Den 2019-07-13 kl. 17:08, skrev Lars Ingebrigtsen:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> OK, but then they simply should use a separate overlay for the
>>> mouse-face, I think, one that doesn't cover the newline.  Does that
>>> solve the problem?
>>
>> Yes, I can hack wid-edit.el as previously suggested.
> 
> OK, I took another look at the wid-edit.el code which reminded me that
> it's not that simple, because it does a lot of manipulation of the
> overlays in the most tedious way.
> 
> So I'll just leave this for somebody else to fix one rainy day...

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). I would expect it to end after 
the last character before the newline, or possibly one character further 
to the right (as if there was an imaginary space character inserted 
there). As was said earlier, it doesn't make sense to highlight parts of 
a line that doesn't contain clickable text.

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). 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 :-)

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:

diff --git "a/lisp/recentf.el" "b/lisp/recentf.el"
index 4112b44e48..5d832a9d37 100644
--- "a/lisp/recentf.el"
+++ "b/lisp/recentf.el"
@@ -1179,9 +1179,9 @@ IGNORE other arguments."
      ;; Represent a single file with a link widget
      `(link :tag ,(car menu-element)
             :button-prefix ""
-           :button-suffix ""
+           :button-suffix " "
             :button-face default
-           :format "%[%t\n%]"
+           :format "%[%t%]\n"
             :help-echo ,(concat "Open " (cdr menu-element))
             :action recentf-open-files-action
             ;; Override the (problematic) follow-link property of the

Best regards,
Linus Källberg





  reply	other threads:[~2019-07-13 15:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-08 12:54 bug#36550: Small bug fix in recentf.el Linus Källberg
2019-07-08 19:58 ` Lars Ingebrigtsen
     [not found]   ` <AM0PR09MB2867529A5BCE4551365F142C87F60@AM0PR09MB2867.eurprd09.prod.outlook.com>
2019-07-09 13:04     ` Lars Ingebrigtsen
2019-07-11 16:34       ` Linus Källberg
2019-07-12 15:07         ` Lars Ingebrigtsen
2019-07-13  0:31         ` bug#36550: mouse-face overlay calculation error Lars Ingebrigtsen
2019-07-13  6:15           ` Eli Zaretskii
2019-07-13 13:10             ` Lars Ingebrigtsen
2019-07-13 13:23               ` Eli Zaretskii
2019-07-13 13:50                 ` Lars Ingebrigtsen
2019-07-13 14:17                   ` Eli Zaretskii
2019-07-13 14:25                     ` Lars Ingebrigtsen
2019-07-13 14:50                       ` Eli Zaretskii
2019-07-13 15:05                         ` Lars Ingebrigtsen
2019-07-13 15:08                           ` Lars Ingebrigtsen
2019-07-13 15:38                             ` Linus Källberg [this message]
2019-07-13 15:49                               ` Eli Zaretskii
2019-07-13 19:49                                 ` Linus Källberg
2019-07-14  5:30                                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM0PR09MB2867DE510C195B176FC680AC87CD0@AM0PR09MB2867.eurprd09.prod.outlook.com \
    --to=linus.kallberg@outlook.com \
    --cc=36550@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).