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: Ordering of command completions Date: Sun, 7 Dec 2014 13:26:36 -0800 (PST) Message-ID: <05dfd1ec-0530-4c76-8079-1a4d2ed8be80@default> References: <87zjaztimi.fsf@wanadoo.es> <0c854b9e-16a9-4147-8a82-3ad94b6790f0@default> <87r3wbtfn9.fsf@wanadoo.es> <2559f693-8b4b-40c7-b3b4-4b5d932c377c@default> <87mw6ztdhc.fsf@wanadoo.es> <99caf488-cdcb-4897-9a94-393bcbf36326@default> <87iohntbk2.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 1417987630 14679 80.91.229.3 (7 Dec 2014 21:27:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2014 21:27:10 +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 Dec 07 22:27:03 2014 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 1XxjM6-0008Sr-2p for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 22:27:02 +0100 Original-Received: from localhost ([::1]:59219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxjM5-0007mn-JY for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 16:27:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxjLr-0007X7-Np for emacs-devel@gnu.org; Sun, 07 Dec 2014 16:26:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxjLj-00076j-1Z for emacs-devel@gnu.org; Sun, 07 Dec 2014 16:26:47 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:20450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxjLi-00076K-Rz for emacs-devel@gnu.org; Sun, 07 Dec 2014 16:26:38 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB7LQZAX002300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Dec 2014 21:26:36 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB7LQYeJ018848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 7 Dec 2014 21:26:35 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB7LQYWK004978; Sun, 7 Dec 2014 21:26:34 GMT In-Reply-To: <87iohntbk2.fsf@wanadoo.es> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] 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:179309 Archived-At: > > Sounds good to me, I guess. Is there a way for a user to advise > > such a command to change or remove the declaration? Is `declare' > > amenable to advising? >=20 > Dunno. What scenario do you have on mind? A user ... not wanting a particular command to be excluded ... for whatever usery reason. How to override the exclusion? > As a last resort, the user could define a new interactive function, > without associated restrictions, that simply calls the "hidden" one. Sure, people can always rewrite the code we provide. That's not what is generally meant by user control over commands, in Emacs. > Besides, the filtering would be optional, of course. Optionally completely on or completely off is not what I'm getting at, either. We are talking about providing declarations at the individual command level (and possibly at the file/package/mode level). Users should be able to change that behavior for an individual command, just as you can declare it for an individual command. That's what advice is for: tweaking an individual function. Users should not need to redefine commands, if we can give them a better way.