From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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 19:31:34 +0200 Message-ID: <838v7xrnux.fsf@gnu.org> References: <87obgug641.fsf@gnu.org> <83ip72s15g.fsf@gnu.org> <95D0D9D79F6C43FC8DA324988AFF23E0@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1358098323 6491 80.91.229.3 (13 Jan 2013 17:32:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Jan 2013 17:32:03 +0000 (UTC) Cc: cyd@gnu.org, 12915@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 13 18:32:19 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 1TuRPs-0001sH-JS for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jan 2013 18:32:16 +0100 Original-Received: from localhost ([::1]:34198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuRPc-0006EK-G7 for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jan 2013 12:32:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuRPT-0006D2-LJ for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 12:31:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TuRPM-00059X-15 for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 12:31:51 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TuRPL-00059P-Tk for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 12:31:43 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TuRPe-0005cH-3B for bug-gnu-emacs@gnu.org; Sun, 13 Jan 2013 12:32:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jan 2013 17:32: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.135809829921559 (code B ref 12915); Sun, 13 Jan 2013 17:32:02 +0000 Original-Received: (at 12915) by debbugs.gnu.org; 13 Jan 2013 17:31:39 +0000 Original-Received: from localhost ([127.0.0.1]:58419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuRPF-0005bb-QG for submit@debbugs.gnu.org; Sun, 13 Jan 2013 12:31:38 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:44101) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuRPB-0005bM-Up for 12915@debbugs.gnu.org; Sun, 13 Jan 2013 12:31:35 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MGK00H00RAGDK00@a-mtaout20.012.net.il> for 12915@debbugs.gnu.org; Sun, 13 Jan 2013 19:31:07 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGK00GLZRBVWVB0@a-mtaout20.012.net.il>; Sun, 13 Jan 2013 19:31:07 +0200 (IST) In-reply-to: <95D0D9D79F6C43FC8DA324988AFF23E0@us.oracle.com> X-012-Sender: halo1@inter.net.il 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:69721 Archived-At: > From: "Drew Adams" > Cc: , , <12915@debbugs.gnu.org> > Date: Sat, 12 Jan 2013 14:43:28 -0800 > > > > 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. Not at all. Drew in http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-01/msg00408.html: > 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. Drew in http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-01/msg00409.html: > 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. Drew in http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-01/msg00412.html: > File-name input is not about a change in the list of buffers or the displayed > files. It is about files that the user has interactively requested to access. > In particular, requested by entering the file name. As you see, I didn't invent anything. > Name one other time when I said that. > Name two, since you claim "time and again". I named 3 above. I meant in this thread. > > 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. The docs are not a catechism. We wrote it, and we can change it if we decide to do so. I asked for _your_ take of this, I'd like to see your use cases when adding to file-name history names of files that were not typed in the minibuffer would be the wrong thing. > 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? Emacs docs are not requirements. They are descriptions of a certain state of the package behavior. When the behavior changes, we update the docs. We never treat the docs as requirements that we need to fulfill. > 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. > 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? > A user does not necessarily want this or that input history polluted by names > that s?he never entered as input. We _are_ talking about selecting files by their names. The name doesn't have to be typed in its entirety. E.g., typing "foo TAB" into the minibuffer, then clicking on "foobar" in *Completions* does end up in the history, although the user only typed "foo". Where do you draw the line? How do you explain the difference to users, without going into the internals, which users don't care about? > 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. 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. > 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. 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.