Re: scratch/command 064f146 1/2: Change command to interactive ... modes

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Dmitry Gutov]

On 13.02.2021 16:12, Lars Ingebrigtsen wrote:
> +@defspec interactive &optional arg-descriptor &rest modes

If we make it use (declare ...) instead, the feature could be made 
backward-compatible, and, for example, third-party code could take 
advantage of it to have Emacs 28 use these predicates, without breaking 
the code in Emacs 27 and earlier.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.02.2021 16:12, Lars Ingebrigtsen wrote:
>> +@defspec interactive &optional arg-descriptor &rest modes
>
> If we make it use (declare ...) instead, the feature could be made
> backward-compatible, and, for example, third-party code could take
> advantage of it to have Emacs 28 use these predicates, without
> breaking the code in Emacs 27 and earlier.

Backwards compatibility is certainly nice, but I don't think it's a
priority when doing Emacs Lisp language design. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Dmitry Gutov]

On 13.02.2021 23:05, Lars Ingebrigtsen wrote:
> Backwards compatibility is certainly nice, but I don't think it's a
> priority when doing Emacs Lisp language design.

*shrug* I don't see a lot of downsides to doing it the backward 
compatible way here, and some forward-looking package maintainers could 
help promote the new feature.

If it's not backward-compatible at all, however, I wouldn't feel 
comfortable with using it in my packages for years to come.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> If it's not backward-compatible at all, however, I wouldn't feel
> comfortable with using it in my packages for years to come.

Could we write a macro `future-interactive' that will expand to the
correct thing depending on the version of Emacs?  We could put something
like that in GNU ELPA.  (I'm not sure the order in which things are
expanded, so this might not work.)

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> On 13.02.2021 16:12, Lars Ingebrigtsen wrote:
>>> +@defspec interactive &optional arg-descriptor &rest modes
>>
>> If we make it use (declare ...) instead, the feature could be made
>> backward-compatible, and, for example, third-party code could take
>> advantage of it to have Emacs 28 use these predicates, without
>> breaking the code in Emacs 27 and earlier.
>
> Backwards compatibility is certainly nice, but I don't think it's a
> priority when doing Emacs Lisp language design. 

I'm not sure if I understand this correctly, but in any case I'll
mention that a change that requires a source construct incompatible with
previous Emacs versions will have very limited adoption, not only among
external packages, but among Emacs packages that are maintained
externally (Org, C-Mode).

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> If it's not backward-compatible at all, however, I wouldn't feel
>> comfortable with using it in my packages for years to come.
>
> Could we write a macro `future-interactive' that will expand to the
> correct thing depending on the version of Emacs?  We could put something
> like that in GNU ELPA.  (I'm not sure the order in which things are
> expanded, so this might not work.)

This seems to work as expected on both master and Emacs 27:

