From: Karl Fogel <kfogel@red-bean.com>
To: Dani Moncayo <dmoncayo@gmail.com>
Cc: 70019@debbugs.gnu.org, Emacs Developers <emacs-devel@gnu.org>
Subject: bug#70019: [PATCH] Fix two bugs in removing bookmark fringe marks (bug#70019)
Date: Sun, 21 Apr 2024 22:51:43 -0500 [thread overview]
Message-ID: <87jzkqawc0.fsf__49272.5300182187$1713757995$gmane$org@red-bean.com> (raw)
In-Reply-To: <CAH8Pv0hOzmFo1AwYSRi1kxkaH7T316S_SuPuOQuGVzhWTJ9T8g@mail.gmail.com> (Dani Moncayo's message of "Sat, 20 Apr 2024 08:50:30 +0200")
On 20 Apr 2024, Dani Moncayo wrote:
>On Sat, Apr 20, 2024 at 2:54 AM Karl Fogel <kfogel@red-bean.com>
>wrote:
>> Nope, you didn't make any mistake. I see the problem; please
>> try this revised version, and thank you for testing.
>
>OK. With this second patch, I don't see the first problem [1]
>anymore, but I keep seeing the second one [2].
Ah, I'm sorry, I meant to discuss that second problem here. For
reference, here's your description of it:
> 1. Open some *info* manual and set a named bookmark there.
> E.g. [C-h r C-x r m f o o RET].
> 2. Kill the *info* buffer and open it again: [C-x k RET C-h r].
>
> When I do that, I don't see the bookmark icon in the fringe
> (wrong).
>
> But I _do_ see the icon if I _jump_ to the bookmark: [C-x r b f
> o o RET]
This is the expected behavior, I think.
Let me explain why I believe that. If you or someone can point
out why this reasoning is wrong, I'd appreciate it.
In general, there's no mechanism for a bookmark fringe mark to be
shown when one goes to a bookmarked location by some means *other*
than through a bookmark function.
For example,
1. Find a file "SomeFile" in your home directory.
2. Create new bookmark "foo" on the first line.
(Now you see a fringe mark.)
3. Kill the buffer entirely.
4. Use [C-x C-f] to find "SomeFile" into a buffer again.
(Now you don't see a fringe mark.)
5. Kill the buffer again.
6. Use [C-x r b] (`bookmark-jump') to visit bookmark "foo"
(Now you see the fringe mark again.)
The reason the fringe mark appears in Step 6 is because the
bookmark code had a chance to get involved (i.e.,
`bookmark--set-fringe-mark' got called somewhere along the way
from `bookmark-jump').
In general, if you set a bookmark in a buffer, and you merely
*leave* the buffer but don't kill the buffer (e.g., you do
`bury-buffer' or something), then that fringe mark will still be
there when you come back. The fringe mark will also be placed if
you get to the location via `bookmark-jump', and if you set a
bookmark there with `bookmark-set'.
Also, if you retarget bookmark "foo" to point to a new location,
then if there's some buffer currently displaying the old target of
"foo", that old buffer's corresponding fringe mark for "foo" will
get removed (bug #1 that I just fixed was about a special case of
this behavior).
Now let's look at how this all works with Info nodes:
Often, two Info nodes are actually in the same file. This was the
case with the two that you used in your reproduction recipe: the
"Distrib" node and the "Intro" node in the Emacs manual -- both
are in emacs.info.gz, which is located at
/usr/local/share/info/emacs.info.gz for me (but might be somewhere
else for you).
When two Info nodes X and Y are in the same underlying file, then
if you put a bookmark in node X, the fringe mark will stay there
even if you go visit node Y and then come back to X (assuming you
didn't do anything to kill the "*info*" buffer along the way).
This is because the buffer has never been killed and the
underlying file that it's visiting has not actually changed.
But imagine that your two nodes X and Y were in two different Info
files. If you set a bookmark in X and then go visit Y, and then
come back to X (but not by using `bookmark-jump'), the fringe mark
will be gone from from X.
So in your reproduction recipe quoted above, when you kill the
"*info*" buffer, you're killing the buffer that's visiting that
particular Info file. When you visit that same Info node again
via a non-bookmark route, there's no code that magically knows
that there is a bookmark located here, and so no fringe mark is
displayed. On the other hand, when you use `bookmark-jump' to
jump to the bookmark, then of course the bookmark code has a
chance to put the fringe mark back.
By the way, I am not claiming that this behavior is ideal. It
would be wonderful if all of Emacs *did* magically have a way to
know when a line associated with some bookmark is being displayed,
so we could show a fringe mark there.
But I can't think of any reasonable way to implement that. By
"reasonable", I mean worth the complexity involved (I'm also not
sure how to do it without an unacceptable performance penalty, but
I haven't thought hard about it, because I'm pretty sure that if
one *were* able to do it without a big performance hit, then the
solution would be far more complex than a fringe mark is worth).
Best regards,
-Karl
next prev parent reply other threads:[~2024-04-22 3:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87r0f26ia6.fsf@red-bean.com>
2024-04-19 8:01 ` bug#70019: [PATCH] Fix two bugs in removing bookmark fringe marks (bug#70019) Dani Moncayo
[not found] ` <CAH8Pv0i6U8iCV_HsezSq4gZB7p-SemEBjYBf-3_GdiTV0_wfsg@mail.gmail.com>
2024-04-20 0:54 ` Karl Fogel
[not found] ` <87zftoq2fp.fsf@red-bean.com>
2024-04-20 6:50 ` Dani Moncayo
[not found] ` <CAH8Pv0hOzmFo1AwYSRi1kxkaH7T316S_SuPuOQuGVzhWTJ9T8g@mail.gmail.com>
2024-04-22 3:51 ` Karl Fogel [this message]
[not found] ` <87jzkqawc0.fsf@red-bean.com>
2024-04-22 6:26 ` Dani Moncayo
[not found] ` <CAH8Pv0iM8Xkph=Ts2vpeKjCUga_RWEujUF=EnNo2SbE3GCxuTg@mail.gmail.com>
2024-04-22 7:40 ` Eli Zaretskii
[not found] ` <86zftl6e11.fsf@gnu.org>
2024-04-22 22:21 ` Karl Fogel
2024-03-26 20:30 bug#70019: 30.0.50; bookmark-set: fringe icon (again) Dani Moncayo
2024-04-19 5:19 ` bug#70019: [PATCH] Fix two bugs in removing bookmark fringe marks (bug#70019) Karl Fogel
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='87jzkqawc0.fsf__49272.5300182187$1713757995$gmane$org@red-bean.com' \
--to=kfogel@red-bean.com \
--cc=70019@debbugs.gnu.org \
--cc=dmoncayo@gmail.com \
--cc=emacs-devel@gnu.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).