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#12915: 24.2.50; Visiting a file via drag-and-drop should add it to the history ofvisited files Date: Sat, 12 Jan 2013 09:59:37 -0800 Message-ID: <0D133CE87DCE4BA396A4720CB7CE4A98@us.oracle.com> References: <87obgug641.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1358013665 20856 80.91.229.3 (12 Jan 2013 18:01:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jan 2013 18:01:05 +0000 (UTC) Cc: 12915@debbugs.gnu.org To: "'Chong Yidong'" , "'Dani Moncayo'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 12 19:01:21 2013 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 1Tu5ON-0007nw-Kj for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Jan 2013 19:01:15 +0100 Original-Received: from localhost ([::1]:50537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tu5O7-0003Ff-N5 for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Jan 2013 13:00:59 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tu5O4-0003FM-2y for bug-gnu-emacs@gnu.org; Sat, 12 Jan 2013 13:00:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tu5Nw-0006pQ-JV for bug-gnu-emacs@gnu.org; Sat, 12 Jan 2013 13:00:55 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tu5Nw-0006pM-Fl for bug-gnu-emacs@gnu.org; Sat, 12 Jan 2013 13:00:48 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tu5O9-0004cG-N7 for bug-gnu-emacs@gnu.org; Sat, 12 Jan 2013 13:01:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Jan 2013 18:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12915 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12915-submit@debbugs.gnu.org id=B12915.135801360817664 (code B ref 12915); Sat, 12 Jan 2013 18:01:01 +0000 Original-Received: (at 12915) by debbugs.gnu.org; 12 Jan 2013 18:00:08 +0000 Original-Received: from localhost ([127.0.0.1]:57192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu5NH-0004ar-Gq for submit@debbugs.gnu.org; Sat, 12 Jan 2013 13:00:08 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:34423) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu5NF-0004ZZ-FC for 12915@debbugs.gnu.org; Sat, 12 Jan 2013 13:00:06 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0CHxjq9014483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Jan 2013 17:59:46 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0CHxipj004415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jan 2013 17:59:45 GMT Original-Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0CHxi6H002441; Sat, 12 Jan 2013 11:59:44 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Jan 2013 09:59:44 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87obgug641.fsf@gnu.org> Thread-Index: Ac3wnpsGOM8m+Q/aTAG8CPEA7bp4iwARjy7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.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:69674 Archived-At: > >> The history of visited files should contain every visited > >> file, regardless of the way it was visited (command line > >> argument, drag-n-drop, menu item, C-x C-f...) > > > > ... and when the file is visited via bookmarks (e.g. > > `C-x r b foo '). (I've just missed this feature). > > This feature is relatively easy to implement. > > I think it is best done by adding an optional argument > `add-history' to `find-file' (and similar functions like > `find-file-other-frame'), so that Lisp callers can specify to > update `file-name-history' even if the file name was not read > interactively. Any objections? Yes, FWIW, I completely disagree with this - the aim. History variables are about _user input_. For file names, that means interactive use of a file-finding command. They are not just about accessing a file, or using a command, or mentioning a variable, or .... They are INPUT histories. In the past there have been suggestions to add commands associated with menu items that a user accesses interactively to `extended-command-history'. That suggestion was rejected (why?), even with the proviso that it be governed by a user option. This proposed change goes against the intention/meaning of Emacs input histories. The proper solution is for commands that read file names to DTRT wrt `file-name-history' - TRT for that command. If for instance, a bookmark jump command visits a file (it need not) then it could, itself, explicitly add that file's name to `file-name-history'. The command knows what TRT is. And the user knows more than does the command, and should ultimately decide. Normally, changing `file-name-history' would not (_should_ not) be done by a bookmark jump command, unless the file name was provided as user input. That's what these histories are for: _user input_. Past input provides candidates for future input. A bookmarking command that reads a bookmark name puts that bookmark name on `bookmark-history'. A priori, it should not also put the visited file name on `file-name-history'. Not without some user agreement (e.g. via an option specific for this wrt bookmarks). This proposed change is misguided, IMHO. I'm surprised that both Emacs maintainers apparently immediately signed on to it. It is so easy for any command (or any function - but this should be done in the context of a command and its user interaction) to add a name to any history, according to what it deems is TRT. There is no need to do this in some low-level, automatic way. No need - and it's generally the wrong thing to do. Is it hard to solve the specific problem raised by the enhancement request (it is not a bug report): have drag-and-drop add the name of the file to `file-history', without going in the direction you are suggesting? Why is that difficult to address specifically? And since users should be able to control this, how would they do it? The enhancement request also mentions menu-item access and bookmark access. Different users will feel differently about whether those should all be lumped together in this respect. I mentioned the case of menus and commands because it is similar: accessing a command via a menu is a different user action than typing its name into the minibuffer for `M-x'. A priori, it is only actual, historical command-name input that we want to later provide for command-name reading. But a user might later want to repeat that menu-accessed command by name, using the minibuffer. That's why this feature was proposed. (This has been an Icicles user option for years. Some people use it, some do not. It is turned on by default.) But it's also why this kind of thing should be controlled by specific user options (one for menu items, one for file bookmarks, etc.). A user should opt into having other commands, which do not _read_ a name (e.g. file), also add a name to the history. This is no less important for file dragging-&-dropping, or file access by menu, than it is for accessing commands by menu. The important point is that we should not generalize the addition of names (of files or whatever) to histories beyond _user interaction_ or in some automatic way beyond user control. And for any user interaction besides _reading_ the name, users should be able to control (e.g. via an option) whether the name gets added to the input name history. For commands like bookmark jumping, a user should be able to decide whether `file-name-history' should be augmented, in addition to `bookmark-history'. I hope you will think a little more about this.