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 17:47:32 +0100 Message-ID: <878u3xfkkb.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1452444497 32368 80.91.229.3 (10 Jan 2016 16:48:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 16:48:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 10 17:48:09 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 1aIJA0-0002GQ-Fr for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 17:48:08 +0100 Original-Received: from localhost ([::1]:47753 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIJ9z-00074y-OJ for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 11:48:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIJ9l-00074g-EC for emacs-devel@gnu.org; Sun, 10 Jan 2016 11:47:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIJ9i-00049w-76 for emacs-devel@gnu.org; Sun, 10 Jan 2016 11:47:53 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:33212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIJ9i-00049k-0Q for emacs-devel@gnu.org; Sun, 10 Jan 2016 11:47:50 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aIJ9e-00022q-C4 for emacs-devel@gnu.org; Sun, 10 Jan 2016 17:47:46 +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 17:47:46 +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 17:47:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 78 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:MNoVAD8eFYXGDmiX0+kTpbDTUwg= 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:197981 Archived-At: Alan Mackenzie writes: >> OK Yuri, now you've got me excited. Let's not talk about "filtering M-x"; >> let's talk about making `interactive' conditional. The former is a UI concern, >> while the latter I consider a core API issue. > > What you're proposing is exactly "filtering M-x"; censoring it, if you > will; a sort of "not in front of the children" attitude that restricts > what you can see by somebody else's criteria. I think most people on > this list would be opposed to censorship in most areas (for example, > national authorities deciding what part of the WWW is suitable for > browsing). Yet, here we are, talking about introducing the same sort of > thing into Emacs. The amount of drama an hyperbole in emacs-devel never ceases to surpass my expectations. On any other place I would read your commentary as tongue-in-cheek, but not in emacs-devel, I'm afraid... :-) > 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 be > yanked into another source file or into documentation, and so on. Try > M-x sometime, and explore the wealth of Emacs commands. > :-) The current implementation of M-x is, possibly, the worst way of exploring the wealth of Emacs commands. M-x is for *executing* commands, not for learning about them (unless your learning method consists on executing commands you don't know about). 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. 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. [snip] > _ANY_ form of censorship must be optional, and not merely up to the > point where some authority decides it's acceptable to impose on the > masses. To be on the safe side, I propose that we involve the EFF, Amnesty International, Reporters Without Borders and the Council of Europe, among others, as overseers of this process. >> Thus, proper UI behavior for M-x falls out by design, and we get to make use >> of conditionality for other purposes, such as better errors when command >> functions are called outside their expected environment. > > Any chance of an example of such an improvement? How are we to improve > on, for example, "Can't execute - not in Foo mode"? > >> I'm open to a feature branch implementing such conditionality, as a candidate >> for merging to master. As described above, I expect the C code impact to be >> fairly minimal, and the changes to `M-x' to also be minor. The automation >> logic seems like the trickiest part, as it would have to happen whenever a >> feature is loaded. > > Again, what is this feature for? Is it going to make editing easier for > 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? 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? Some of those commands can cause undesirable effects if you invoke them by accident, I experienced that as a beginner and is very confusing. 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? 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?