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: Sun, 13 Jan 2013 10:55:05 -0800 Message-ID: <8AAC568AC91D477F96BE4F920616C3BA@us.oracle.com> References: <87obgug641.fsf@gnu.org> <83ip72s15g.fsf@gnu.org> <95D0D9D79F6C43FC8DA324988AFF23E0@us.oracle.com> <838v7xrnux.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 1358103354 18453 80.91.229.3 (13 Jan 2013 18:55:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Jan 2013 18:55:54 +0000 (UTC) Cc: cyd@gnu.org, 12915@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 13 19:56:11 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 1TuSj0-0007bv-Lp for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jan 2013 19:56:06 +0100 Original-Received: from localhost ([::1]:50522 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuSik-0005do-I1 for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jan 2013 13:55:50 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuSif-0005dh-PW for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 13:55:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TuSie-0003IF-4d for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 13:55:45 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuSie-0003IA-12 for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 13:55:44 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TuSiw-0007Zd-6K for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 13:56:02 -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: Sun, 13 Jan 2013 18:56:02 +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.135810334829089 (code B ref 12915); Sun, 13 Jan 2013 18:56:02 +0000 Original-Received: (at 12915) by debbugs.gnu.org; 13 Jan 2013 18:55:48 +0000 Original-Received: from localhost ([127.0.0.1]:58521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuSif-0007Z2-Bf for submit@debbugs.gnu.org; Sun, 13 Jan 2013 13:55:46 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51425) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuSib-0007Yo-UO for 12915@debbugs.gnu.org; Sun, 13 Jan 2013 13:55:43 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0DItFIi018590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Jan 2013 18:55:16 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0DItEXp002300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Jan 2013 18:55:14 GMT Original-Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0DItDZK010452; Sun, 13 Jan 2013 12:55:13 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Jan 2013 10:55:13 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <838v7xrnux.fsf@gnu.org> Thread-Index: Ac3xs8f4S7f+rxadQb6UbzHfd/V7/AAAGbyw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:69723 Archived-At: > > So it should be clear to anyone who actually reads what I > > wrote that I am _not against_ the idea of extending input > > histories beyond minibuffer reading to other ways of > > invoking the same behavior (in this case, accessing files). > > You could have fooled me. Apparently. As I said, it should be clear to anyone who actually reads what I wrote. Can't say it any clearer: I am all in favor of letting users choose to automatically add to an "input" history when they choose things (including file names) in ways other than just by typing the name at a minibuffer prompt. I am in favor of letting users _choose_ to do that, and choose specifically whether to do it for different kinds of things (e.g., file names, as one kind) and for different ways of choosing things (e.g., menu access, as one way). > > But I also made it clear that it is important for users to > > be able to control whether and where and how much this is > > done. I argued against an automatic handling of all displayed > > files by simply adding their names to `file-name-history' > > willy nilly. > > What is fundamentally different between typing a file name > at "C-x C-f" prompt, and selecting a file name via the file > selection dialog after clicking "File->Visit New File" on the > menu bar? Why would the former end up in the history, but > not the latter? Why indeed? User preference - that's the difference that counts. (For some definition of "fundamentally different" there are no fundamental differences. For any difference pointed to, you can reply that it is not "fundamental".) Certainly there is a difference between the two interactions you mention. And users can differ in whether they prefer that both interactions augment the history. Until now, Emacs Dev has preferred that only one of them do that. Emacs Dev specifically _rejected_ the proposal to treat both menu access and minibuffer-input access the same wrt input history. Why? Ask yourself what the "fundamental difference" was behind that rejection. Certainly some difference was comprehended, and it must have seemed "fundamental" enough to Emacs Dev. Well, that difference can obviously be important to some users - it has been important enough that Emacs Dev decided, for _all_ users, against treating the two the same. Certainly Emacs Dev must have been right wrt at least some users. > > Would you argue, for instance, that every face that has > > ever been shown in the current session must be automatically > > added to `face-name-history'? > > No one suggested such absurdity. Precisely. > I could turn the table and ask you whether it would make sense to let > users customize insertion into history by file-name wildcards. After > all, some user, somewhere, may wish to insert *.cpp files, but not > *.cxx, right? That way lies madness. No one suggested such absurdity. But you are welcome to. (In Icicles you can in fact retrieve a previously used completion pattern, but it is on a different history list, as mentioned previously.) > User options should serve specific workflows or use cases that make > sense. So far, I've given my use cases, but haven't heard any others > that contradict my experience. It would be nice to hear such > real-life experiences, for a change. That would make this discussion > a whole lot more productive. You've already heard from a couple people (not me) who mentioned that blanket inclusion would pollute their histories with too much noise, and who cited a previous thread for reference. Their message was thanks, but no thanks. The point is that users are different. User A (a la Emacs Dev) does not want menu access, but only `M-x' access, to contribute to the input history. User B wants them both to contribute. User C wants also command-line args from Emacs startup and emacsclient file args to contribute. User D wants also file names used as shell-command args to contribute, but only from shell use inside Emacs. User E wants Emacs to try also to get file-name args from shell commands used outside Emacs, and add those too. User F wants to include files opened from *grep*, but not from Dired. User G wants files opened from Dired, but only when opened singly (not all marked etc.). User H wants even the names of files copied using Dired (`C'). User I wants those, as well as the names of Dired subdirs inserted (`i') and `C-x C-d' targets, both dirs and file names matching wildcard patterns. User J wants the names of files acted on in Dired using `A', `Q', `B', `S', `P', and `Z'. User K... I already agreed that each of the possibilities you listed in _your_ use case can be useful: "They, and others, can all be useful." Good suggestion of some possibilities to consider. Just let users decide which, if any, of them they want for their own use. That's all. Why should Emacs hard-wire Eli's choice of user interactions as the only one to define when names are to be included? It should be easy enough to come up with a list of possible file-choosing interactions - like you did, and then present the user with an option that allows a choice of which interactions should augment `file-name-history'. (Similarly, for other histories, and perhaps another, short list covering all histories.) The list for file-name preferences could be fixed by Emacs Dev. (Or it could perhaps even be extendable, if we devise a means to map interaction names to controlling code. To be clear, I have no such code in my pocket now.) If you like, Eli's Preferred Interactions could even serve for the default value of the option controlling file-name inclusion: * minibuffer input * menu access * emacsclient file-name arg * RET in Dired (mouse too? `e', `f', `o', `C-o', `a', `F' too?) * files previously visited in the same session but since killed Did I get your preferred list right? Sounds like a good start, to me. Turn those all on for the default behavior, if you like. But should Dired perhaps have its own option governing file interactions (see above for possibilities)? That might make sense too. Likewise, some other modes (e.g. grep/compilation mode). My point is only to give individual users the choice.