From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Making `interactive' conditional Date: Sun, 10 Jan 2016 20:31:20 +0100 Message-ID: <874melfczb.fsf@wanadoo.es> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1452454320 16058 80.91.229.3 (10 Jan 2016 19:32:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 19:32:00 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 10 20:31:52 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 1aILiS-0001xb-BZ for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 20:31:52 +0100 Original-Received: from localhost ([::1]:48847 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aILiR-0000KC-Pt for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 14:31:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aILiD-0000Jc-V2 for emacs-devel@gnu.org; Sun, 10 Jan 2016 14:31:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aILi9-00037T-S4 for emacs-devel@gnu.org; Sun, 10 Jan 2016 14:31:37 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:40053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aILi9-00034X-HO for emacs-devel@gnu.org; Sun, 10 Jan 2016 14:31:33 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aILi4-0001jn-2n for emacs-devel@gnu.org; Sun, 10 Jan 2016 20:31:28 +0100 Original-Received: from 33.red-79-156-42.staticip.rima-tde.net ([79.156.42.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jan 2016 20:31:28 +0100 Original-Received: from ofv by 33.red-79-156-42.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jan 2016 20:31:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 172 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 33.red-79-156-42.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:ZTs8qXrcoyHuQJzsUJzH6hdSua4= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:197996 Archived-At: Drew Adams writes: [snip] >> 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. 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. > Don't you ever use `C-h f' or `C-h v' to discover/explore > (even for spelling information)? I'm talking about M-x. `C-h *' is a different thing. > 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? 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. [snip] > Even thinking that Emacs Dev can specify what constitutes > "the current context" for a given user is presumptuous. 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. That's something decided by the developer, right? Overriding checks that throws errors as something beyond the reach of the ordinary user, overriding the M-x filter is one customization change away (in case it was active, to begin with). So I don't understand what you are worried about. > 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. 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? If the user expects to see the command, he can use C-h f to check its docstring and learn about its restrictions. > 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_. 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. > 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. 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. Operating solely on the command names (prefixes that match mode names, etc) are hacks that work on arbitrary premises. >> 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. But what me (and Lars, and most people here, AFAIU) are proposing is, precisely, making possible to filter M-x candidates! 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. > [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. By the developer, of course. The same person who wrote the command and knows how and when it is correct to use it. >> 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.) I'm not interested on seeing thousands of commands, not. I use M-x to find a command on the provided list. If the list contains many commands, it will be more difficult to find your command, no matter how smart is your completion method. The fact that the set of available commands grows with time, as more and more packages are `require'd by your Emacs session, makes things worse. > [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.] 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. > 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. 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. [snip] > 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. 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. Sorry for not commenting on the rest of your message. I'm bit busy now. But this: > 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). 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. [snit]