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

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.