* bug#1175: 23.0.60; bookmark code regression
@ 2008-10-16 17:36 Chong Yidong
0 siblings, 0 replies; 6+ messages in thread
From: Chong Yidong @ 2008-10-16 17:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 1175
Stefan, I guess this is your change.
"Drew Adams" <drew.adams@oracle.com> wrote:
> 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.
>
> This breaks third-party code that calls `bookmark-jump-noselect'.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1175: 23.0.60; bookmark code regression
@ 2008-10-21 16:54 Chong Yidong
2008-10-21 17:53 ` Drew Adams
2008-10-27 13:32 ` Stefan Monnier
0 siblings, 2 replies; 6+ messages in thread
From: Chong Yidong @ 2008-10-21 16:54 UTC (permalink / raw)
To: Drew Adams; +Cc: 1175
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1175: 23.0.60; bookmark code regression
2008-10-21 16:54 Chong Yidong
@ 2008-10-21 17:53 ` Drew Adams
2008-10-22 6:20 ` Richard M. Stallman
2008-10-27 13:32 ` Stefan Monnier
1 sibling, 1 reply; 6+ messages in thread
From: Drew Adams @ 2008-10-21 17:53 UTC (permalink / raw)
To: 'Chong Yidong'; +Cc: 1175
> > 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1175: 23.0.60; bookmark code regression
2008-10-21 17:53 ` Drew Adams
@ 2008-10-22 6:20 ` Richard M. Stallman
0 siblings, 0 replies; 6+ messages in thread
From: Richard M. Stallman @ 2008-10-22 6:20 UTC (permalink / raw)
To: Drew Adams, 1175; +Cc: 1175, cyd, bug-submit-list, bug-gnu-emacs
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.
I agree with you.
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.
You are right here too. Compatibility with past Emacs releases
is more important, generally speaking, than avoiding changes in
the sources now. I am sure this function isn't used in very many places
in Emacs, so changing it back to be compatible won't be a lot of work.
There is, BTW, nothing truly "internal" when it comes to Emacs,
especially when it comes to Emacs Lisp.
That doesn't really matter. There are functions which users should
not call, and if they do, they are out of luck when we change them.
But `bookmark-jump-noselect' should not be treated that way; it is too
natural and useful.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1175: 23.0.60; bookmark code regression
2008-10-21 16:54 Chong Yidong
2008-10-21 17:53 ` Drew Adams
@ 2008-10-27 13:32 ` Stefan Monnier
1 sibling, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2008-10-27 13:32 UTC (permalink / raw)
To: Chong Yidong; +Cc: 1175
>> 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 think there's a slight disagreement: I think it's worthwhile to
preserve the old semantics of bookmark-jump-noselect, but not by
changing the current one: instead, we should rename b-j-n to something
else and write a new b-j-n wrapper.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#1175: 23.0.60; bookmark code regression
@ 2008-10-15 20:51 Drew Adams
0 siblings, 0 replies; 6+ messages in thread
From: Drew Adams @ 2008-10-15 20:51 UTC (permalink / raw)
To: emacs-pretest-bug
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.
This breaks third-party code that calls `bookmark-jump-noselect'.
In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
of 2008-10-03 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-10-27 13:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-16 17:36 bug#1175: 23.0.60; bookmark code regression Chong Yidong
-- strict thread matches above, loose matches on Subject: below --
2008-10-21 16:54 Chong Yidong
2008-10-21 17:53 ` Drew Adams
2008-10-22 6:20 ` Richard M. Stallman
2008-10-27 13:32 ` Stefan Monnier
2008-10-15 20:51 Drew Adams
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).