From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Menu commands to M-x history? Date: Mon, 27 Jul 2009 13:26:59 -0700 Message-ID: References: <7432.1248236149@olgas.newt.com> <7dbe73ed0907221134o1a1fe024k353b1a9a61482041@mail.gmail.com> <9D1E3CE97BF4491E973F872B00D6277D@us.oracle.com> <916D7A0558D14A809114127E47A21BB2@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248726970 17834 80.91.229.12 (27 Jul 2009 20:36:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 20:36:10 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, 'Mathias Dahl' To: "'Lennart Borgman'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 22:36:02 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MVWvR-0005rm-KI for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 22:36:02 +0200 Original-Received: from localhost ([127.0.0.1]:50278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVWvR-0001He-0D for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 16:36:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVWmw-00076O-HQ for emacs-devel@gnu.org; Mon, 27 Jul 2009 16:27:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVWmr-00073O-Q0 for emacs-devel@gnu.org; Mon, 27 Jul 2009 16:27:14 -0400 Original-Received: from [199.232.76.173] (port=51763 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVWmr-00073G-C7 for emacs-devel@gnu.org; Mon, 27 Jul 2009 16:27:09 -0400 Original-Received: from acsinet11.oracle.com ([141.146.126.233]:29338) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MVWmo-0002b1-5u; Mon, 27 Jul 2009 16:27:06 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6RKRJlK032218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jul 2009 20:27:20 GMT Original-Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6RKQxJK032715; Mon, 27 Jul 2009 20:27:00 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 27 Jul 2009 13:26:58 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcoO78Ia8dyfgObIQuuTQRzx9uHKkgABdpRA X-Source-IP: abhmt001.oracle.com [141.146.116.10] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.4A6E0D93.00D9:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113251 Archived-At: > You said that this history is for just M-x history commands. That > semantic is really a programmers semantic. The argument we want to use > for the user interface is rather if it is useful for users to do a > certain thing. Well, that's exactly the question we're discussing: 1. Whether it is useful to include commands invoked using the menu in M-x's history. 2. If so, whether to do that by default or only on demand. You and I say it can be useful (1); some others have seemed to say no. You say this should be the default behavior (2); I say no. Neither of us is arguing from the point of view of implementers. All arguments so far have been in terms of usefulness to users. We just disagree. > >> Don't mix the programmer semantics with the user semantics unless > >> there is a good reason to do so. Very often there is, but not in a > >> case like this. > > > > What does that mean? How did I mix them? Or what non-mixing > > do you have in mind? IOW, what is it that you are really trying to say? > > Really nothing more than that the argument the M-x history is for "M-x > executed commands" is useless. It focuses more on the programming side > than on the user. I don't see why. As a user, I want to see, by default, the commands I have already entered as input to M-x. This has nothing, for me, to do with "the programming side". It would be easy enough for me to always use the larger list, `icicle-interactive-history', which includes menu item, in the Icicles implementation of `M-x'. I choose not to do so for the benefit of users. There is no difficulty in substituting a different history variable, so your "programming side" argument is without basis. > >> > That's important for users. > >> Why is it important for users? > > See what was said previously. Noise reduction. > > If we want to put menu commands in M-x history then it is not noise. Again, it just means more stuff for users to search through. And in the Icicles case, I include not only menu items but all commands invoked using `call-interactively' (which means even more such noise). > > Pertinence of history entries to the task at hand. > > I can't see why that should exclude menu commands from M-x history. Do > you do something very special when you use the menus that you do not > do when you use M-x? I don't have an answer that will satisfy you, I guess. I think we can agree to disagree. > > You know, we _could_ always use just `minibuffer-history', > > and have no such specificity. But that is less useful to users. > > And why do you say this? ... ;-) Why would no specificity at all be less useful? Seems obvious. Although the `commandp' predicate for `M-x' would filter out non-commands as completion candidates, accessing non-commands from the history via `M-p' etc. would mean plowing through irrelevant noise. If you consider all of the possible types of completion candiates (colors, buffers, files, commands, variables, ...), I should think the interest in having separate, domain-specific history lists would be obvious. > >> > It is why commands executed using key bindings are also not > >> > included in the history list. > >> > >> That is a totally diffirent story since it is a different > >> context as I said before. You really do not need any of the > >> commands you execute with a key binding in the M-x history. > > > > I think you do. But only on demand. > > I am surprised. It seems like a very minor case. Well, in Icicles, you can do multiple things with multiple completion candidates. Just as you can build a keyboard macro using both keystrokes and M-x invocations, so a combination can sometimes be useful in Icicles. At least, that's the idea. But I suppose that three tiers could be useful: 1. M-x commands 2. #1 + commands invoked via menu 3. #2 + the other commands invoked via `call-interactively' Currently, I have only two tiers: #1 and #3 (including #2). > >> Because it is intended to be helpful to newbies, Not to > >> experienced Emacs users. > > > > I intend it to be helpful to both. If a newbie can learn > > `C-h k', then s?he can learn a key to complete commands previously > > invoked from the menu. > > Nothing wrong with that of course. I just mean that there is not so > very much to care about for old time users if commands invoked from > the menus are put in the M-x history. You mean that adding those commands won't bother old-timers? Dunno. > > We agree that being able to access menu items via history > > can be helpful. We disagree whether such access should be by > > default or on demand. > > Yes.