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

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:
> >
> >  Stéphane Marks <[email protected]> writes:
> >
> >  > On Tue, Jul 28, 2026 at 1:42 PM Eshel Yaron <[email protected]>
> wrote:
> >  >
> >  >  Juri Linkov <[email protected]> writes:
> >  >
> >  >  >> It doesn't make much sense for bookmark--jump-via to ignore the
> >  >  >> DISPLAY-FUNCTION argument, no matter what the handler does, IMO.
> >  >  >> The contract for bookmark handlers is that someone else (the
> caller,
> >  >  >> not the handler) displays the bookmarked buffer; if the handler
> >  >  >> nevertheless displays the bookmarked buffer (or any other buffer),
> >  >  >> that's the handler's fault/responsibility.
> >  >  >
> >  >  > All handlers display the bookmarked buffer.  I can't find a handler
> >  >  > that doesn't display it.
> >  >
> >  >  Hmm?  See the default handler, bookmark-default-handler.
> >  >  Man-bookmark-jump is also conforming, for instance.
> >  >
> >  > This conformance you speak of is undocumented.
> >
> >  Shall we fix that?  Maybe like this?
> >
> >  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.