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 14:40:25 -0800 (PST) Message-ID: 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> <2b423be0-9378-44d7-abad-a649fdf1e3c2@default> <874melfczb.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 1452465655 20269 80.91.229.3 (10 Jan 2016 22:40:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 22:40:55 +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 23:40:43 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 1aIOfB-0005lJ-VE for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 23:40:42 +0100 Original-Received: from localhost ([::1]:49971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIOfB-0000ZM-6x for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 17:40:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIOf5-0000Ys-2W for emacs-devel@gnu.org; Sun, 10 Jan 2016 17:40:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIOez-0005th-Vn for emacs-devel@gnu.org; Sun, 10 Jan 2016 17:40:35 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:27867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIOez-0005tC-MG for emacs-devel@gnu.org; Sun, 10 Jan 2016 17:40:29 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0AMeRqf009684 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 Jan 2016 22:40:28 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u0AMeQ70032398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 Jan 2016 22:40:27 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0AMeQDS009493; Sun, 10 Jan 2016 22:40:26 GMT In-Reply-To: <874melfczb.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: userv0022.oracle.com [156.151.31.74] 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:198004 Archived-At: > >> 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. >=20 > The fact that M-x shows a list of candidates does not make it an > adequate tool for discovering. The fact that it lists *everything*, > regardless of what yo are doing at the moment, less so. >=20 > > Don't you ever use `C-h f' or `C-h v' to discover/explore > > (even for spelling information)? >=20 > I'm talking about M-x. `C-h *' is a different thing. Why is it different, in terms of discovery? Why wouldn't your same arguments ("The fact that it lists *everything*, regardless of what yo are doing at the moment" etc.) apply to `C-h f'? > > 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? >=20 > AFAIK, nobody suggested changing `C-h *', you just introduced that > topic. Please don't do that. It is not a constructive way of > discussing technical matters. Sure it is. Don't your same arguments apply? Why should we stop at `M-x'? Seems to me that the same arguments for and against the proposal apply here as well. Can you point out something different in this regard? > > Even thinking that Emacs Dev can specify what constitutes > > "the current context" for a given user is presumptuous. >=20 > But it is not presumptuous to put code in the command that > checks the context and errors out if it it not the correct one.=20 No, it is not. Users can pick and choose commands and key bindings to use. The _very general_ command `execute-extended-command' (`M-x') has much wider scope. Much greater damage, if your presumption is off the mark. > > 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. >=20 > But you are not opposed to checks in the commands about its > applicability. If a command has a check that errors out on > non-editable buffers, what's wrong with not showing that > command on M-x on that circunstance? I already answered that. (1) The command needs to raise that error anyway - it won't necessarily be invoked by `M-x'. (2) Such a particular command does not have as part of its mission to show users which commands have names matching given input. `M-x' does. And I gave additional reasons. Feel free to read what I've already written. > > 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_. >=20 > Again, you are arguing about something that you made up. As mentioned > several times, it is not decided (not even discussed, except by you) if > the feature will be activated by default. Oh, so the talk about binding this behavior to `M-x' does not apply? I made that up? Great to hear. We can all forget about that then. Let me clear: (1) It should not be activated by default. (2) If Emacs Dev is convinced that this is a great idea then it can create a _new) command that implements it. There is no reason to hijack `execute-extended-command' for this. And there is certainly no reason to hijack `M-x' for it. Provide the new and wonderful behavior in a new command, and let users come to love it on their own and bind it to whatever keys they like. In a decade or two we can decide whether it should become the new norm. Just like other innovations (and some of them have been left by the wayside). Perhaps, as an Ido user, you are desirous for Ido to become the new norm for minibuffer input, and perhaps someday it will. But you'll notice that we didn't just switch the default behavior to it the day it rolled off the press. This new behavior hasn't rolled off the press. It hasn't even been described clearly yet. But we do seem to be talking about changing `execute-extended-command' (`M-x'), AFAICS. (Yes, John asked that this be done in a sandbox, for now. That's one good thing, at least.) > > 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. >=20 > Annotating commands with information about its applicability is > something that gives users more control, because they have more > knowledge and can process it to taylor their needs. I have not objected to associating any such info with commands. I might have something to say about how that is done, but I don't object to our doing so, as long as this is open to users as well: to add, subtract, and modify such associations. > Operating solely on the command names (prefixes that match > mode names, etc) are hacks that work on arbitrary premises. I described a lot more in the way of interactive filtering than filtering by mode name. Please read what I wrote. And beyond the examples I gave or other examples that may already be realized here or there, the possibilities are endless. The point is to let _users_ filter easily, in various ways. > > No one has spoken against being able to filter `M-x' > > candidates to fit the user's current context. >=20 > But what me (and Lars, and most people here, AFAIU) are > proposing is, precisely, making possible to filter M-x candidates! As I understand it, the proposal is not about _users_ filtering the candidates, especially interactively. The proposal is for, in effect, a code-time filtering by Emacs Dev. There's a world of difference between the two. And again, I'm not against Emacs Dev coming up with its best behavior in this regard, and then _letting users choose_ to experiment with the resulting _new_ command. But I am not in favor of it hijacking `M-x' for this new (and so far vaguely specified) pie in the sky. > The recent proposal about using this feature in place of tests that > error out when the context is not the expected one, is a new > development. I'm not much convinced about that, btw. As I stated: 1. You cannot, in any case, do without the error-raising code in the command bodies (and it was argued that you would be able to, as if that would be a great savings). Commands can be invoked in various ways, and such errors need to be raised. 2. It is not always an improvement to prevent a user from raising an error. It can be helpful for a user to see an error message. When a given command is _not_ present as a completion candidate you have no way of knowing why (or even whether the command exists). [FWIW, I argued something similar against the sequential fall-through behavior of `completion-styles', with no user feedback as to which completion styles failed and which style ultimately succeeded. Learning that something does _not_ work can be helpful.] > > The question is how what constitutes the "current context" is > > determined/decided, and by whom, and when. >=20 > By the developer, of course. The same person who wrote the command and > knows how and when it is correct to use it. User first, command-developer second, Emacs Dev last. No one has objected to the developer of a command defining it so that it reads input with completion and so that the completion candidates are limited to whatever the developer thinks is appropriate. Developers already do that, using a predicate with `completing-read' or `read-file-name'. But why should a developer of command `foo' decide whether a user can see the command _name_ `foo' as an `M-x' candidate? Let the user decide what command names to show - just as s?he does using pattern-matching. > As I mentioned on other messages, M-x with the correct UI is often more > convenient than keybindings and menus on usability terms (ergonomics, > discoverability, mnemonics). On that aspect, M-x is severely handicapped > by the presence of a growing large number of irrelevant candidates. That seems to be what is behind your use case, indeed. If you use only `M-x' to invoke commands then yes, I can see why you might regard it as too blunt a hammer. Most users use additional key bindings to invoke commands, not just `M-x'. You can use `M-x' for nearly everything, if you are so inclined (but you still need at least some keys bound to a command such as `self-insert-command', even just to enter input for `M-x'.) [You could be even more ascetic, and limit yourself to only Icicles key completion - only key `S-TAB'. That lets you invoke any command, including character-insertion. http://www.emacswiki.org/emacs/Icicles_-_Key_Completion#ThreeKeyEmacs] But why would you, when you can make use of multiple keys? Your answer is that, in your setup, `M-x' lets you abbreviate command names radically, and using abbreviated command names is handier than using multiple keys. That's to be counted as one user's interesting preference, but it is hardly a common one. > > 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. >=20 > Precisely, I use ido+flx for that, and it works great up to > some extent (see above). But ido (and helm, and Icicles, I > guess) work on command names, which is quite limiting. > A hack, really. I can't speak for Helm, but I've already said that Icicles does _not_ limit you to pattern-matching (for command names or anything else). You can filter, on the fly, using arbitrary predicates. But the point is not what is available today but where Emacs could head. Instead of what is currently being proposed, I'd sooner see making it easy for _users_ to be able to filter powerfully and flexibly. And no, I'm not talking only about matching candidate names. > > 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. >=20 > You are misunderstanding the whole issue. Annotating the commands gives > more information, hence more power, to the users. It is up to them to > how to use that information. Emacs will provide the necessary > infrastructure to filter commands on that annotations, but that's all. I'll be glad to find that I have misunderstood, but so far I don't think so. If the only change is to "annotate" existing functions (and why stop with just commands?) with additional information about contexts where Emacs Dev thinks their invocation might be especially useful, I have nothing against that. But note the qualifiers: "might be especially useful". This can only be a code-time developer guess, at best. That's a far cry from making `M-x' obey such annotations, treating them as restrictions: hard, predefined filtering. And I do think I understand the current proposal when I think that it is about predefined `M-x' filtering, and not just annotating functions with suggestive context info. > > 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). >=20 > Again, nobody said or implied what you say above. You are making that > up. Please try to understand what we are discussing here before wasting > your energies fighting something that does not exist. Same for the rest > of your message starting on that paragraph. We disagree. It seems pretty clear to me that the proposal is about `M-x' filtering, not just about annotating functions with suggested context information. But it also seems clear that the proposal is, so far, quite vague. Just what kind of annotation and how it will be specified (associated with commands), and what kind of `M-x' filtering and how it will (or won't) be controlled by users - such things have not been specified clearly, if at all.