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

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.


Eshel