bug#81467: [PATCH] Make bookmark-jump work with other-window/frame/tab-prefix

On Wed, Jul 29, 2026 at 11:36 AM Eshel Yaron <[email protected]> wrote:

> Stéphane Marks <[email protected]> writes:
>
> > On Wed, Jul 29, 2026 at 9:54 AM Eshel Yaron <[email protected]> wrote:
> >
> >  Stéphane Marks <[email protected]> writes:
> >
> >  > On Wed, Jul 29, 2026 at 2:49 AM Eshel Yaron <[email protected]>
> wrote:
> >  >
> >  >  diff --git a/lisp/bookmark.el b/lisp/bookmark.el
> >  >  index 77136308573..30b4da9c1b2 100644
> >  >  --- a/lisp/bookmark.el
> >  >  +++ b/lisp/bookmark.el
> >  >  @@ -305,7 +305,10 @@ bookmark-alist
> >  >   HANDLER is a function that provides the `bookmark-jump' behavior
> for a
> >  >   specific kind of bookmark instead of the default
> `bookmark-default-handler'.
> >  >   This is the case for Info bookmarks, for instance.  HANDLER must
> accept
> >  >  -a bookmark as its single argument.
> >  >  +a bookmark as its single argument.  HANDLER should set the current
> >  >  +buffer (e.g. with `set-buffer') and optionally set point in that
> buffer.
> >  >  +The command that invokes HANDLER displays the buffer that HANDLER
> leaves
> >  >  +as current.
> >  >
> >  >   A function `bookmark-make-record-function' may define additional
> entries
> >  >   in PARAM-LIST that can be used by HANDLER.")
> >  >
> >  > I think not.  The prevalence of bookmark handlers in the wild that
> have accumulated without such
> >  > guidance suggests it's a bit too late and we need other mitigations.
> We could adopt language that
> >  > recommends such a policy but not ban it which risks lots of noise
> from users.
> >
> >  It doesn't ban anything, it only describes how the handler is used.
> >  So I don't think I understand your objection, sorry.
> >
> > At the very least, it is not correct to say "The command that invokes
> HANDLER displays the buffer that
> > HANDLER leaves as current."  For example, if display-function is ignore,
> as is the case for the bufferlo
> > advice I detest, this would not be true as bufferlo handles display on
> its own.  As the OP pointed out, an
> > Emacs built-in case is shell-bookmark-jump which calls shell which calls
> pop-to-buffer.
>
> shell-bookmark-jump is not a command, it is a handler.
> The command that invokes that handler goes on to display whichever
> buffer the handler leaves as current.  That's just how bookmark commands
> (currently) work.  The above diff is just an attempt to document it. :)
>

How about we add a new property to bookmark handlers.  Just as we have
properties like (get handler 'bookmark-handler-type), we can add a new one
that indicates a handler handles its own display and we'd ignore
display-function in bookmark--jump-via when that property is present (or a
specific value).  I'd amend the bufferlo handlers to include that property
and I'd also submit a patch for shell-bookmark-jump (which I also wrote).
Perhaps in the bufferlo case, it the property could indicate a "strong"
value as in do not display-function ever vs. shell-bookmark-jump which
could be advisory if display-function is not #'ignore, perhaps.