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#16542: 24.3.50; When finding a file via a bookmark, that file is not part of file-name-history Date: Sat, 25 Jan 2014 00:42:29 -0800 (PST) Message-ID: References: <87lhy5kqa9.fsf@bzg.ath.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1390639403 8605 80.91.229.3 (25 Jan 2014 08:43:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jan 2014 08:43:23 +0000 (UTC) Cc: 16542@debbugs.gnu.org To: Dani Moncayo , Bastien Guerry Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 25 09:43:28 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W6yps-00086f-7I for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Jan 2014 09:43:28 +0100 Original-Received: from localhost ([::1]:50326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6ypr-0000Ym-OO for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Jan 2014 03:43:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6ypf-0000YU-VP for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 03:43:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6ypS-0000iR-9m for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 03:43:15 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6ypS-0000iN-6G for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 03:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W6ypR-0000Cd-NJ for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 03:43:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Jan 2014 08:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16542-submit@debbugs.gnu.org id=B16542.1390639357743 (code B ref 16542); Sat, 25 Jan 2014 08:43:01 +0000 Original-Received: (at 16542) by debbugs.gnu.org; 25 Jan 2014 08:42:37 +0000 Original-Received: from localhost ([127.0.0.1]:35052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W6yp2-0000Bv-NC for submit@debbugs.gnu.org; Sat, 25 Jan 2014 03:42:37 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:39179) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W6yp0-0000Bm-Ro for 16542@debbugs.gnu.org; Sat, 25 Jan 2014 03:42:35 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0P8gT0a024772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Jan 2014 08:42:30 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0P8gSGr024105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jan 2014 08:42:29 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0P8gS2d013196; Sat, 25 Jan 2014 08:42:28 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:83971 Archived-At: > FWIW: There are other cases (besides "via the bookmarks buffer") where > a file is visited but not added to the file-name-history. >=20 > Bug #12915 contains a general discussion about the matter. Yes, thank you, Dani. FWIW, I will repeat just this part from my post in that thread: The proper solution is for commands that read file names to DTRT wrt `file-name-history' - TRT for that command. ^^^^^^^^^^^^^^^^^^^^ IOW, it is up to the command. It should not be the case that the mere fact of putting file contents into a buffer (e.g. via `find-file-noselect'), or even the mere fact of "visiting" a file, should place that file name into `file-name-history'. Any given command can decide (i.e., be designed) to update the history that way, but this should not be something general, i.e., done in a blanket way. In the case of a bookmark that really represents a file location (and they are not all such, but the current case deals only with the default handler and its file-access case, so it is probably OK in this regard), it could be thought that the file name might reasonably be added to `file-name-history'. Why? Because it is very close to the idea of the user inputting the file name. But it is not the same thing as entering the file name explicitly, as minibuffer input. And that alone is what `file-name-history' (and all of the minibuffer histories) are for. It makes sense, if the user enters a bookmark name in the minibuffer, to add that name to a bookmark-name history list. But not to update any other history lists by that action. Again, though, it should be up to the individual command (i.e., its designer, based on its purpose etc.) to decide this. There should be no blanket rule - certainly not maximizing adding file names to the history. The general guideline should be what I said above: Add to the current minibuffer history only when the given name is in fact entered from the minibuffer. But that's a guideline, and any given command could decide otherwise, e.g., could decide that it would be more helpful to users to add some name that was not in fact entered. We could also decide to have a user option that let users choose whether to be lax or strict about respecting the guideline. Then commands could test that option and thus decide whether to add a related file name to the history even when it was not entered. Please do see the bug #12915 thread, for more info. In particular, as one important example, there is the case of commands that are invoked by accessing menus, rather than via `M-x'. IOW, by menu-item name rather than by command name, and by menu rather than by minibuffer. IMO, there should be a user option governing whether those command names get added to `command-history'. (And I have such an option in Icicles, for instance.)