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 14:43:28 -0800 Message-ID: <95D0D9D79F6C43FC8DA324988AFF23E0@us.oracle.com> References: <87obgug641.fsf@gnu.org> <83ip72s15g.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 1358030704 29140 80.91.229.3 (12 Jan 2013 22:45:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jan 2013 22:45:04 +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 Sat Jan 12 23:45:17 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 1Tu9pE-0003Ec-KJ for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Jan 2013 23:45:16 +0100 Original-Received: from localhost ([::1]:55810 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tu9oy-00049H-GX for geb-bug-gnu-emacs@m.gmane.org; Sat, 12 Jan 2013 17:45:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tu9op-000493-Ch for bug-gnu-emacs@gnu.org; Sat, 12 Jan 2013 17:44:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tu9om-0003UH-H2 for bug-gnu-emacs@gnu.org; Sat, 12 Jan 2013 17:44:51 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tu9om-0003UD-Cp for bug-gnu-emacs@gnu.org; Sat, 12 Jan 2013 17:44:48 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tu9p0-0003hQ-Fo for bug-gnu-emacs@gnu.org; Sat, 12 Jan 2013 17:45: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: Sat, 12 Jan 2013 22:45: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.135803064314133 (code B ref 12915); Sat, 12 Jan 2013 22:45:02 +0000 Original-Received: (at 12915) by debbugs.gnu.org; 12 Jan 2013 22:44:03 +0000 Original-Received: from localhost ([127.0.0.1]:57347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu9o2-0003ft-In for submit@debbugs.gnu.org; Sat, 12 Jan 2013 17:44:03 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:20071) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu9nx-0003fE-W7 for 12915@debbugs.gnu.org; Sat, 12 Jan 2013 17:44:00 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0CMhapA019299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Jan 2013 22:43:37 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0CMhZfX011844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jan 2013 22:43:36 GMT Original-Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0CMhZ9M032156; Sat, 12 Jan 2013 16:43:35 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Jan 2013 14:43:35 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83ip72s15g.fsf@gnu.org> Thread-Index: Ac3w8xX5/9Y5Ne/cR0u0zqoIIp03DQAE+htA 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:69684 Archived-At: > > It's a file-name _input_ history - generalized at most to > > a user-request-for-the-file history. It is not just a > > file-display history. > > You keep saying that, time and again, You're very inventive. Name one other time when I said that. Name two, since you claim "time and again". > but I have yet to see an explanation and specific reasons > why this history should only keep file names typed in the > mini-buffer, See (emacs) Minibuffer History. See (elisp) Minibuffer History. Really, please do take a look at that doc. It describes what minibuffer histories are and what they are for. That is, it describes the design/intention - so far. I am not inventing anything here - except that I too am in favor of generalizing the input history to "a user-request-for-the-file history", allowing for different forms of such request. Turn it around - where do you see that the Emacs doc says that `file-name-history' is for every file that has ever been displayed? Similarly, any other minibuffer history variable. A minibuffer input history is, well, a minibuffer input history. It is a history of your past inputs for a particular command or a particular kind of command (e.g. commands that read file names). That is the design, not just some past implementation limitation. And I was quite clear that it _can_ be useful to extend this to names introduced indirectly by other means - other user interactions, besides simply typing a name in the minibuffer. To back that up, I gave a specific example of my having proposed this, long ago, for commands that a user invokes indirectly (not by name) by using a menu. And that discussion (where the proposal was rejected) dealt also with implementation specifics - it was not just pie in the sky. And I mentioned that I implemented that years ago for Icicles. 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). 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. > nor why might the user object to having file names added to that > history when files are visited via menus or DND or whatever. Users are different. And they might want different behavior for different kinds of names or for different commands. A user does not necessarily want this or that input history polluted by names that s?he never entered as input. A given user might well want input history to include only actual inputs (as now), to keep cycling or searching more succinct or for other reasons. Same reason a user might not want to include the names of commands s?he invokes using a menu. Ask yourself why Emacs Dev rejected that possibility when I proposed it, if you want reasons why a user might consider such inclusion to pollute the actual input history with noise. But a different user might not object at all, and might appreciate this feature. That's why (a) I am not opposed to making such possibilities available to users and (b) I stated that users should be able to control this. BOTH: (a) new possibilities and (b) ability to choose among them. There are many ways to access a file, or invoke a command, or get information about a variable. We should not assume that all users want all such ways to be amalgamated when it comes to augmenting specific "input histories". I hope it is clear to you now that I am not against giving users the opportunity to retrieve names implicated by past interactions besides just minibuffer input. Far from it. As another example of that, in Icicles you can retrieve past text that you have typed in the minibuffer during completion but which you never entered using RET. You do not use the minibuffer history to do that, however - the two histories are kept separate and accessed differently. Having that completion-content history is useful because Icicles lets you do multiple things with different, or even with multiple, completion candidates, based on the current minibuffer text. You might open several files during a file-finding command without ever hitting RET (e.g., hitting C-g to end instead). The point is that yes, it can be useful for users to have additional sets of names that were used in some way in the past (even indirectly/implicitly), making them available for later reuse. I do not disagree with that at all - I have even proposed it. > Without specific and detailed explanations, this is just "he said, she > said" kind of argument, which can never lead to any constructive > discussion. Blah. More of your inventive "You keep saying that, time and again,..." No one said anything like "he said" or "she said" - at all. Except you. And no one said what you claim I said. And I agree with you that that kind of thing is not constructive. So skip it, please. > My use case that might benefit from this is when a file is visited > because some program invoked emacsclient. I find myself in the need > of revisiting the file after I did "C-x #", and then I'm annoyed that > I cannot find it in the history, until it hits me that "oh, yes, it > was visited via emacsclient..." > > Another similar situation is when a file was visited via RET in the > Dired buffer, then the buffer was killed, and then one wants to > revisit the file with "C-x C-f". > > I believe this can be generalized: a file that was visited without > typing its name in the minibuffer, then the buffer was killed, and > then the user wants to revisit the file. And I would not be against any such possibilities. I tried to make that clear. They, and others, can all be useful. User A (you perhaps) might want the name of every file that is ever displayed in any way to be added to the input history. User B might want actually-input file names plus names of files accessed using Dired to be included. User C might want names input to `find-file' etc. and names input to emacsclient to be included. User D might want those plus all file names used in shell commands, even outside Emacs (parsing shell command histories or whatever). User E might want to include all file names present as text in any buffer. The discussion here can focus on file names - that's fine, and an important case. But similar considerations apply generally to any kind of name that can be used in an input history. And especially when it comes to proposals to treat things in an automatic, blanket way, it can help to think about doing the same for other kinds of names. That might help discover whether the proposed handling might not be such a great idea after all. 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'? Some users might like that; some might not - for some it might be helpful; for others it might represent just noise, getting in the way of reusing a real past face choice. There are lots of possibilities. My argument is against an automatic one-size-fits-all approach that takes control away from users and radically changes the meaning and behavior of traditional Emacs minibuffer histories. I am not against extending, under user control, specific input histories in various ways. I would argue though that such ways should involve user interaction - actually _choosing_ the thingie that is named in some way, as opposed to simply all adding the names of all files or all faces that have so far been displayed/accessed/used etc. The same is true for dealing with other sets of names - completion candidates, for instance. Some libraries let users of `C-x b' access also recently accessed files (per recentf), or names cached using filecache, during buffer-name completion. Icicles does that, and IIRC, Ido and Helm offer that also. But some users will want those names included with buffer-name candidates, and some users will not. And some who want them included will want fewer or more such names (different limits). In Icicles there are user options to control such behavior (one for recentf names, one for filecache names). That is the kind of argument I am making here: give users the _possibility_ of including, as part of `file-name-history', file names not actually typed in the minibuffer. But give them also the ability to _choose_ which such names get added, as defined by how the files were chosen for access. Different strokes for different folks. This is a normal thing to consider whenever you are thinking about including additional candidates: whether, what kind, how many. That's all. And let individual users decide.