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: Key bindings proposal Date: Mon, 2 Aug 2010 10:59:51 -0700 Message-ID: References: <19534.1494.627000.357123@gargle.gargle.HOWL><19537.40472.267000.563053@gargle.gargle.HOWL><176EDAD3B9E54E39870FA3F84A5DDF3C@us.oracle.com> <19542.56658.583000.394397@gargle.gargle.HOWL> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1280772043 28798 80.91.229.12 (2 Aug 2010 18:00:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Aug 2010 18:00:43 +0000 (UTC) Cc: 'Lennart Borgman' , emacs-devel@gnu.org To: "'Uday S Reddy'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 02 20:00:40 2010 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.69) (envelope-from ) id 1OfzJN-00049T-5g for ged-emacs-devel@m.gmane.org; Mon, 02 Aug 2010 20:00:33 +0200 Original-Received: from localhost ([127.0.0.1]:37405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OfzJK-0003pM-HL for ged-emacs-devel@m.gmane.org; Mon, 02 Aug 2010 14:00:26 -0400 Original-Received: from [140.186.70.92] (port=45247 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OfzJ3-0003me-J0 for emacs-devel@gnu.org; Mon, 02 Aug 2010 14:00:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OfzJ0-0007OW-E5 for emacs-devel@gnu.org; Mon, 02 Aug 2010 14:00:08 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:48938) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OfzJ0-0007O7-4o for emacs-devel@gnu.org; Mon, 02 Aug 2010 14:00:06 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o72HxsGJ006468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Aug 2010 17:59:55 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o72Hxrkn012837; Mon, 2 Aug 2010 17:59:53 GMT Original-Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 458723461280771992; Mon, 02 Aug 2010 10:59:52 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Aug 2010 10:59:51 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsyU1uPTHT85M4RRByp/c+vVIUMLAADAxXw In-Reply-To: <19542.56658.583000.394397@gargle.gargle.HOWL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4C570799.0265:SCFMA4539814, ss=1, pt=DBB_66871, fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:128140 Archived-At: > > Could discovery be even easier? Yes, IMO. Icicles users have the > > equivalent of `apropos' available on the fly every time they use the > > minibuffer for anything. Could the menus be improved? Yes. Could > > menu access from the keyboard be improved? Yes, IMO (though `tmm' > > is OK) - La Carte, especially together with Icicles, gives you > > excellent menu access and menu discovery from the keyboard. > > > > And other improvements are always possible. But Emacs is _better_, > > not worse, than most apps wrt command discovery and access. > > Oh, that self-congratulation again! At least on Windows, you don't > need any special libraries to access the stadard menubar by keyboard. > If you press the Alt-key once, the menubar gets selected. Then you > type keys as follows (in the dired-mode menubar): > > o - goes to Options > o - goes to Operate > RET - selects the Operate menu > i - goes to Isearch Files > RET - selects Isearch Files > > A Windows developer or Java developer that cares about access would > have also associated key strokes with each menu title and menu item. > These appear as underscored characters in the menus. For instance, > one could have chosen `p' in `Operate' as the selected key > stroke. Then typing `p' would have taken you directly to `Operate' > without stopping at `Options'. When there are unique key strokes > associated with the menu items, no RET character is needed for > selection. So, in an accessible Windows application, the above > navigation could have been done with 2 keystrokes instead of the 5 > that Emacs requires. This is something like 10-15 year old > technology. Just open Thunderbird and play with keys to navigate the > menus. You will get the idea. AFAIK, Lennart added support for the MS Windows menu navigation keystrokes (aka menu accelerators) - see his library `menacc.el'. And AFAIK La Carte supports Lennart's addition. I have not tried this feature myself because I am not interested in using it. But AFAIK it is available (though not in vanilla Emacs, and only on Windows). FYI, it was unclear to me that you were talking about this particular kind of keyboard navigation of menus (menu accelerators). You seemed also/instead to be claiming that menu items were not associated with keyboard shortcuts, which is not true for the most part. But those keyboard shortcuts are something different from menu accelerators. > Do you still want to claim that Emacs is better than most apps for > access? Yep. And I said "discovery and access", and most of what I wrote had to do with _discovery_. Why? Because discovery is the strong point of menus, IMHO. And yes, IMO Emacs beats "most apps" in both respects. But I am no expert on all available apps - I could be wrong. ;-) Menu accelerators are one thing. There you might have a point, though I'm not sure how important such a feature is. Perhaps they could be added to Emacs more generally than just for Windows. I'm no help for that. However, I have a feeling (but again, I'm ignorant and unpracticed here) that using menus via accelerators on a regular basis is not the way to go. Menus are about organizing commands. They are helpful for discovery (and rediscovery of infrequently used commands). Regularly using menus (e.g. via accelerators) to access frequently used commands sounds like a bad habit - to me. But again, I do not really know what I'm talking about here. ;-) That sounds like just substituting an alternative set of key bindings, one that reflects the menu structure instead of another key organization. And while menu structure has a certain logic to it (which is why it can be helpful), that logic is not necessarily the best key-binding logic. It is a logic aimed at a particular purpose, IMO: discovery (and rediscovery): finding the needle in the haystack). In any case, when it comes to keyboard access of menus in general (not menu accelerators), Emacs is not lacking. Likewise when it comes to discovery of menu items. As I said, Emacs is OK out of the box (`tmm'), and it shines with a little extra help (e.g. La Carte, Icicles). There is really no reason that an Emacs user, new or old, should not use menus to discover Emacs functionality. And thereby learn keyboard shortcuts (they are indicated in the menus). _That's_ why I introduced menus into the discussion: because you were talking about discovery in Emacs without mentioning menus. > > The complaints here about weird Emacs keybindings are surprising to > > me, coming from you, Uday, who are familiar with Emacs. They sound > > like the superficial comments of a vi'er or someone unfamiliar with > > Emacs - someone who has the impression that one is _required_ to use > > `M-x a C-s' in order to search. It is trivial to use `M-x', trivial > > to use the menu, and trivial to bind a simpler key to something that > > you use often. > > I didn't "complain" about the weird key bindings. I gave the weird > bindings as an example to talk about the over-reliance of Emacs on key > bindings. That statement (claim) is all the talking you did about it, AFAICT. I think you did not give any argument or examples to support the claim of an "over-reliance" on key bindings. You did not even explain what you mean by that. You seemed to suggest that users are _required_ to use the default key sequences (whether seemingly weird ones such as `M-s a C-s' or not), or at least that they are _required_ to use keyboard keys (as opposed to menus or `M-x'). I countered that there is no such over-reliance. But you didn't make clear what you mean by that, so my rebuttal can only guess. If you mean that Emacs forces users to use keyboard key bindings, weird or not, then I disagree. And especially if you mean that Emacs forces users to use particular key bindings (the defaults). > > Try Icicles and La Carte. You can easily sort items on the fly and > > you can easily get to any item, no matter where it is in the menu > > tree. > > Can they match the 3-key stroke access (Alt p i) to "Isearch Files" in > the dired menu? AFAIK, they support Lennart's addition of `&' to menu items to support Windows keyboard navigation of menus. (I have not tested that.) So if Lennart has added menu accelerators for this menu item, and if those accelerators give you a key sequence as short as `Alt p i', then yes. Otherwise no. But that's not why I pointed you to Icicles and La Carte. You asked about _sorting_, so I mentioned Icicles, which lets you change sort orders on the fly, including to any sort orders you define yourself (which is simple). And I mentioned _direct access_ to a menu item anywhere in the tree. The entire path to a menu item is matchable, so you can match a deep item directly. And you can use multiple simple match patterns (regexps, substrings, fuzzy match,...) instead of using a single complex pattern. (You can of course also drill down menu by menu, just as you do with your Windows key navigation or with `tmm'. That is simply a special case of prefix matching.) I do not mention direct access to a menu item in order to promote the use of menus on a regular basis, as a substitute for the usual key bindings. I mention it in the context of discoverability. You can _very_ easily discover what menu items there are that involve searching files (or any other functionality) - regardless of what the menu organization might be. Just type `ear S-SPC file' to see all menu items that contain both `ear' (for "search") and `file', in either order. You can even filter to find all menu items that do _not_ match some pattern, or that match this but not that, where "this" and "that" are as complex as you like. And you can check the doc strings for any of the matching menu items - on the fly. If you cycle among some or all of them, the first line of the doc string is shown in the mode line of *Completions*. And you can see (in *Help*) the entire doc string for any of them (cycling or picking one or more directly). I emphasize discovery because to me that is where menus come into their own. If you want to use menus on a regular basis to access everything, then menu accelerators might be interesting to you. To me, menus are interesting because they _organize_ commands. And that organization can help you (a) find something and (b) learn what commands are available and (c) what keys they are bound to. I would not recommend that organization as the best keyboard access - e.g. menu accelerators, but I don't speak from practice here. > > > On second thought, perhaps the menus are not as disorganized as I > > > had imagined. I haven't yet begun to use them seriously. > > > > Please do. You will thank yourself. And you will no doubt file > > menu bugs or enhancement requests or provide patches for > > improvements. Welcome. > > I will be quite happy to use menus if the menu items have keystrokes > associated with them like on Windows & Java applications. Without > that, they are quite inefficient. > > I will check to see if La Carte and Icicles can help. Whether or not La Carte and Icicles can help you personally is one thing. The point in mentioning them here was, as I said, to show "that Emacs can easily give excellent menu access and provide excellent menu discovery. Out of the box it is OK, and it could easily be made even better."