From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#1175: 23.0.60; bookmark code regression Date: Tue, 21 Oct 2008 10:53:09 -0700 Message-ID: <009d01c933a5$e17ff690$0200a8c0@us.oracle.com> References: <87ljwhsxb3.fsf@cyd.mit.edu> Reply-To: Drew Adams , 1175@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1224612630 28845 80.91.229.12 (21 Oct 2008 18:10:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Oct 2008 18:10:30 +0000 (UTC) Cc: 1175@emacsbugs.donarmstrong.com To: "'Chong Yidong'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 21 20:11:28 2008 connect(): Connection refused Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KsLhX-0002JS-F0 for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Oct 2008 20:11:28 +0200 Original-Received: from localhost ([127.0.0.1]:47082 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsLgR-0003aU-4n for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 Oct 2008 14:10:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsLgN-0003aB-M7 for bug-gnu-emacs@gnu.org; Tue, 21 Oct 2008 14:10:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsLgJ-0003YI-Nq for bug-gnu-emacs@gnu.org; Tue, 21 Oct 2008 14:10:15 -0400 Original-Received: from [199.232.76.173] (port=45377 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsLgJ-0003Y4-F1 for bug-gnu-emacs@gnu.org; Tue, 21 Oct 2008 14:10:11 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:42358) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KsLgH-0004Fy-BL for bug-gnu-emacs@gnu.org; Tue, 21 Oct 2008 14:10:10 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9LIA1v1027535; Tue, 21 Oct 2008 11:10:01 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m9LI02BT024347; Tue, 21 Oct 2008 11:00:03 -0700 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 21 Oct 2008 18:00:02 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 1175 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: wontfix Original-Received: via spool by 1175-submit@emacsbugs.donarmstrong.com id=B1175.122461159723100 (code B ref 1175); Tue, 21 Oct 2008 18:00:02 +0000 Original-Received: (at 1175) by emacsbugs.donarmstrong.com; 21 Oct 2008 17:53:17 +0000 Original-Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m9LHrEGq023092 for <1175@emacsbugs.donarmstrong.com>; Tue, 21 Oct 2008 10:53:15 -0700 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m9LHr5pe009314; Tue, 21 Oct 2008 12:53:06 -0500 Original-Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m9LHr4Zr019162; Tue, 21 Oct 2008 11:53:05 -0600 Original-Received: from dradamslap1 (/141.144.55.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Oct 2008 17:53:04 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ljwhsxb3.fsf@cyd.mit.edu> Thread-Index: AckznctFKhAtSlc6ScC8LE/f2xghQwAAI78w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 21 Oct 2008 14:10:15 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:21759 Archived-At: > > 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.