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, 23 Aug 2010 07:39:50 -0700 Message-ID: <8D701A9E7D444011925CB68BF0883D2B@us.oracle.com> References: <19534.1494.627000.357123@gargle.gargle.HOWL><19537.40472.267000.563053@gargle.gargle.HOWL> <87tymlv41y.fsf@mail.jurta.org> 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 1282575149 28917 80.91.229.12 (23 Aug 2010 14:52:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Aug 2010 14:52:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Juri Linkov'" , "'Uday S Reddy'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 23 16:52:27 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 1OnYNu-0002lF-Bd for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 16:52:26 +0200 Original-Received: from localhost ([127.0.0.1]:60443 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnYNt-0000Mp-J4 for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 10:52:25 -0400 Original-Received: from [140.186.70.92] (port=51905 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnYJT-0006C0-1y for emacs-devel@gnu.org; Mon, 23 Aug 2010 10:47:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnYCA-00038Z-Cu for emacs-devel@gnu.org; Mon, 23 Aug 2010 10:40:19 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:37790) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnYCA-000389-71 for emacs-devel@gnu.org; Mon, 23 Aug 2010 10:40:18 -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 o7NEe5KI011604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Aug 2010 14:40:07 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7N8PAur009261; Mon, 23 Aug 2010 14:40:03 GMT Original-Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 522034131282574401; Mon, 23 Aug 2010 07:40:01 -0700 Original-Received: from dradamslap1 (/10.159.236.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Aug 2010 07:40:00 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87tymlv41y.fsf@mail.jurta.org> Thread-Index: ActCy0vv7o0UywSCQMm6CjPrpo+3bgAAi2GQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 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:129090 Archived-At: > 1. Command names for M-x. An input sequence comprises of characters > of the command name, and completion helps making the input > sequence shorter. This have to be taken into account when > designing a scheme for command names (using an unique command > name prefix, etc.) > > To improve this type of input, we could try adding dwim completions > for M-x. For instance, like the > `calc-execute-extended-command' command > basically does the same as `execute-extended-command' but prefills the > minibuffer's input with the `calc-' prefix: M-x calc- > > Similarly e.g. in Dired, M-x could guess the `dired-' prefix > for Dired commands, so you could just add `isearch' to run > `dired-isearch-filenames'. Please don't. There are lots of 3rd-party extensions to Dired (etc.) whose commands do not start with the prefix `dired-'. Typically, they start with the 3rd-party library prefix. Likewise, for personal user commands that are useful in Dired (etc.). There is no problem getting completion to filter only to a given prefix or substring or whatever, even in vanilla Emacs (e.g. using completion styles). Hard-coding prefix matching for the current mode is truly misguided. > So if we had a separate top-level menu "_S_earch" I've long argued for such a top-level menu. I've used a `Search' menubar menu for decades. There is lots of stuff on other menus that really belongs on `Search', and it's helpful for it to be top level. If people are worried about menu space, then move something like `Options' back under `Help' or `File' (it was originally under `Help'). This is a useful change independently of the reason you gave (use of menu accelerators). > 4. Toolbar (a flat menu with icons). If changes are to be envisioned for the tool bar, they should be along lines already suggested previously: allow for multiple actions, popup menu, etc. per icon (e.g. via modifier keys). The only things particular about a tool bar should be (1) icons, (2) immediate, single action by clicking. Emacs provides a deep, rich user experience with multiple levels of interaction. Emacs tool bars could be made richer and more useful while retaining their simplicity for novice use. There is no reason to limit Emacs tool bars to what are available in some other apps. And even some other apps have tool-bar icons that allow more complex interaction. > All in all, is it a conclusion we are leaning towards: > > 1. All commands should have a name designed for M-x completions. > 2. Most commands should be presented in the main menu. > 3. Few basic commands should be bound to a key sequence. > 4. Some of most frequently used command should be added to the toolbar. That is definitely not a conclusion (4 conclusions) that I am leaning toward. #1: Naming a command can take completion into account to some degree, but that should be only a minor consideration. There are other things important about command names (discoverability, naming patterns for the library, relation to other commands,...). #2: A command should be put on a menu only when it is helpful to provide it with menu access and organization (e.g. discoverability, association with similar commands). It makes no sense to say that "most" commands should or should not be on menus, let alone the "main menu" (whatever that might be). #3 is particularly off the wall. (Though it's unclear what you might mean by "basic commands".) Having a command bound by default does not prevent anyone from rebinding it to a different key. It is true that many commands need not be bound by default, but it is also true that many are not bound by default. There is no problem here that needs to be solved. #4: Some should. Some should not. This is a vacuous conclusion.