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: Making `interactive' conditional Date: Sun, 10 Jan 2016 10:23:38 -0800 (PST) Message-ID: <2b423be0-9378-44d7-abad-a649fdf1e3c2@default> References: <87mvszdp6b.fsf@gnus.org> <8737u9kv6f.fsf@russet.org.uk> <87fuy7hdc6.fsf_-_@wanadoo.es> <87bn8vh8q4.fsf@wanadoo.es> <4002fc97-5629-4367-8b8f-48b659fefdce@default> <20160110152710.GB3580@acm.fritz.box> <878u3xfkkb.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452450243 20243 80.91.229.3 (10 Jan 2016 18:24:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 18:24:03 +0000 (UTC) To: =?iso-8859-1?B?03NjYXIgRnVlbnRlcw==?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 10 19:23:51 2016 Return-path: Envelope-to: ged-emacs-devel@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 1aIKec-0003TF-Kk for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 19:23:50 +0100 Original-Received: from localhost ([::1]:48489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIKeb-0001N5-Ta for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 13:23:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIKeX-0001Mw-HR for emacs-devel@gnu.org; Sun, 10 Jan 2016 13:23:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIKeU-0003Mr-GN for emacs-devel@gnu.org; Sun, 10 Jan 2016 13:23:45 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIKeT-0003Me-WF for emacs-devel@gnu.org; Sun, 10 Jan 2016 13:23:42 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0AINeiw010581 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 Jan 2016 18:23:41 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u0AINe88024180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 Jan 2016 18:23:40 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0AINeE1001206; Sun, 10 Jan 2016 18:23:40 GMT In-Reply-To: <878u3xfkkb.fsf@wanadoo.es> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197992 Archived-At: > > This might be OK if the only reason you every use M-x is to execute a > > command. But it's not. People (in particular, me) use it to discover > > Emacs, to find the exact name of a command which has only vaguely > > embedded itself in the memory, to get this name into the kill ring to b= e > > yanked into another source file or into documentation, and so on. Try > > M-x sometime, and explore the wealth of Emacs commands. > > :-) >=20 > The current implementation of M-x is, possibly, the worst way of > exploring the wealth of Emacs commands. I disagree strongly. With good ways to match, and especially with the ability to narrow (e.g. what is provided by Icicles and Helm, and possibly other completion contexts), it is far better, not worse, than `apropos-command' - for example. Interactive, incremental, on-demand help of different degrees. It is a fantastic tool for _discovery_ - another Emacs-needs-better theme that has been brought up recently. > M-x is for *executing* commands, > not for learning about them (unless your learning method consists on > executing commands you don't know about). Very wrong. `M-x' is for lots of things. And discovery, even for the limited completion that vanilla Emacs offers, is one of the most important. Don't you ever use `C-h f' or `C-h v' to discover/explore (even for spelling information)? Are you going to go whole-hog on this new idea, and so decide to limit the completion candidates for `C-h f' to only the functions that some Emacs Dev programmer decided are "appropriate" for the current context? I hope not. I would hope that you see the point of showing a user all of the function names that match the current input. > C-h f, the fine manual or, > better, browsing the sources is what I would do (and have done) for > exploring what Emacs has to offer. See above. If it is such a great idea to let Emacs Dev predetermine which commands are appropriate for the current `M-x' context, then why limit this great feature to `M-x'? Surely `C-h f' and `C-h v' and ... can be enhanced the same way? Even thinking that Emacs Dev can specify what constitutes "the current context" for a given user is presumptuous. Not only does it depend on many tangible factors - more than just the current mode(s). It depends also on intangible factors - in particular the user's current aim/intention. Let's not be so presumptuous. Instead, if we provide guesses to try to help, let a user choose our guesses, instead of imposing them. And even more importantly, let users ignore our brilliant guesses and decide for themselves what they consider the "current context" to be. Let _users_ filter, on demand. Provide different, useful ways for them to quickly and powerfully filter candidates out/in, thus shaping the set of candidates (and thus defining the context!), _themselves_. Icicles and Helm have tried to do exactly that, and have succeeded to some extent. Let's move in the direction of giving users _more_ control, and faster and more powerful control - not in the direction of supposing, at code time, that we know what's good for them. > Besides, if you insist on using M-x for learning about new commands, I > suppose that having only those that apply to your current context is > helpful, to say the least. Sure. But WHO decides just what the "current context" means, and when? Is it the currently invoked command that is reading your input that decides? Can the user decide, interactively? Or is it some Emacs maintainer who goes over all of the commands in a wholesale fashion, applying some simplistic rule ahead of time, prior to even distributing Emacs to users? No one has spoken against being able to filter `M-x' candidates to fit the user's current context. [Please read that again, if it's not clear.] The question is how what constitutes the "current context" is determined/decided, and by whom, and when. > > Again, what is this feature for? Is it going to make editing easier fo= r > > experienced users? Is it really going to attract new users, ones who > > would be very happy in Emacs but for the huge number of commands > > presented to them in an M-x? >=20 > How user-friendly is to type M-x and be offered with thousands of > commands that have zero relation to the task you are performing? If that's what you're doing then I submit that maybe you are not using `M-x' as well as you might. (Unless for some reason you want to see those thousands.) [And aside from considering `M-x' for this, I would hope that you would have something more specific than just `M-x' to use, to help you carry out the "task you are performing". If you are using `M-x' only to invoke commands, and you are using only or mainly `M-x' to invoke commands, then something is missing.] You should be able to quickly & easily filter `M-x' candidates by pattern matching. And hopefully you would be able to also filter them with additional conditions/predicates. But YOU should be able to do that, together with the invoked command (`M-x' in this case, which already filters using `commandp') - not just some hard-coded filtering done at code time. _Late binding_ is a user's friend, especially for a user of an interactive, self-documenting, and extensible environment such as Emacs. Lifting such decisions to the earliest possible stage, code time, is going backward. Let's concentrate, instead, on giving users _more_, not less, control over the set of completion candidates. Let's help users filter more powerfully, instead of hard-coding what we think is the right filtering them. Let users decide. > Some of those commands can cause undesirable effects if you > invoke them by accident, Too vague. If so, then fix those particular commands. Make sure that the commands themselves take care of the context in which they are invoked. Let's not try to solve _that_ problem using a one-size-fits-all, abstract, general rule, applied at code time to a huge code base. > I experienced that as a beginner and is very confusing. When that happens, file a bug report so we can fix that command. Such a problem is particular to _that_ command and should be fixed in a way that is appropriat to _it_. > Talking about discoverability and your M-x learning method, if I'm > interested on learning what can I do while editing a C file, how does > help me having to skim over thousands upon thousands of unrelated > commands that only make sense for their respective modes? No one is arguing that you should need to scan thousands of unrelated commands. The question is _how_ to determine which commands _you_ want to see in the _current context_. That question needs to be answered with finesse, not just using a sledge hammer. And the best way to start answering it is to give _you_, the user, great ways to filter interactively. _You_ should decide just how you see the current context, what you see it to be. Emacs should not be second-guessing you about that. There are many users and many use cases for something even as simple as `M-x'. Do not presume to guess what is good for everyone. > Why we hide the menus of the modes that are not active for the current > buffer? Why we have local keymaps? Where were you at the time those > repressing features were imposed on the masses? Modes and buffers and such are useful ways to categorize or define contexts. And there are others. We could do with some more (IMO). (Common Lisp "packages", i.e., namespaces is one.) But looking for ways to precisely specify a context is _opposite_ to what is being proposed here. What is being proposed here is to _interpret_ the absence of a context specification as a particular context, ahead of time. You cannot (should not) assume that the only appropriate user context for `M-x' is the current major mode (or that mode plus the current minor modes). `M-x' is completely general, and it should remain so. Nothing prevents a mode or library from defining a different command that reads command names and invokes one that is chosen by the user, and that imposes a particular interpretation of the current context, i.e., provides only certain command names as candidates. That's exactly what's called for - not breaking the legs off of `M-x' to make it fit some rigid mold.