(defmacro future-interactive (arg-descriptor &rest modes)
  (if (< emacs-major-version 28)
      `(interactive ,arg-descriptor)
    `(interactive ,arg-descriptor ,@(mapcar #'eval modes))))

(defun foo (arg)
  (future-interactive "P" 'fundamental-mode)
  (message "P was %s" arg))

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> This seems to work as expected on both master and Emacs 27:
>
> (defmacro future-interactive (arg-descriptor &rest modes)
>   (if (< emacs-major-version 28)
>       `(interactive ,arg-descriptor)
>     `(interactive ,arg-descriptor ,@(mapcar #'eval modes))))
>
> (defun foo (arg)
>   (future-interactive "P" 'fundamental-mode)
>   (message "P was %s" arg))

Cool!  Does it survive byte compilation, too?  Hm...  I guess so,
because macros should be expanded by that time, I guess?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I'm not sure if I understand this correctly, but in any case I'll
> mention that a change that requires a source construct incompatible with
> previous Emacs versions will have very limited adoption, not only among
> external packages, but among Emacs packages that are maintained
> externally (Org, C-Mode).

Of course.  But that's the case with any new thing that Emacs
introduces, from lexical binding to new functions, macros and special
forms.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> This seems to work as expected on both master and Emacs 27:
>>
>> (defmacro future-interactive (arg-descriptor &rest modes)
>>   (if (< emacs-major-version 28)
>>       `(interactive ,arg-descriptor)
>>     `(interactive ,arg-descriptor ,@(mapcar #'eval modes))))
>>
>> (defun foo (arg)
>>   (future-interactive "P" 'fundamental-mode)
>>   (message "P was %s" arg))
>
> Cool!  Does it survive byte compilation, too?  Hm...  I guess so,
> because macros should be expanded by that time, I guess?

It seems to survive, yes.

Byte-code on Emacs 27:

(defalias 'foo #[(arg) "\301\302^H\"\207" [arg message "P was %s"] 3 nil "P"])

Byte-code on master:

(defalias 'foo #[(arg) "\301\302^H\"\207" [arg message "P was %s"] 3
nil ["P" (fundamental-mode)]])

So I could pack it up as a new GNU ELPA package `future-interactive',
and anyone who wants to use it, can.  Or should it be a core package
perhaps?

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> It seems to survive, yes.
>
> Byte-code on Emacs 27:
>
> (defalias 'foo #[(arg) "\301\302^H\"\207" [arg message "P was %s"] 3 nil "P"])
>
> Byte-code on master:
>
> (defalias 'foo #[(arg) "\301\302^H\"\207" [arg message "P was %s"] 3
> nil ["P" (fundamental-mode)]])

Great!

> So I could pack it up as a new GNU ELPA package `future-interactive',
> and anyone who wants to use it, can.  Or should it be a core package
> perhaps?

Hm...  perhaps a core package would be the best solution here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> I'm not sure if I understand this correctly, but in any case I'll
>> mention that a change that requires a source construct incompatible with
>> previous Emacs versions will have very limited adoption, not only among
>> external packages, but among Emacs packages that are maintained
>> externally (Org, C-Mode).
>
> Of course.  But that's the case with any new thing that Emacs
> introduces, from lexical binding to new functions, macros and special
> forms.

The language features that you mention have a "local" applicability.
That means that you can take advantage of them without depending of what
others do. This is not the case with M-x filtering. For it to be really
useful a wide adoption is necessary, or else the effective description
of the feature for several year would be "filters out *some* unrelated
commands".

But if I got your description right, the `declare' construct is
backwards source-code compatible, right? This would lessen my worries to
a great extent.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> So I could pack it up as a new GNU ELPA package `future-interactive',
>> and anyone who wants to use it, can.  Or should it be a core package
>> perhaps?
>
> Hm...  perhaps a core package would be the best solution here?

I don't think we currently have any other way to make it easy to use on
master, do we?

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Basil L. Contovounesios]

Stefan Kangas <stefankangas@gmail.com> writes:

> This seems to work as expected on both master and Emacs 27:
>
> (defmacro future-interactive (arg-descriptor &rest modes)
>   (if (< emacs-major-version 28)
>       `(interactive ,arg-descriptor)
>     `(interactive ,arg-descriptor ,@(mapcar #'eval modes))))

Why is the eval necessary?

> (defun foo (arg)
>   (future-interactive "P" 'fundamental-mode)
>   (message "P was %s" arg))

I thought (declare (modes ...)) was the intended way of achieving this
in packages that need to support older Emacsen too.

Thanks,

-- 
Basil

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Alan Mackenzie]

On Sun, Feb 14, 2021 at 10:03:57 -0600, Stefan Kangas wrote:
> Stefan Kangas <stefankangas@gmail.com> writes:

> > Dmitry Gutov <dgutov@yandex.ru> writes:

> >> If it's not backward-compatible at all, however, I wouldn't feel
> >> comfortable with using it in my packages for years to come.

> > Could we write a macro `future-interactive' that will expand to the
> > correct thing depending on the version of Emacs?  We could put something
> > like that in GNU ELPA.  (I'm not sure the order in which things are
> > expanded, so this might not work.)

> This seems to work as expected on both master and Emacs 27:

> (defmacro future-interactive (arg-descriptor &rest modes)
>   (if (< emacs-major-version 28)
>       `(interactive ,arg-descriptor)
>     `(interactive ,arg-descriptor ,@(mapcar #'eval modes))))

It won't work in Emacsen before Emacs 28, because it doesn't exist on
those systems.  This idea would mean having to distribute the macro with
every package, with all the evils that would entail.

> (defun foo (arg)
>   (future-interactive "P" 'fundamental-mode)
>   (message "P was %s" arg))

Please, can't we just halt all this and take stock?  `interactive'
specifies how to call a lisp function interactively.  This new stuff
being put it has nothing to do with the interactive call.  It will foul
things up horribly.

Why can't this new feature be implemented without introducing
incompatibilities?

What am I missing?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> But if I got your description right, the `declare' construct is
> backwards source-code compatible, right? This would lessen my worries to
> a great extent.

Yes, the `declare' form should have no effect in previous Emacs versions
(Emacs helpfully just ignores `declare' things that it doesn't know
about.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> This seems to work as expected on both master and Emacs 27:
>>
>> (defmacro future-interactive (arg-descriptor &rest modes)
>>   (if (< emacs-major-version 28)
>>       `(interactive ,arg-descriptor)
>>     `(interactive ,arg-descriptor ,@(mapcar #'eval modes))))
>
> Why is the eval necessary?

Because the correct interactive form is:

    (interactive ... foo-mode)

Rather than:

    (interactive ... 'foo-mode)

>> (defun foo (arg)
>>   (future-interactive "P" 'fundamental-mode)
>>   (message "P was %s" arg))
>
> I thought (declare (modes ...)) was the intended way of achieving this
> in packages that need to support older Emacsen too.

Hmm, I suppose that could work.  I have no strong opinion, but it might
be a bit messier than the macro.  OTOH, you don't need the macro for
that.  Maybe we could support both?

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> It won't work in Emacsen before Emacs 28, because it doesn't exist on
> those systems.  This idea would mean having to distribute the macro with
> every package, with all the evils that would entail.

That's why I proposed to make it into a GNU ELPA or core package.
Then it's just another dependency for a while.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Hm...  perhaps a core package would be the best solution here?
>
> I don't think we currently have any other way to make it easy to use on
> master, do we?

Hm...  I guess not.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Basil L. Contovounesios]

Stefan Kangas <stefankangas@gmail.com> writes:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>>> (defmacro future-interactive (arg-descriptor &rest modes)
>>>   (if (< emacs-major-version 28)
>>>       `(interactive ,arg-descriptor)
>>>     `(interactive ,arg-descriptor ,@(mapcar #'eval modes))))
>>
>> Why is the eval necessary?
>
> Because the correct interactive form is:
>
>     (interactive ... foo-mode)
>
> Rather than:
>
>     (interactive ... 'foo-mode)
>
>>> (defun foo (arg)
>>>   (future-interactive "P" 'fundamental-mode)
                              ^^
Then don't do that ;).

-- 
Basil

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>>>> (defun foo (arg)
>>>>   (future-interactive "P" 'fundamental-mode)
>                               ^^
> Then don't do that ;).

Fair point!  ;-)

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>>> Hm...  perhaps a core package would be the best solution here?
>>
>> I don't think we currently have any other way to make it easy to use on
>> master, do we?
>
> Hm...  I guess not.

Please find attached a patch.

[-- Attachment #2: 0001-Add-new-forward-compatibility-package-future-interac.patch --]
[-- Type: text/x-diff, Size: 4513 bytes --]

From bfec0bd8971e93c85353f7415960fdbbfe6c3f01 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Sun, 14 Feb 2021 20:45:56 +0100
Subject: [PATCH] Add new forward compatibility package 'future-interactive'

* lisp/emacs-lisp/future-interactive.el:
* test/lisp/emacs-lisp/future-interactive-tests.el: New files.
---
 lisp/emacs-lisp/future-interactive.el         | 58 +++++++++++++++++++
 .../emacs-lisp/future-interactive-tests.el    | 38 ++++++++++++
 2 files changed, 96 insertions(+)
 create mode 100644 lisp/emacs-lisp/future-interactive.el
 create mode 100644 test/lisp/emacs-lisp/future-interactive-tests.el

diff --git a/lisp/emacs-lisp/future-interactive.el b/lisp/emacs-lisp/future-interactive.el
new file mode 100644
index 0000000000..fe12924194
--- /dev/null
+++ b/lisp/emacs-lisp/future-interactive.el
@@ -0,0 +1,58 @@
+;;; future-interactive.el --- Forward compatibility for `interactive' in Emacs 28.  -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2021 Free Software Foundation, Inc.
+
+;; Author: Stefan Kangas <stefankangas@gmail.com>
+;; Keywords: lisp, compatibility
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; This is a forward compatibility package to allow maintaining
+;; support for older versions of Emacs while also using the new third
+;; argument to the `interactive'form added in Emacs 28.
+;;
+;; To use this in a package, just add a dependency on this package and
+;; replace `interactive' with `future-interactive':
+;;
+;;     (require 'future-interactive)
+;;
+;;     (defun foo-command ()
+;;       (future-interactive nil foo-mode)
+;;       ... )
+;;
+;; See the `future-interactive' macro for more information.
+
+;;; Code:
+
+;; This is a GNU ELPA :core package to be able to easily use this in
+;; other :core packages.
+
+(defmacro future-interactive (arg-descriptor &rest modes)
+  "Use the correct `interactive' form for any Emacs version.
+
+This is a forward compatibility macro that allows packages to
+provide the third argument to `interactive' (added in Emacs 28)
+while still working on older versions of Emacs.
+
+To use it, simply replace `interactive' with `future-interactive'."
+  (if (< emacs-major-version 28)
+      `(interactive ,arg-descriptor)
+    `(interactive ,arg-descriptor ,@modes)))
+
+(provide 'future-interactive)
+;;; future-interactive.el ends here
diff --git a/test/lisp/emacs-lisp/future-interactive-tests.el b/test/lisp/emacs-lisp/future-interactive-tests.el
new file mode 100644
index 0000000000..f525d03fcb
--- /dev/null
+++ b/test/lisp/emacs-lisp/future-interactive-tests.el
@@ -0,0 +1,38 @@
+;;; future-interactive-tests.el --- Tests for future-interactive.el  -*- lexical-binding: t -*-
+
+;; Copyright (C) 2021 Free Software Foundation, Inc.
+
+;; Author: Stefan Kangas <stefankangas@gmail.com>
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;;; Code:
+
+(require 'ert)
+(require 'future-interactive)
+
+(defun foo (args)
+  (future-interactive "P" fundamental-mode)
+  (message "args is %s" args))
+
+(ert-deftest future-interactive-test ()
+  (should (fboundp 'foo))
+  (should (foo t)))
+
+(provide 'future-interactive-tests)
+;;; future-interactive-tests.el ends here
-- 
2.30.0

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Jose A. Ortega Ruiz]

given the 97% statistic, would it be possible to also have a
buffer-local default-interactive-mode (or some declaration at global
scope) setting a default value for the third argument of (interactive x)
when not given?

that way i could just write at the top of my jao-awful-mode.el package:

   (setq-local default-interactive-mode 'jao-awful-mode)

and use only backwards compatible interactive forms in the rest of the
code.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Monnier]

> given the 97% statistic, would it be possible to also have a
> buffer-local default-interactive-mode (or some declaration at global
> scope) setting a default value for the third argument of (interactive x)
> when not given?
>
> that way i could just write at the top of my jao-awful-mode.el package:
>
>    (setq-local default-interactive-mode 'jao-awful-mode)
>
> and use only backwards compatible interactive forms in the rest of the
> code.

That would make a lot of sense, indeed.
Then you'd have to mark specially the few commands that are not tied to
the major mode (if any), but that'd be a lot less work.


        Stefan

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 14 Feb 2021 14:25:42 -0600
> Cc: emacs-devel@gnu.org, Dmitry Gutov <dgutov@yandex.ru>
> 
> Please find attached a patch.

Isn't this a bit premature?  I thought we were still debating how best
to implement the annotations?

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Please find attached a patch.

Looks good to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Isn't this a bit premature?  I thought we were still debating how best
> to implement the annotations?

The discussion seems to have evaporated, so...

Stefan M was in favour of using contextual annotation, so that

(some-new-directive 'foo-mode)

(defun foo-thing1 ()
  (interactive))

(defun foo-thing2 ()
  (interactive))

means that these two commands are tagged as being for foo-mode, and then
using "negative tagging" like

  (declare (completion t))

on the commands that shouldn't get that tagging.  He didn't expound on
why -- whether he just thinks (interactive "p" foo-mode) is just too
ugly, and offends the eye, or whether this would be less work.

It won't be less work -- adding the markup is mechanical, but whether a
command should be mode-specific (and in what mode it should be in) is
what requires work: You have to actually look at each command and make
the determination (and that's the case whether you use contextual
annotations or not).

For instance, I tagged up message.el, and most of the commands are for
message mode, some are general, and there's one command
(`message-make-html-message-with-image-files') that only works in
dired-mode.  (This sort of thing is more common than you'd think --
there's a bunch of commands work in the intersection of two modes, so
it's arbitrary what file they end up in.)

(I've already written about how I think contextual annotations are a
long-term maintenance nightmare, so I won't repeat that bit here.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org,
>   dgutov@yandex.ru
> Date: Tue, 16 Feb 2021 13:15:13 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Isn't this a bit premature?  I thought we were still debating how best
> > to implement the annotations?
> 
> The discussion seems to have evaporated, so...

Without any conclusions.

I'm still worried about the incompatibility we are introducing into
byte code, and so were a couple of others.  You dismissed those
concerns, and I frankly don't understand how they can be dismissed.

To me, the proposed alternatives sound like a clear win, since the
downsides are non-existent, whereas the advantage is clear.  Why do we
need to insist on introducing bytecode incompatibility?

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm still worried about the incompatibility we are introducing into
> byte code, and so were a couple of others.  You dismissed those
> concerns, and I frankly don't understand how they can be dismissed.
>
> To me, the proposed alternatives sound like a clear win, since the
> downsides are non-existent, whereas the advantage is clear.  Why do we
> need to insist on introducing bytecode incompatibility?

Nobody responded to my dismissals, so I have no idea what parts (if any)
of those people thought were insufficient.

Could you explain, perhaps?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Tue, 16 Feb 2021 17:31:31 +0100
> 
> > To me, the proposed alternatives sound like a clear win, since the
> > downsides are non-existent, whereas the advantage is clear.  Why do we
> > need to insist on introducing bytecode incompatibility?
> 
> Nobody responded to my dismissals, so I have no idea what parts (if any)
> of those people thought were insufficient.

I thought they did, but maybe I've mixed up the chronology here, as
mail delivery was behaving strangely during the last few days.

> Could you explain, perhaps?

What part would you like me to explain?

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > To me, the proposed alternatives sound like a clear win, since the
>> > downsides are non-existent, whereas the advantage is clear.  Why do we
>> > need to insist on introducing bytecode incompatibility?
>> 
>> Nobody responded to my dismissals, so I have no idea what parts (if any)
>> of those people thought were insufficient.
>
> I thought they did, but maybe I've mixed up the chronology here, as
> mail delivery was behaving strangely during the last few days.
>
>> Could you explain, perhaps?
>
> What part would you like me to explain?

Why it's important that commands loaded from .elc files are backwards
compatible when commands loaded from .el files aren't, for instance.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Tue, 16 Feb 2021 18:06:38 +0100
> 
> Why it's important that commands loaded from .elc files are backwards
> compatible when commands loaded from .el files aren't, for instance.

The command's body is the same, so it is IMO a disadvantage to have a
.elc file that can only be loaded by Emacs >= 28.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Why it's important that commands loaded from .elc files are backwards
>> compatible when commands loaded from .el files aren't, for instance.
>
> The command's body is the same, so it is IMO a disadvantage to have a
> .elc file that can only be loaded by Emacs >= 28.

The .elc file can be loaded fine -- the only incompatibility is in the
interactive spec bit (both in the .el file and in the .elc file).

So "not backwards compatible bytecode" is perhaps overstating the case.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Tue, 16 Feb 2021 18:39:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Why it's important that commands loaded from .elc files are backwards
> >> compatible when commands loaded from .el files aren't, for instance.
> >
> > The command's body is the same, so it is IMO a disadvantage to have a
> > .elc file that can only be loaded by Emacs >= 28.
> 
> The .elc file can be loaded fine -- the only incompatibility is in the
> interactive spec bit (both in the .el file and in the .elc file).
> 
> So "not backwards compatible bytecode" is perhaps overstating the case.

I don't think I agree.

Looking at it from another aspect: don't you agree that the
alternative solutions are less intrusive?  They introduce neither new
syntax nor new semantics, they just use existing facilities.  Thus,
those alternatives don't increase complexity as much as the new arg of
'interactive'.  It is advantageous to have a solution with less
complexity.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Looking at it from another aspect: don't you agree that the
> alternative solutions are less intrusive?  They introduce neither new
> syntax nor new semantics, they just use existing facilities.  Thus,
> those alternatives don't increase complexity as much as the new arg of
> 'interactive'.  It is advantageous to have a solution with less
> complexity.

But that's a different discussion.

I take it that the conclusion to the question I asked ("is there a point
to having the .elc files be compatible when the .el files aren't?") is
"no, there's no point in that".

Are we in agreement on that?  If so, could you tell me what's wrong with
that logic?

The other question you're now re-asking is: Does it make sense to
introduce a new `interactive' form?

And I've argued that point repeatedly, and I don't really wish to repeat
myself.  I can do so if you think it would help, though -- just let me
know.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Tue, 16 Feb 2021 19:10:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Looking at it from another aspect: don't you agree that the
> > alternative solutions are less intrusive?  They introduce neither new
> > syntax nor new semantics, they just use existing facilities.  Thus,
> > those alternatives don't increase complexity as much as the new arg of
> > 'interactive'.  It is advantageous to have a solution with less
> > complexity.
> 
> But that's a different discussion.
> 
> I take it that the conclusion to the question I asked ("is there a point
> to having the .elc files be compatible when the .el files aren't?") is
> "no, there's no point in that".
> 
> Are we in agreement on that?

No, we are not.

> The other question you're now re-asking is: Does it make sense to
> introduce a new `interactive' form?
> 
> And I've argued that point repeatedly, and I don't really wish to repeat
> myself.  I can do so if you think it would help, though -- just let me
> know.

I just cannot understand why you insist on this solution as the only
one, when there are others that can do the job without the downsides.
Is "compromise" a dirty word or something?

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I take it that the conclusion to the question I asked ("is there a point
>> to having the .elc files be compatible when the .el files aren't?") is
>> "no, there's no point in that".
>> 
>> Are we in agreement on that?
>
> No, we are not.

Could you explain what your disagreement is on this point?  That would
be helpful.

>> The other question you're now re-asking is: Does it make sense to
>> introduce a new `interactive' form?
>> 
>> And I've argued that point repeatedly, and I don't really wish to repeat
>> myself.  I can do so if you think it would help, though -- just let me
>> know.
>
> I just cannot understand why you insist on this solution as the only
> one, when there are others that can do the job without the downsides.
> Is "compromise" a dirty word or something?

OK, so you want me to re-iterate my arguments, once again?

OK.

I think that if mode tagging is something that is going to happen on a
large scale, the mechanism for doing this must be clear, easy and
maintainable.  Tagging 97% of our commands with

(defun foo ()
  (declare (completion foo-mode))
  (interactive "p"))

seems like a much worse solution in the "clear and easy" dept than

(defun foo ()
  (interactive "p" foo-mode))

Do you disagree with this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Tue, 16 Feb 2021 19:36:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I take it that the conclusion to the question I asked ("is there a point
> >> to having the .elc files be compatible when the .el files aren't?") is
> >> "no, there's no point in that".
> >> 
> >> Are we in agreement on that?
> >
> > No, we are not.
> 
> Could you explain what your disagreement is on this point?  That would
> be helpful.

I already explained that.  You didn't agree with my arguments, so I
see no reason to reiterate them.  But that doesn't mean I agree.
Having incompatible byte code is BAD.

> I think that if mode tagging is something that is going to happen on a
> large scale, the mechanism for doing this must be clear, easy and
> maintainable.  Tagging 97% of our commands with
> 
> (defun foo ()
>   (declare (completion foo-mode))
>   (interactive "p"))
> 
> seems like a much worse solution in the "clear and easy" dept than
> 
> (defun foo ()
>   (interactive "p" foo-mode))
> 
> Do you disagree with this?

Yes, I disagree that the former is not clear, easy, and maintainable.
We've been using similar constructs for years.

There was also a suggest to use symbol properties.  that is also
something we use widely in Emacs, including in the new
completion-default-include-p function (and in many other places).

They are all good, clean, maintainable practices which we are using
and will continue to use.  I don't see why 'interactive' is better.
In fact, I could make a case to the contrary: it is already a kind of
magic, as can be clearly seen from its implementation.  Explaining how
it works needs quite a few words.  So it isn't as clear as might
appear at first sight.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I already explained that.  You didn't agree with my arguments, so I
> see no reason to reiterate them.  But that doesn't mean I agree.
> Having incompatible byte code is BAD.

OK, I must have missed the arguments.  Beyond it being bad, in a general
way, for some reason or other.

>> I think that if mode tagging is something that is going to happen on a
>> large scale, the mechanism for doing this must be clear, easy and
>> maintainable.  Tagging 97% of our commands with
>> 
>> (defun foo ()
>>   (declare (completion foo-mode))
>>   (interactive "p"))
>> 
>> seems like a much worse solution in the "clear and easy" dept than
>> 
>> (defun foo ()
>>   (interactive "p" foo-mode))
>> 
>> Do you disagree with this?
>
> Yes, I disagree that the former is not clear, easy, and maintainable.
> We've been using similar constructs for years.

That's not quite a response to what I asked: Which one of those syntaxes
are clearer and easier?  (To read and to write.)

> There was also a suggest to use symbol properties.  that is also
> something we use widely in Emacs, including in the new
> completion-default-include-p function (and in many other places).
>
> They are all good, clean, maintainable practices which we are using
> and will continue to use.  I don't see why 'interactive' is better.
> In fact, I could make a case to the contrary: it is already a kind of
> magic, as can be clearly seen from its implementation.  Explaining how
> it works needs quite a few words.  So it isn't as clear as might
> appear at first sight.

I think it's clear that the new interactive spec leads to commands that
are easier to read and write than if (virtually all) commands need a
second (pretty obscure) incantation -- interactive/declare then works in
concert, and you have to understand both.

The question is then: Is this clarity worth it to introduce a
non-backwards compatible syntax in Emacs Lisp?  My answer is, of course,
"yes", but I can see that there might be disagreement on that point.  My
answer, to restate it yet again, is that Emacs Lisp has never shied away
from introducing new macros, functions and special forms if we think
that's the best long-term language solution.

Code meant for older Emacs versions then can't use the new syntax, but
that's not special for `interactive' -- it's the same with any new form.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Tue, 16 Feb 2021 20:31:01 +0100
> 
> > Yes, I disagree that the former is not clear, easy, and maintainable.
> > We've been using similar constructs for years.
> 
> That's not quite a response to what I asked: Which one of those syntaxes
> are clearer and easier?  (To read and to write.)

I find both to be of the same level of clarity and easiness of
reading and writing.

> I think it's clear that the new interactive spec leads to commands that
> are easier to read and write than if (virtually all) commands need a
> second (pretty obscure) incantation -- interactive/declare then works in
> concert, and you have to understand both.

I don't think an addition of a 'declare' form makes the function
harder to read, no.

Moreover, I believe many (most?) commands will remain unmarked,
because they make sense in any mode.

So I don't see any significant advantages in using 'interactive' for
this purpose, but I do see disadvantages.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Yes, I disagree that the former is not clear, easy, and maintainable.
>> > We've been using similar constructs for years.
>>
>> That's not quite a response to what I asked: Which one of those syntaxes
>> are clearer and easier?  (To read and to write.)
>
> I find both to be of the same level of clarity and easiness of
> reading and writing.

To my mind, if two forms of writing the same thing are equally clear and
easy to understand, the less verbose one is often the better choice.
But I would claim that the more verbose form in this case is less clear
and harder to understand.

It is also more typing, so isn't it obviously therefore also harder to
write?  I'm not talking mainly about the number of keys pressed, which I
think we can agree objectively speaking will be higher, but the amount
of new things you need to learn and remember to write even fairly basic
Emacs Lisp.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 16 Feb 2021 14:30:08 -0600
> Cc: dgutov@yandex.ru, emacs-devel@gnu.org
> 
> To my mind, if two forms of writing the same thing are equally clear and
> easy to understand, the less verbose one is often the better choice.
> But I would claim that the more verbose form in this case is less clear
> and harder to understand.
> 
> It is also more typing, so isn't it obviously therefore also harder to
> write?  I'm not talking mainly about the number of keys pressed, which I
> think we can agree objectively speaking will be higher, but the amount
> of new things you need to learn and remember to write even fairly basic
> Emacs Lisp.

I think these nano-issues, if they are issues at all, don't come close
to justifying incompatible changes.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Dmitry Gutov]

On 16.02.2021 22:30, Stefan Kangas wrote:
> But I would claim that the more verbose form in this case is less clear
> and harder to understand.

That's because 'completion' is not a good name for it: it doesn't, 
indeed, explain what the value is. Nor does it say that it will be used 
by the proposed execute-extended-current-mode-command command.

OTOH, if we had annotations like

(declare (applicable-major-modes MODE1 MODE2 ...))
(declare (applicable-minor-modes MODE1 MODE2 ...))

it would both allow some speed improvement in the completion predicate 
(don't have to apply both major and minor mode checks to each symbol) 
and more consistently allow read-extended-command-predicate to use 
arbitrary conditions (at the user's choice).

The list of annotations can be expanded with other tags, too, as well as 
with a free-form predicate

(declare (applicable-pred PRED))

P.S. I'm guessing the applicable-* names look pretty long for a number 
of readers here. Surely someone can pick a shorter naming scheme that's 
still semantic.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think these nano-issues, if they are issues at all, don't come close
> to justifying incompatible changes.

I think that in the long term, taking care to not make simple things
like making a command for a mode too arduous, is important.

And again, I don't see what makes extending `interactive' so special
here.  We introduce new things in Emacs Lisp all the time when we think
that that improves the language.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Dmitry Gutov]

On 17.02.2021 00:00, Lars Ingebrigtsen wrote:
> And again, I don't see what makes extending `interactive' so special
> here.  We introduce new things in Emacs Lisp all the time when we think
> that that improves the language.

You're extending it in an incompatible way, one that most third-party 
code won't be able to make use of for years to come. And this extension 
basically sets in stone the kinds of "tags" 
read-extended-command-predicate can meaningfully use. The new feature 
being added to 'interactive' is non-extensible.

And yet, we have an alternative approach which is both more flexible and 
available for people to use now. I don't see why we would want to spend 
effort on maintaining support for both, honestly.

As for verbosity, it's not like there weren't any suggestions to reduce 
the number of annotations either (like tying command definitions to 
packages, or custom groups, etc).

Also, why all the new functions in simple.el are called simply 
completion-*? They are not applicable to completion in any other 
contexts, only to command completion in M-x.

RE: [External] : Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Drew Adams]

> I think that in the long term, taking care to not
> make simple things like making a command for a
> mode too arduous, is important.

I may be missing something, but is making a command
for a mode arduous now (before your recent changes)?
Just what's hard about it?  Haven't we all been
making mode-specific commands painlessly forever?

Is it possible that you have a new hammer and are
looking for nails to use it on?  I know you said,
in response to Stefan's suggestion of that, that
you're now seeing nails everywhere.

But that's precisely the symptom of Hammeritis,
akin to a pregnant woman noticing that there are
pregnant women everywhere she looks.

Or perhaps your "nails sticking out all over the
place" was just another joke, not a statement that
you think there's really a great need for this new
feature - that there really are lots of nails
sticking out, needing hammering?

> And again, I don't see what makes extending
> `interactive' so special here.  We introduce
> new things in Emacs Lisp all the time when we
> think that that improves the language.

... for some definition of "new things", "we",
and "all the time".

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 17.02.2021 00:00, Lars Ingebrigtsen wrote:
>> And again, I don't see what makes extending `interactive' so special
>> here.  We introduce new things in Emacs Lisp all the time when we think
>> that that improves the language.
>
> You're extending it in an incompatible way, one that most third-party
> code won't be able to make use of for years to come.

And, again, what makes `interactive' special here?  Any time we
introduce something new on the language level, of course you can't use
that in older Emacs versions.

(Stefan K's macro makes it trivial to use in out-of-tree packages,
though.)

> And this extension basically sets in stone the kinds of "tags"
> read-extended-command-predicate can meaningfully use. The new feature
> being added to 'interactive' is non-extensible.

No, you can add any predicates you want.  But not via `interactive'.

> As for verbosity, it's not like there weren't any suggestions to
> reduce the number of annotations either (like tying command
> definitions to packages, or custom groups, etc).

And I responded to all of those and said why I thought those were bad
ideas.

> Also, why all the new functions in simple.el are called simply
> completion-*? They are not applicable to completion in any other
> contexts, only to command completion in M-x.

Better names are welcome.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Alan Mackenzie]

Hello, Lars.

On Tue, Feb 16, 2021 at 23:00:30 +0100, Lars Ingebrigtsen wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> > I think these nano-issues, if they are issues at all, don't come close
> > to justifying incompatible changes.

> I think that in the long term, taking care to not make simple things
> like making a command for a mode too arduous, is important.

Other people disagree with your judgment, here.  Normally, before making
massive changes, the proposed changes are first discussed on this list
and a consensus reached.  And for major changes, these are, and should
be, done first on a branch, to enable them to be evaluated before being
merged.  Neither of these things has happened in this case.

> And again, I don't see what makes extending `interactive' so special
> here.

I explained that in my post from Sun, 14 Feb 2021 15:03:53 +0000.  You
ignored that post, as you have ignored so many posts questioning your
new scheme.  Instead you've ploughed ahead with the changes, without
waiting for the desired consensus.

> We introduce new things in Emacs Lisp all the time when we think that
> that improves the language.

That won't cut it.  That verges on being untruthful.  This isn't an
ordinary change, it's a particularly fundamental change in Emacs's
structures.  Done by you acting alone.

And "We"?  Who is "we" here?  Normally, large changes are made by
consensus.  For this change there is no consensus.  The fact is, the
effect of this change could have been had without the questionable major
changes you're imposing on Emacs.

What sort of project is Emacs to be?  Up till now, as I say, it has
worked by consensus and respect.  Do you want these qualities to be
continued from this point on?  I hope so.

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> Other people disagree with your judgment, here.

And some agree.

> I explained that in my post from Sun, 14 Feb 2021 15:03:53 +0000.  You
> ignored that post, as you have ignored so many posts questioning your
> new scheme.  Instead you've ploughed ahead with the changes, without
> waiting for the desired consensus.

I have posted more than 50 posts about this in the last few days, but I
haven't responded to all messages -- especially since Stefan K had
already rebutted the points in your post.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Alan Mackenzie]

Hello, Lars.

On Tue, Feb 16, 2021 at 23:55:23 +0100, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Other people disagree with your judgment, here.

> And some agree.

One of those people questioning that judgment is Eli Zaretskii, the
chief maintainer of Emacs.

> > I explained that in my post from Sun, 14 Feb 2021 15:03:53 +0000.  You
> > ignored that post, as you have ignored so many posts questioning your
> > new scheme.  Instead you've ploughed ahead with the changes, without
> > waiting for the desired consensus.

> I have posted more than 50 posts about this in the last few days, but I
> haven't responded to all messages

Many of these posts merely responded to the points made without
answering them.  In fact, some of them were downright evasive, including
at least some to Eli from this evening.  Why did you not deal with these
points before hacking master?

> -- especially since Stefan K had already rebutted the points in your
> post.

He did no such thing.  He expressed a view contrary to mine, and I'm not
sure he even understood what I was saying.  His posts lacked the
customary semantic redundancy that would allow a proper discussion to
have developed.  Indeed, it seemed clear he wasn't leaving any opening
for such a discussion.

But my points have not been answered properly.  You are the person
driving these far-reaching changes.  Why are you evading scrutiny of
them?  Why are you making these changes on master rather than in a
branch?  It seems you want to present a fait accompli without the
consensus.  Why?

Why are you treating Eli with such disrespect?

Again, I ask you, what sort of project do you want Emacs to be?  Do you
value the respect and consensus which has been prevalent up to now, or
are you trying to supplant it with something else?

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> Many of these posts merely responded to the points made without
> answering them.  In fact, some of them were downright evasive, including
> at least some to Eli from this evening.

I don't agree with your assessment as to my posts being evasive.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Dmitry Gutov]

On 17.02.2021 00:37, Lars Ingebrigtsen wrote:

>> Also, why all the new functions in simple.el are called simply
>> completion-*? They are not applicable to completion in any other
>> contexts, only to command completion in M-x.
> 
> Better names are welcome.

command-completion-* should be better.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 17.02.2021 00:00, Lars Ingebrigtsen wrote:
>> And again, I don't see what makes extending `interactive' so special
>> here.  We introduce new things in Emacs Lisp all the time when we think
>> that that improves the language.
>
> You're extending it in an incompatible way, one that most third-party
> code won't be able to make use of for years to come.

I don't think the second half of this sentence is correct.  Please see
my compatibility macro `future-interactive' posted to this list.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Juri Linkov]

> To my mind, if two forms of writing the same thing are equally clear and
> easy to understand, the less verbose one is often the better choice.
> But I would claim that the more verbose form in this case is less clear
> and harder to understand.

The question is how this form is less clear and harder to understand:

(defun Info-follow-reference (footnotename &optional fork)
  (declare (completion Info-mode))
  ================================
  (interactive
   (let ((completion-ignore-case t)
	 (case-fold-search t)
	 completions default alt-default (start-point (point)) str i bol eol)
     (save-excursion
       ;; Store end and beginning of line.
       (setq eol (line-end-position)
             bol (line-beginning-position))
       (goto-char (point-min))
       (while (re-search-forward "\\*note[ \n\t]+\\([^:]*\\):" nil t)
	 (setq str (match-string-no-properties 1))
	 ;; See if this one should be the default.
	 (and (null default)
	      (<= (match-beginning 0) start-point)
	      (<= start-point (point))
	      (setq default t))
	 ;; See if this one should be the alternate default.
	 (and (null alt-default)
	      (and (<= bol (match-beginning 0))
		   (<= (point) eol))
	      (setq alt-default t))
	 (setq i 0)
	 (while (setq i (string-match "[ \n\t]+" str i))
	   (setq str (concat (substring str 0 i) " "
			     (substring str (match-end 0))))
	   (setq i (1+ i)))
	 ;; Record as a completion and perhaps as default.
	 (if (eq default t) (setq default str))
	 (if (eq alt-default t) (setq alt-default str))
	 ;; Don't add this string if it's a duplicate.
	 (or (assoc-string str completions t)
	     (push str completions))))
     ;; If no good default was found, try an alternate.
     (or default
	 (setq default alt-default))
     ;; If only one cross-reference found, then make it default.
     (if (eq (length completions) 1)
         (setq default (car completions)))
     (if completions
	 (let ((input (completing-read (if default
					   (concat
					    "Follow reference named (default "
					    default "): ")
					 "Follow reference named: ")
				       completions nil t)))
	   (list (if (equal input "")
		     default input)
                 current-prefix-arg))
       (user-error "No cross-references in this node"))))

than what we have now in master (see the difference at the end):

(defun Info-follow-reference (footnotename &optional fork)
  (interactive
   (let ((completion-ignore-case t)
	 (case-fold-search t)
	 completions default alt-default (start-point (point)) str i bol eol)
     (save-excursion
       ;; Store end and beginning of line.
       (setq eol (line-end-position)
             bol (line-beginning-position))
       (goto-char (point-min))
       (while (re-search-forward "\\*note[ \n\t]+\\([^:]*\\):" nil t)
	 (setq str (match-string-no-properties 1))
	 ;; See if this one should be the default.
	 (and (null default)
	      (<= (match-beginning 0) start-point)
	      (<= start-point (point))
	      (setq default t))
	 ;; See if this one should be the alternate default.
	 (and (null alt-default)
	      (and (<= bol (match-beginning 0))
		   (<= (point) eol))
	      (setq alt-default t))
	 (setq i 0)
	 (while (setq i (string-match "[ \n\t]+" str i))
	   (setq str (concat (substring str 0 i) " "
			     (substring str (match-end 0))))
	   (setq i (1+ i)))
	 ;; Record as a completion and perhaps as default.
	 (if (eq default t) (setq default str))
	 (if (eq alt-default t) (setq alt-default str))
	 ;; Don't add this string if it's a duplicate.
	 (or (assoc-string str completions t)
	     (push str completions))))
     ;; If no good default was found, try an alternate.
     (or default
	 (setq default alt-default))
     ;; If only one cross-reference found, then make it default.
     (if (eq (length completions) 1)
         (setq default (car completions)))
     (if completions
	 (let ((input (completing-read (if default
					   (concat
					    "Follow reference named (default "
					    default "): ")
					 "Follow reference named: ")
				       completions nil t)))
	   (list (if (equal input "")
		     default input)
                 current-prefix-arg))
       (user-error "No cross-references in this node")))
   Info-mode)
   =========

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Juri Linkov]

>> As for verbosity, it's not like there weren't any suggestions to
>> reduce the number of annotations either (like tying command
>> definitions to packages, or custom groups, etc).
>
> And I responded to all of those and said why I thought those were bad
> ideas.

Then why we are removing :group tags from defcustom?  Because they are redundant.
Completion annotations are redundant the same way.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

>>> As for verbosity, it's not like there weren't any suggestions to
>>> reduce the number of annotations either (like tying command
>>> definitions to packages, or custom groups, etc).
>>
>> And I responded to all of those and said why I thought those were bad
>> ideas.
>
> Then why we are removing :group tags from defcustom?  Because they are redundant.
> Completion annotations are redundant the same way.

Not exactly in the same way, because the overwhelmingly most common case
with :group tags is that all defcustoms in one file share the same group.

With completion annotations, we have seen ratios from 50-75 %.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

>> To my mind, if two forms of writing the same thing are equally clear and
>> easy to understand, the less verbose one is often the better choice.
>> But I would claim that the more verbose form in this case is less clear
>> and harder to understand.
>
> The question is how this form is less clear and harder to understand:

That's fair enough.  But it also seems like a pathological case.

(If we support both forms, you could choose the one that is more clear.)

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> command-completion-* should be better.

It's a bit of a mouthful, but I guess it makes sense, so I've now
renamed the predicates.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

>> The question is how this form is less clear and harder to understand:
>
> That's fair enough.  But it also seems like a pathological case.

Interactive specs that are of that size are highly unusual, so
optimising for that case seems misguided.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Then why we are removing :group tags from defcustom?  Because they
>> are redundant.
>> Completion annotations are redundant the same way.
>
> Not exactly in the same way, because the overwhelmingly most common case
> with :group tags is that all defcustoms in one file share the same group.
>
> With completion annotations, we have seen ratios from 50-75 %.

Indeed.  The :group thing is a problem of an entirely different
magnitude.

(That said, I'm not really enthusiastic about :group removal.  :-)  But
it's Customize, which is kinda hard to care much about anyway, so
whoever actually cares can decide.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Dmitry Gutov]

On 17.02.2021 13:02, Lars Ingebrigtsen wrote:
>> command-completion-* should be better.
> It's a bit of a mouthful, but I guess it makes sense, so I've now
> renamed the predicates.

Thank you.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Monnier]

>>> And again, I don't see what makes extending `interactive' so special
>>> here.  We introduce new things in Emacs Lisp all the time when we think
>>> that that improves the language.
>> You're extending it in an incompatible way, one that most third-party
>> code won't be able to make use of for years to come.
> I don't think the second half of this sentence is correct.  Please see
> my compatibility macro `future-interactive' posted to this list.

Side note: IIUC this macro relies on "eager macroexpansion", so there
are corner cases where it won't work.  I don't think these matter very
much in practice, unless maybe ... have you checked that it works
correctly with Edebug?


        Stefan

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  dgutov@yandex.ru,
>   emacs-devel@gnu.org
> Date: Tue, 16 Feb 2021 23:00:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think these nano-issues, if they are issues at all, don't come close
> > to justifying incompatible changes.
> 
> I think that in the long term, taking care to not make simple things
> like making a command for a mode too arduous, is important.

I don't think using 'declare' or a plist can be characterized as
"arduous".

> And again, I don't see what makes extending `interactive' so special
> here.  We introduce new things in Emacs Lisp all the time when we think
> that that improves the language.

It's not the extension per se, it's the fact that it causes
difficulties, as mentioned in this thread.  they may be small
difficulties, but the alternatives avoid them completely, and aren't
more complex.  I think using one of the alternatives will leave more
developers happy, and that in itself is a significant advantage, IMO.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> Date: Tue, 16 Feb 2021 22:47:20 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
>   Stefan Kangas <stefankangas@gmail.com>, dgutov@yandex.ru
> From: Alan Mackenzie <acm@muc.de>
> 
> That won't cut it.  That verges on being untruthful.  This isn't an
> ordinary change, it's a particularly fundamental change in Emacs's
> structures.  Done by you acting alone.
> 
> And "We"?  Who is "we" here?  Normally, large changes are made by
> consensus.  For this change there is no consensus.  The fact is, the
> effect of this change could have been had without the questionable major
> changes you're imposing on Emacs.

Let's not get too personal here, okay?  No matter how serious are
technical disagreements, there's no reason to suspect Lars of even a
shadow of ill will or intent to subvert the Emacs project.

> What sort of project is Emacs to be?  Up till now, as I say, it has
> worked by consensus and respect.  Do you want these qualities to be
> continued from this point on?  I hope so.

And this line will not lead to any useful discussions, so I suggest
that we drop it.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> Date: Tue, 16 Feb 2021 23:20:29 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
>   Stefan Kangas <stefankangas@gmail.com>, dgutov@yandex.ru
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Other people disagree with your judgment, here.
> 
> > And some agree.
> 
> One of those people questioning that judgment is Eli Zaretskii, the
> chief maintainer of Emacs.

FTR, that's not my title, never was.

I consider my opinions no more important than those of Lars (and no
less, hopefully).

> Why are you treating Eli with such disrespect?

I don't feel being treated disrespectfully by Lars, FWIW.

Once again, let's avoid making this discussion too ad-hominem.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 17 Feb 2021 00:50:55 -0800
> Cc: emacs-devel@gnu.org
> 
> > You're extending it in an incompatible way, one that most third-party
> > code won't be able to make use of for years to come.
> 
> I don't think the second half of this sentence is correct.  Please see
> my compatibility macro `future-interactive' posted to this list.

The alternative solutions don't need such shims, which is an
advantage.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Dmitry Gutov]

On 17.02.2021 10:50, Stefan Kangas wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 17.02.2021 00:00, Lars Ingebrigtsen wrote:
>>> And again, I don't see what makes extending `interactive' so special
>>> here.  We introduce new things in Emacs Lisp all the time when we think
>>> that that improves the language.
>>
>> You're extending it in an incompatible way, one that most third-party
>> code won't be able to make use of for years to come.
> 
> I don't think the second half of this sentence is correct.  Please see
> my compatibility macro `future-interactive' posted to this list.

You're right, so strictly speaking, someone who really likes the new 
'interactive' form, can use it. At the cost of minor inconveniences like 
having to depend on an extra package, some grepping disadvantages and 
whatever potential issue with 'edebug' that Stefan mentioned.

RE: [External] : Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Matt Armstrong]

Drew Adams <drew.adams@oracle.com> writes:

>> I think that in the long term, taking care to not
>> make simple things like making a command for a
>> mode too arduous, is important.
>
> I may be missing something, but is making a command
> for a mode arduous now (before your recent changes)?
> Just what's hard about it?  Haven't we all been
> making mode-specific commands painlessly forever?
>
> Is it possible that you have a new hammer and are
> looking for nails to use it on?  I know you said,
> in response to Stefan's suggestion of that, that
> you're now seeing nails everywhere.

[...]

I think you're missing which came first.

The nail: Lars sought a way to associate interactive commands with
modes.  This is for the benefit of interactive help, completion in a
(new) command purpose built for mode specific commands, etc.

The Hammer: The interactive form currently under debate.

He did not change (interactive) and only then wonder what to do with it.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Juri Linkov]

>>>> As for verbosity, it's not like there weren't any suggestions to
>>>> reduce the number of annotations either (like tying command
>>>> definitions to packages, or custom groups, etc).
>>>
>>> And I responded to all of those and said why I thought those were bad
>>> ideas.
>>
>> Then why we are removing :group tags from defcustom?  Because they are redundant.
>> Completion annotations are redundant the same way.
>
> Not exactly in the same way, because the overwhelmingly most common case
> with :group tags is that all defcustoms in one file share the same group.
>
> With completion annotations, we have seen ratios from 50-75 %.

I don't know where you see such low ratios.  In a typical package like
gomoku.el there are 16 commands tagged with 'gomoku-mode', and 2 untagged.
This is 90% vs 10%.

It makes more sense to make tagging opt-out, i.e. to tag the whole package
like defgroup does.  Then tag only a few commands available globally.

Usually most commands in a package are internal, only a few of commands are
entry points.  Package entry points are usually tagged with the autoload cookie.

So only 10% of entry points need the `declare' tag, other 90% don't need any tagging.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Juri Linkov]

>>> To my mind, if two forms of writing the same thing are equally clear and
>>> easy to understand, the less verbose one is often the better choice.
>>> But I would claim that the more verbose form in this case is less clear
>>> and harder to understand.
>>
>> The question is how this form is less clear and harder to understand:
>
> That's fair enough.  But it also seems like a pathological case.

I see nothing pathological here - this is a quite common case,
maybe a little longer than others.  But such valid cases
should not be dismissed lightly.  It would be more hassle
and error-prone to support such long interactive specs with
a mode name dangling at the end.

> (If we support both forms, you could choose the one that is more clear.)

I see no need to support both.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Óscar Fuentes]

Juri Linkov <juri@linkov.net> writes:

>>>>> As for verbosity, it's not like there weren't any suggestions to
>>>>> reduce the number of annotations either (like tying command
>>>>> definitions to packages, or custom groups, etc).
>>>>
>>>> And I responded to all of those and said why I thought those were bad
>>>> ideas.
>>>
>>> Then why we are removing :group tags from defcustom?  Because they are redundant.
>>> Completion annotations are redundant the same way.
>>
>> Not exactly in the same way, because the overwhelmingly most common case
>> with :group tags is that all defcustoms in one file share the same group.
>>
>> With completion annotations, we have seen ratios from 50-75 %.
>
> I don't know where you see such low ratios.  In a typical package like
> gomoku.el there are 16 commands tagged with 'gomoku-mode', and 2 untagged.
> This is 90% vs 10%.
>
> It makes more sense to make tagging opt-out, i.e. to tag the whole package
> like defgroup does.  Then tag only a few commands available globally.
>
> Usually most commands in a package are internal, only a few of commands are
> entry points.  Package entry points are usually tagged with the autoload cookie.
>
> So only 10% of entry points need the `declare' tag, other 90% don't need any tagging.

As mentioned elsewhere, tagging is far from being a simple task. Each
command must be considered individually. Your example about gomoku is
not representative as it is an small, isolated package, i.e. you won't
use gomoku-* elsewhere outside gomoku, except for the entry point(s), of
course.

The statistics Lars posted about Gnus are telling: only about 6 of every
10 commands were tagged. I expect to see similar numbers on other large
packages, such as Org and Calc.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Stefan Kangas <stefankangas@gmail.com>,  dgutov@yandex.ru,
>>   emacs-devel@gnu.org
>> Date: Tue, 16 Feb 2021 23:00:30 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I think these nano-issues, if they are issues at all, don't come close
>> > to justifying incompatible changes.
>> 
>> I think that in the long term, taking care to not make simple things
>> like making a command for a mode too arduous, is important.
>
> I don't think using 'declare' or a plist can be characterized as
> "arduous".
>
>> And again, I don't see what makes extending `interactive' so special
>> here.  We introduce new things in Emacs Lisp all the time when we think
>> that that improves the language.
>
> It's not the extension per se, it's the fact that it causes
> difficulties, as mentioned in this thread.  they may be small
> difficulties, but the alternatives avoid them completely, and aren't
> more complex.  I think using one of the alternatives will leave more
> developers happy, and that in itself is a significant advantage, IMO.

Yes. Among other things, it would accelerate the adoption of the
feature, for instance. If most maintainers of external packages (which
includes Org and C-Mode) refrain from tagging their commands, the value
we get from the filtering diminishes.

As a language designer and implementer myself, I sympathize with Lars'
stance about language evolution but, apart from the controversy it is
facing, it will negatively affect the purpose that intends to serve.
Once the feature is popular enough we can migrate to the `interactive'
form, or even a better solution. This can start a trend about adding
features that depend on metainformation about commands and other
entities and we will benefit from ideas and experience on the coming
months.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Lars Ingebrigtsen <larsi@gnus.org>,
>   dgutov@yandex.ru,  emacs-devel@gnu.org
> Date: Wed, 17 Feb 2021 19:45:50 +0200
> 
> > (If we support both forms, you could choose the one that is more clear.)
> 
> I see no need to support both.

Agreed.  Supporting more than one form would be the worst of all
worlds in this case.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think that in the long term, taking care to not make simple things
>> like making a command for a mode too arduous, is important.
>
> I don't think using 'declare' or a plist can be characterized as
> "arduous".

I think it is.  We'd be demanding that people learn about obscure things
like `declare' just to write a little mode.  That's not good language
design.

>> And again, I don't see what makes extending `interactive' so special
>> here.  We introduce new things in Emacs Lisp all the time when we think
>> that that improves the language.
>
> It's not the extension per se, it's the fact that it causes
> difficulties, as mentioned in this thread.  they may be small
> difficulties, but the alternatives avoid them completely, and aren't
> more complex.  I think using one of the alternatives will leave more
> developers happy, and that in itself is a significant advantage, IMO.

The difficulties are minuscule.

If somebody wants to write code that backwards-compatible, then use the
compat library or use `declare'.  I don't see why that should stop us
from making the Emacs Lisp language better, and use the best language
construction in our in-tree code.

Doing otherwise makes no sense.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Dmitry Gutov]

On 17.02.2021 21:01, Óscar Fuentes wrote:
> Once the feature is popular enough we can migrate to the `interactive'
> form, or even a better solution. This can start a trend about adding
> features that depend on metainformation about commands and other
> entities and we will benefit from ideas and experience on the coming
> months.

Exactly.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 17.02.2021 21:01, Óscar Fuentes wrote:
>> Once the feature is popular enough we can migrate to the `interactive'
>> form, or even a better solution. This can start a trend about adding
>> features that depend on metainformation about commands and other
>> entities and we will benefit from ideas and experience on the coming
>> months.
>
> Exactly.

Then you can use the compat library -- in which case, removing the
compat-ness is a matter of search/replace instead of rewriting forms.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> Please find attached a patch.

Hm...  trying this out now, I don't think the compat macro solution
actually works.  That is, it works fine when byte-compiled, but not in
non-compiled code.  The reason for this is that `interactive-form' just
does a `Fassq' on the Lisp form and looks for the Qinteractive symbol.
Which is won't find if the symbol in `future-interactive'.

So I'm not sure a macro compat solution here can work.  I should have
caught this earlier, since I've been looking at `interactive-form' quite
a bit lately.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 17 Feb 2021 20:30:10 +0100
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I think that in the long term, taking care to not make simple things
> >> like making a command for a mode too arduous, is important.
> >
> > I don't think using 'declare' or a plist can be characterized as
> > "arduous".
> 
> I think it is.  We'd be demanding that people learn about obscure things
> like `declare' just to write a little mode.  That's not good language
> design.

Neither 'declare' nor 'plist' are obscure.  We use them all over the
place.  So we will have to agree to disagree about this.

> > It's not the extension per se, it's the fact that it causes
> > difficulties, as mentioned in this thread.  they may be small
> > difficulties, but the alternatives avoid them completely, and aren't
> > more complex.  I think using one of the alternatives will leave more
> > developers happy, and that in itself is a significant advantage, IMO.
> 
> The difficulties are minuscule.

We will have to agree to disagree about this as well.

And please note that I'm not the only one who disagrees with you and
prefers to use one of the alternatives.

> If somebody wants to write code that backwards-compatible, then use the
> compat library or use `declare'.  I don't see why that should stop us
> from making the Emacs Lisp language better, and use the best language
> construction in our in-tree code.

Using more than one construct for this is worse than using any one of
the possible solutions.

And I don't think the issue here is improving the language, the issue
is how to implement a feature with minimum adverse effects.  It's
about pragmatics, not about language development.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Monnier]

>> Please find attached a patch.
> Hm...  trying this out now, I don't think the compat macro solution
> actually works.  That is, it works fine when byte-compiled, but not in
> non-compiled code.  The reason for this is that `interactive-form' just
> does a `Fassq' on the Lisp form and looks for the Qinteractive symbol.
> Which is won't find if the symbol in `future-interactive'.

As I said, I think it will work whenever the code has been fully
macro-expanded, which happens not just for byte-compilation but also for
`eval-buffer`, or when loading a `.el` file.  We should arguably do it
at most other occasions (e.g. `C-M-x`), but someone will have to write
the corresponding patches.


        Stefan

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> As I said, I think it will work whenever the code has been fully
> macro-expanded, which happens not just for byte-compilation but also for
> `eval-buffer`, or when loading a `.el` file.  We should arguably do it
> at most other occasions (e.g. `C-M-x`), but someone will have to write
> the corresponding patches.

We can fix this in Emacs 28, of course -- but my point was that this
doesn't work (in general) in earlier Emacs versions.  (Which was the
point of the compat macro.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Monnier]

>> As I said, I think it will work whenever the code has been fully
>> macro-expanded, which happens not just for byte-compilation but also for
>> `eval-buffer`, or when loading a `.el` file.  We should arguably do it
>> at most other occasions (e.g. `C-M-x`), but someone will have to write
>> the corresponding patches.
>
> We can fix this in Emacs 28, of course -- but my point was that this
> doesn't work (in general) in earlier Emacs versions.  (Which was the
> point of the compat macro.)

It'll still work in most cases in older Emacsen, tho, since it works
when the code is byte-compiled, or `load`ed, or eval'd via `eval-buffer`
which should cover 99.9894% of the cases where a package's code will
be executed.


        Stefan

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Please find attached a patch.
>
> Hm...  trying this out now, I don't think the compat macro solution
> actually works.  That is, it works fine when byte-compiled, but not in
> non-compiled code.  The reason for this is that `interactive-form' just
> does a `Fassq' on the Lisp form and looks for the Qinteractive symbol.
> Which is won't find if the symbol in `future-interactive'.

It is working for me in Emacs 27, and it was working for me at the time
when I wrote it (both byte-compiled and interpreted).

I test by evaluating this in "emacs -Q":

    (defmacro future-interactive (arg-descriptor &rest modes)
      "Use the correct `interactive' form for any Emacs version.

    This is a forward compatibility macro that allows code providing
    the third argument to `interactive' (added in Emacs 28) to
    continue working on old versions of Emacs.

    To use it, replace `interactive' with `future-interactive'."
      (if (< emacs-major-version 28)
          `(interactive ,arg-descriptor)
        `(interactive ,arg-descriptor ,@modes)))

    (defun foo (arg)
      (future-interactive "P" fundamental-mode)
      (message "P was %s" arg))

And then I say `M-x foo RET'.  If `footnote-mode' is activated, the
macro did not work as expected, otherwise it did.

Bisecting points to c1ef7adeb649aa as the first commit that broke it.

Are you seeing the same thing?

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Monnier]

>>> Please find attached a patch.
>>
>> Hm...  trying this out now, I don't think the compat macro solution
>> actually works.  That is, it works fine when byte-compiled, but not in
>> non-compiled code.  The reason for this is that `interactive-form' just
>> does a `Fassq' on the Lisp form and looks for the Qinteractive symbol.
>> Which is won't find if the symbol in `future-interactive'.
>
> It is working for me in Emacs 27, and it was working for me at the time
> when I wrote it (both byte-compiled and interpreted).
>
> I test by evaluating this in "emacs -Q":

The key here is *how* you are "evaluating", since this will determine
whether eager-macroexpansion took place or not (if it did, the code
should work, but if it didn't, it probably won't).


        Stefan

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Please find attached a patch.
>>>
>>> Hm...  trying this out now, I don't think the compat macro solution
>>> actually works.  That is, it works fine when byte-compiled, but not in
>>> non-compiled code.  The reason for this is that `interactive-form' just
>>> does a `Fassq' on the Lisp form and looks for the Qinteractive symbol.
>>> Which is won't find if the symbol in `future-interactive'.
>>
>> It is working for me in Emacs 27, and it was working for me at the time
>> when I wrote it (both byte-compiled and interpreted).
>>
>> I test by evaluating this in "emacs -Q":
>
> The key here is *how* you are "evaluating", since this will determine
> whether eager-macroexpansion took place or not (if it did, the code
> should work, but if it didn't, it probably won't).

Sorry, I used `eval-defun' in the above test.

I quickly tried it with `load-file' on the uncompiled .el in Emacs 27,
and it also seems to work as expected.  Is there anything else I should
test in addition to that?

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> It is working for me in Emacs 27, and it was working for me at the time
> when I wrote it (both byte-compiled and interpreted).

You're absolutely right -- I wonder what's going on in my Emacs here.
Here's my test case:

(defun foo-command1 ()
  (future-interactive nil emacs-lisp-mode)
  (+ 1 2))

If I `C-M-x' (`eval-defun') on that in this Emacs, then:

(symbol-function 'foo-command1)
=> (lambda nil (future-interactive nil emacs-lisp-mode) (+ 1 2))

But if I start a fresh Emacs, then:

(symbol-function 'foo-command1)
=> (lambda nil (interactive nil emacs-lisp-mode) (+ 1 2))

which is what you're also seeing.

Stefan M says that macroexpansion happens differently with different
commands, which makes sense, but...  er...  what is making `eval-defun'
in this particular Emacs not macroexpand, while if I start a new one, it
will?  I guess I could have messed up some of the Emacs internals,
somehow?

Hm.  In any case, it looks like this was a false alarm, and your compat
macro works exactly as designed, both in Emacs 28 and in previous
versions.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan M says that macroexpansion happens differently with different
> commands, which makes sense, but...  er...  what is making `eval-defun'
> in this particular Emacs not macroexpand, while if I start a new one, it
> will?  I guess I could have messed up some of the Emacs internals,
> somehow?

Aha!

I've got a recipe to reproduce the problem:

./src/emacs -l /tmp/fut-int.elc -l edebug

(defun foo-command1 ()
  (future-interactive nil emacs-lisp-mode)
  (+ 1 2))

(symbol-function 'foo-command1)
=> (lambda nil (interactive nil emacs-lisp-mode) (+ 1 2))

That is, if edebug is loaded, then `C-M-x' (even if given no prefix)
stops macroexpanding the defun?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (symbol-function 'foo-command1)
> => (lambda nil (interactive nil emacs-lisp-mode) (+ 1 2))

I mean, it returns:

(lambda nil (future-interactive nil emacs-lisp-mode) (+ 1 2))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Monnier]

> That is, if edebug is loaded, then `C-M-x' (even if given no prefix)
> stops macroexpanding the defun?

Ah, looks like the code of `eval-defun` was upgraded to do
eager-macroexpansion, but Edebug overrides it and hasn't been similarly
upgraded (or better yet: improved so as to just use the normal code when
the code is not instrumented).


        Stefan

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Monnier]

>> That is, if edebug is loaded, then `C-M-x' (even if given no prefix)
>> stops macroexpanding the defun?
> Ah, looks like the code of `eval-defun` was upgraded to do
> eager-macroexpansion, but Edebug overrides it and hasn't been similarly
> upgraded (or better yet: improved so as to just use the normal code when
> the code is not instrumented).

I just installed a fix for that, which makes Edebug reuse the normal
`eval-defun` code.


        Stefan

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> That is, if edebug is loaded, then `C-M-x' (even if given no prefix)
>>> stops macroexpanding the defun?
>> Ah, looks like the code of `eval-defun` was upgraded to do
>> eager-macroexpansion, but Edebug overrides it and hasn't been similarly
>> upgraded (or better yet: improved so as to just use the normal code when
>> the code is not instrumented).
>
> I just installed a fix for that, which makes Edebug reuse the normal
> `eval-defun` code.

I think that commit causes 'make test/edebug-tests' to hang:

--8<---------------cut here---------------start------------->8---
make test/edebug-tests
make -C test edebug-tests
make[1]: Entering directory '/home/blc/.local/src/emacs/test'
make[2]: Entering directory '/home/blc/.local/src/emacs/test'
  GEN      lisp/emacs-lisp/edebug-tests.log
Running 43 tests (2021-02-18 16:34:55+0000, selector `(not (tag :unstable))')
Edebug: edebug-cl-defmethod-qualifier (number)
Edebug: edebug-cl-defmethod-qualifier :around (number)
   passed   1/43  edebug-cl-defmethod-qualifier (0.000698 sec)
Edebug: edebug-anon584
   passed   2/43  edebug-tests--&rest-behavior (0.000304 sec)
Edebug: f@cl-flet@585
Edebug: gate@cl-flet@586
Edebug: edebug-test-code-cl-flet1

   passed   3/43  edebug-tests--conflicting-internal-names (0.062670 sec)
Edebug: edebug-test-code-range






Go...
   passed   4/43  edebug-tests-backtrace-goto-source (0.220103 sec)
Edebug: edebug-anon651
Edebug: edebug-test-code-make-lambda

Breakpoint set in edebug-anon651
Edebug: edebug-test-code-use-lambda


Go...
Break
Result: 1 (#o1, #x1, ?\C-a)
Go...
   passed   5/43  edebug-tests-break-in-lambda-out-of-defining-context (0.038740 sec)
   passed   6/43  edebug-tests-check-keymap (0.000361 sec)
Edebug: edebug-test-code-circular-read-syntax

   passed   7/43  edebug-tests-circular-read-syntax (0.015725 sec)
Edebug: inner@cl-flet@10000
Edebug: inner@cl-flet@10001
Edebug: edebug-tests-cl-flet-1
Edebug: inner@cl-flet@10002
Edebug: edebug-tests-cl-flet-2
   passed   8/43  edebug-tests-cl-flet (0.001139 sec)
Edebug: wrap@cl-macrolet@654
Edebug: edebug-test-code-use-cl-macrolet
--8<---------------cut here---------------end--------------->8---

0. ./src/emacs -Q
1. M-x load-file RET test/lisp/emacs-lisp/edebug-tests.elc RET
2. M-x ert RET RET

This starts an Edebug session in edebug-test-code-use-cl-macrolet:


[-- Attachment #2: 2021-02-18-164332_642x109_scrot.png --]
[-- Type: image/png, Size: 210456 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1035 bytes --]


3. g

--8<---------------cut here---------------start------------->8---
F edebug-tests-break-in-lambda-out-of-defining-context
    Edebug observes a breakpoint in a lambda executed out of defining context.
    (buffer-read-only #<killed buffer>)

F edebug-tests-cl-macrolet
    Edebug can instrument ‘cl-macrolet’ expressions. (Bug#29919)
    (ert-test-failed
     ((should
       (eql
	(point)
	stop-point))
      :form
      (eql 4205 4129)
      :value nil))

F edebug-tests-trivial-backquote
    Edebug can instrument a trivial backquote expression (Bug#23651).
    (ert-test-failed
     ((should
       (string-match-p
	(regexp-quote "1 (#o1, #x1, ?\\C-a)")
	edebug-tests-messages))
      :form
      (string-match-p "1 (#o1, #x1, \\?\\\\C-a)" " (#o1, #x1, ?\\C-a)")
      :value nil))
--8<---------------cut here---------------end--------------->8---

Same happens if I load the source file edebug-tests.el instead.

The hang doesn't happen with the preceding commit.

HTH,

-- 
Basil

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Rolf Ade]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> I think that in the long term, taking care to not make simple things
>> >> like making a command for a mode too arduous, is important.
>> >
>> > I don't think using 'declare' or a plist can be characterized as
>> > "arduous".
>> 
>> I think it is.  We'd be demanding that people learn about obscure things
>> like `declare' just to write a little mode.  That's not good language
>> design.
>
> Neither 'declare' nor 'plist' are obscure.  We use them all over the
> place.  So we will have to agree to disagree about this.

Sure, not obscure. Almost everyone able to write a little mode can look
it up with a few keystrokes, will maybe remember having seen some of the
things mentioned in info node (elisp)Declare Form and all.

To core developers this commands are of course familiar. Not necessarily
for others which are nevertheless able to write a little mode (even if
useful only for themself).

Using declare for adding the feature raises the amount of what I have to
remeber or lookup a little bit if I want to write another little mode.

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Once again, let's avoid making this discussion too ad-hominem.

Hear, hear.

Alan (and anyone else), if you think person A is speaking
disrespectfully to person B, it can be useful to take some action, but
please take care in the way you do it.  Criticizing a person's words
in this way has a tendency to hurt feelings, so we should try to be
extra kind when we say such a thing.

A good first approach is to say privately to A that per words to B
feel disrespectful to you.

I suggest rereading https://gnu.org/philosophy/kind-communication.html
before you write them, and citing those Kind Communication Guidelines
in what you send.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I just installed a fix for that, which makes Edebug reuse the normal
> `eval-defun` code.

Great!  And I can confirm that `C-M-x' in Emacs 28 works fine now in
this use case.

(defun foo-command1 ()
  (future-interactive nil emacs-lisp-mode)
  (+ 1 2))

(symbol-function 'foo-command1)
=> (lambda nil (interactive nil emacs-lisp-mode) (+ 1 2))

However, `C-u C-M-x' gives us:

(symbol-function 'foo-command1)
=> (lambda nil (edebug-enter 'foo-command1 (list) #'(lambda nil (edebug-after (edebug-before 0) 1 (interactive nil emacs-lisp-mode)) (edebug-after (edebug-before 2) 3 (+ 1 2)))))

Note the placement of the `interactive' form -- so this isn't a command
now.  Compare with a non-macro `interactive':

(defun foo-command2 ()
  (interactive nil emacs-lisp-mode)
  (+ 1 2))

(symbol-function 'foo-command2)
=> (lambda nil (interactive) (edebug-enter 'foo-command2 (list) #'(lambda nil (edebug-after (edebug-before 0) 1 (+ 1 2)))))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Monnier]

> However, `C-u C-M-x' gives us:
>
> (symbol-function 'foo-command1)
> => (lambda nil (edebug-enter 'foo-command1 (list) #'(lambda nil
> (edebug-after (edebug-before 0) 1 (interactive nil emacs-lisp-mode))
> (edebug-after (edebug-before 2) 3 (+ 1 2)))))

Yes, I did mention that earlier in the thread.

You'll need to adjust the Edebug specs of `defun` (there are probably
other ways, of course) if you want to fix that.


        Stefan

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You'll need to adjust the Edebug specs of `defun` (there are probably
> other ways, of course) if you want to fix that.

You mean add "future-interactive" as an alternative in the spec?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Stefan Monnier]

>> You'll need to adjust the Edebug specs of `defun` (there are probably
>> other ways, of course) if you want to fix that.
> You mean add "future-interactive" as an alternative in the spec?

Yup: the spec is all about instrumenting the source code as-is (before
macro-expansion).


        Stefan

Re: scratch/command 064f146 1/2: Change command to interactive ... modes

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> You'll need to adjust the Edebug specs of `defun` (there are probably
>>> other ways, of course) if you want to fix that.
>> You mean add "future-interactive" as an alternative in the spec?
>
> Yup: the spec is all about instrumenting the source code as-is (before
> macro-expansion).

OK, so if we do include future-interactive as a core GNU ELPA package,
then the following 100% guaranteed untested patch should make this work
in Emacs 28.

diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index 45e76c751f..8a5960bb28 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -2088,7 +2088,8 @@ edebug-match-def-body
        ;; more convenient to define their Edebug spec here.
        (defun ( &define name lambda-list lambda-doc
 	        [&optional ("declare" def-declarations)]
-	        [&optional ("interactive" &optional [&or stringp def-form]
+	        [&optional ([&or "interactive" "future-interactive"]
+                            &optional [&or stringp def-form]
                             &rest symbolp)]
 	        def-body))
 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no