Subject: RE: 23.0.60; bookmark code regression

From: "Drew Adams" <[email-masked]>
Date: Tue, 21 Oct 2008 10:53:09 -0700

> > Please, please restore the sane behavior of `bookmark-jump-noselect'
> > as it was for Emacs 22: it should return a cons (BUFFER . 
> > POINT) when a bookmark is located.
> 
> I discussed with Stefan.  Since bookmark-jump-noselect is an internal
> function of bookmark.el, we don't guarantee that its behavior is
> unchanged across Emacs versions.  Furthermore, the
> bookmark-jump-noselect not only returned (BUFFER . POINT) but also
> preserved the current buffer (and point) instead of changing 
> buffer and moving point, whereas the new version does change buffer
> and point.  So it doesn't make sense to change the return value of
> the new version.

I was afraid you might come back with a copout such as saying it is an
internal-only function. I disagree, obviously, or I wouldn't have filed the bug.

This is analogous to `find-file-noselect'. `bookmark-jump-noselect' is an
obvious choice for some function to call, to obtain the bookmark buffer and
buffer position. Without actually displaying it - perhaps because some other
display mechanism is preferred or perhaps because some other manipulation is to
be performed.

You have decided to couple (hard-code) obtaining the buffer and position with
the act of displaying it. Bad design.

It is irrelevant whether the old and new `bookmark-jump-noselect's differ in
which buffer and position are current after they are called. No one asked you to
preserve the current buffer and point - that's not what this is about. This bug
is about the return value (only).

What's important is to be able to obtain the buffer and position indicated by
the argument BOOKMARK. The only function that does that (er, did that) is
`bookmark-jump-noselect'.

This is what I must do now, to give you an idea:

(let ((cell  (bookmark-jump-noselect bookmark)))
  (when (> emacs-major-version 22) ; UGLY HACK
   (setq cell (cons (current-buffer) (point))))
  (when cell
    ...))

You've given no reason why `bookmark-jump-noselect' should *not* continue to
return (BUFFER . POINT) - none whatsoever.

And you even phrase your refusal in terms of not wanting to *change*: "it
doesn't make sense to change the return value of the new version". What
chutzpah. Emacs 23 has not even been released, so please don't speak of
"changing" from the Emacs 23 behavior to what has always been the behavior
before. That language betrays a myopic view of Emacs development: any difference
from the current behavior is interpreted as a "change" request.

Change is what you've done (with no discussion or change request ;-), it is not
what I'm requesting. You've changed the return value. Please *do not* change it
- return the same value as Emacs always has: (BUFFER . POINT). Restore the
behavior that's been broken.

There is, BTW, nothing truly "internal" when it comes to Emacs, especially when
it comes to Emacs Lisp. And in this case, there is no reason to consider
`buffer-jump-noselect' somehow off-limits for use by others.

And as to guarantees about things not changing from one release to another -
that's a joke. You've never guaranteed backward compatibility even for the most
non-internal of features. Backward compatibility is hardly one of the strong
points of Emacs development. AFAICT, it is no concern whatsoever of the
developers. Whenever it is brought up it is rebuked as a non-concern.

Please reconsider. 

1. There is no other function that provides the buffer and position of a
bookmark. That is one of the obvious uses/purposes of `buffer-jump-noselect' -
or at least it has been until the behavior was broken by this change. Sure, a
user can write such a function using the hack shown above, but s?he shouldn't
have to.

2. There is no reason not to return the same value as before: (BUFFER . POINT).
You have given no such reason, and the return value is not specially used by the
current code. There is no harm in continuing to return something that can be
useful outside `bookmark.el'.

Please try to think more openly, not so narrowly, about the changes you make.
Coupling determination of bookmark location with display is just plain bad. And
unnecessary - nothing is gained by that coupling, and nothing will be lost by
decoupling the two a bit.