From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Making `interactive' conditional Date: Sun, 10 Jan 2016 10:36:48 -0200 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> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11407aecf4b21d0528fa1291 X-Trace: ger.gmane.org 1452429426 6688 80.91.229.3 (10 Jan 2016 12:37:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 12:37:06 +0000 (UTC) Cc: emacs-devel To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 10 13:37:05 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 1aIFF3-000175-6N for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 13:37:05 +0100 Original-Received: from localhost ([::1]:46649 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIFF2-0003EK-IV for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 07:37:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIFEu-0003DU-0L for emacs-devel@gnu.org; Sun, 10 Jan 2016 07:37:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIFEn-0007Ik-7l for emacs-devel@gnu.org; Sun, 10 Jan 2016 07:36:55 -0500 Original-Received: from mail-yk0-x22c.google.com ([2607:f8b0:4002:c07::22c]:36033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIFEn-0007Hq-0u for emacs-devel@gnu.org; Sun, 10 Jan 2016 07:36:49 -0500 Original-Received: by mail-yk0-x22c.google.com with SMTP id v14so312925606ykd.3 for ; Sun, 10 Jan 2016 04:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=P2oo3G2DOgZcOXg09AIGNSLq8+lPRoF0awgIm8f2rHE=; b=fPTtDb5EAjz9cZw9fyCxST6AYQ97NCJO0Bf741kOy2maAM0WyMHLjVZ5aP4w+7YWj+ lUhwk+Dd/AQy7/oiH2BkwriH0OKy02JH/xeB6gaUjSDuFbzi/K+n0biLhTc7K8YVpnEW v2dJi6Z3pLCFOTdPIq90yYBV+diLiVGoa5X30aVGouTJvLsnA/h7oRpHxKcA98qQU7yX eKiZ+PwQPsrX75Qskj8wykT9gu/618fwaE0eYOTYvfP9js1t6vP64LK62p58EE6pQK/u 2uiPTJ0u5tA9XiK0gRLICk3ZbhvBxdumFyWT0VbRfMQacZ0DHtubPtFhn3emahQVj+Td DNWQ== X-Received: by 10.129.52.200 with SMTP id b191mr68292363ywa.141.1452429408512; Sun, 10 Jan 2016 04:36:48 -0800 (PST) Original-Received: by 10.129.87.130 with HTTP; Sun, 10 Jan 2016 04:36:48 -0800 (PST) Original-Received: by 10.129.87.130 with HTTP; Sun, 10 Jan 2016 04:36:48 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: fdL43M5vPngLwICWa7gcDOT0b_g X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4002:c07::22c 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:197962 Archived-At: --001a11407aecf4b21d0528fa1291 Content-Type: text/plain; charset=UTF-8 On Jan 10, 2016 7:02 AM, "Lars Magne Ingebrigtsen" wrote: > > John Wiegley writes: > > > > The question is how to declare such conditionality. We can do this rather > > easily by accepting new keyword arguments to `interactive': > > > > (interactive "sDirectory: " [:mode foo-mode] [:when ]) > > That does sound kinda exciting. To take a random example, `M-x > delete-matching-lines' could have a :when of `buffer-writable-p' and not > auto-complete when in a read-only buffer. Etc. I like this too. One minor detail: I think I would invert the second keyword (i.e., use :unless or :error-if, instead of :when). This way the return value of the function could be used as the error message. > > We could alleviate some of that > > by writing code to automatically consider every interactive function *without > > an autoload token* as being conditional on any modes defined in the same > > package (likely determined by prefix matching). > > Hm... I think that sounds a bit too magical to be workable in general. > I may be wrong, but I think that would probably lead to undesirable side > effects I agree with Lars, we shouldn't overdo this with magical guesswork. There are plenty of commands which work outside their major mode. I think that the point of this feature would be to remove from completion (or signal a friendly error) commands that would be guaranteed to error out (probably in some enigmatic way) if invoked outside the expected context. This includes, for instance, the package-menu commands, which will immediately barf if the current buffer doesn't contain a tabulated list of packages. --001a11407aecf4b21d0528fa1291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jan 10, 2016 7:02 AM, "Lars Magne Ingebrigtsen"= <larsi@gnus.org> wrote:
>
> John Wiegley <jwiegley@gmail.= com> writes:
> >
> > The question is how to declare such conditionality. We can do thi= s rather
> > easily by accepting new keyword arguments to `interactive': > >
> >=C2=A0 =C2=A0 =C2=A0(interactive "sDirectory: " [:mode f= oo-mode] [:when <function>])
>
> That does sound kinda exciting.=C2=A0 To take a random example, `M-x > delete-matching-lines' could have a :when of `buffer-writable-p= 9; and not
> auto-complete when in a read-only buffer.=C2=A0 Etc.

I like this too.
One minor detail: I think I would invert the second keyword (i.e., use :unl= ess or :error-if, instead of :when). This way the return value of the funct= ion could be used as the error message.=C2=A0

> > We could alleviate some of that
> > by writing code to automatically consider every interactive funct= ion *without
> > an autoload token* as being conditional on any modes defined in t= he same
> > package (likely determined by prefix matching).
>
> Hm...=C2=A0 I think that sounds a bit too magical to be workable in ge= neral.
> I may be wrong, but I think that would probably lead to undesirable si= de
> effects

I agree with Lars, we shouldn't overdo this with magical= guesswork. There are plenty of commands which work outside their major mod= e. I think that the point of this feature would be to remove from completio= n (or signal a friendly error) commands that would be guaranteed to error o= ut (probably in some enigmatic way) if invoked outside the expected context= .

This includes, for instance, the package-menu commands, whic= h will immediately barf if the current buffer doesn't contain a tabulat= ed list of packages.

--001a11407aecf4b21d0528fa1291--