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
next prev parent 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).