bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi,

AFAIU we must update this test in `edebug--called-interactively-skip':

#+begin_src emacs-lisp
  (when (and (memq (car-safe (nth 1 frame1)) '(lambda closure)) ...
#+end_src


My test case:

#+begin_src emacs-lisp
(defun f (x)
  (interactive "P")
  (message "c-i: %s" (called-interactively-p 'any)))
(global-set-key [print] #'f)
#+end_src

When edebugging `f', (called-interactively-p 'any) will eval to nil in
current master when hitting print.  Evalled to t as expected in older
Emacs versions.


TIA,

Michael.

bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> AFAIU we must update this test in `edebug--called-interactively-skip':
>
> #+begin_src emacs-lisp
>   (when (and (memq (car-safe (nth 1 frame1)) '(lambda closure)) ...
> #+end_src

Indeed, thanks!


        Stefan

bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> AFAIU we must update this test in `edebug--called-interactively-skip':
>>
>> #+begin_src emacs-lisp
>>   (when (and (memq (car-safe (nth 1 frame1)) '(lambda closure)) ...
>> #+end_src

I pushed a patch to `emacs-30` which should fix this.
Can you confirm it fixes it in your real use case as well?


        Stefan

bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> I pushed a patch to `emacs-30` which should fix this.
> Can you confirm it fixes it in your real use case as well?

Thanks.  Other use cases are fixed as well - but advices are broken :-(

#+begin_src emacs-lisp
(defun f (x)
  (interactive "P")
  (message "c-i: %s" (called-interactively-p 'any)))

(advice-add 'f :around (defun my-f--around-ad (f &rest args) (apply f args)))

(global-set-key [print] #'f)
#+end_src

Hitting [print] says nil.  AFAIU this should also work transparently,
right?  The breakage seems to date further back in this case.


And i have another request: could you please search for the few other
occurrences of the symbol 'closure' in the Emacs Elisp code base?  I
guess in most cases there is a need to update these places, too.


Regards,

Michael.

bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> I pushed a patch to `emacs-30` which should fix this.
>> Can you confirm it fixes it in your real use case as well?
> Thanks.  Other use cases are fixed as well

Thank you, closing.

>  but advices are broken :-(
[...]
> (advice-add 'f :around (defun my-f--around-ad (f &rest args) (apply f args)))

AFAIK that's not new.

> Hitting [print] says nil.  AFAIU this should also work transparently,
> right?  The breakage seems to date further back in this case.

It should work for most advices but not for `:around` advice, because
fundamentally, it's virtually impossible to recognize this

    (apply f args)

as being an "interactive call".

> And i have another request: could you please search for the few other
> occurrences of the symbol 'closure' in the Emacs Elisp code base?
> I guess in most cases there is a need to update these places, too.

I already did.
There's one case on `comp.el` which may require some update, but I don't
understand the code enough to know what it intends to do.
It seems to match both `lambda` and `closure`, hence function *values*,
but somehow it doesn't try and handle byte-code functions which are far
more common function values, so maybe the `closure` is just irrelevant
and the code is expected to match source code expressions (whose
evaluation will return functions)?


        Stefan

bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> I already did.

What about `which-key--get-keymap-bindings-1'?


For this one I CC Alan M.:

> There's one case on `comp.el` which may require some update

Yes, that's more or less the only other one I found:
`comp--spill-lap-function'.  Alan, we are discussing how relevant the
code in that function is that checks for lambda and closure cars, and if
it must be updated to handle the new interpreted function objects.

> but I don't understand the code enough to know what it intends to
> do.  It seems to match both `lambda` and `closure`, hence function
> *values*, but somehow it doesn't try and handle byte-code functions
> which are far more common function values, so maybe the `closure` is
> just irrelevant and the code is expected to match source code
> expressions (whose evaluation will return functions)?

Dunno.  `comp-trampoline-compile' constructs a lambda form to compile.
But never a "closure form".  So maybe irrelevant to check for 'closure'
indeed.

Alan had added the 'closure' symbol in

06e4ebc81a4 "With `native-compile', compile lambdas in a defun or lambda too"

which seems had been a fix for bug#64646 "Master: Native compiler
doesn't always compile lambda".  Guess this bug report is also an answer
to Stefan's question.



Michael.

bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Eli Zaretskii]

> Cc: 71934-done@debbugs.gnu.org, Alan Mackenzie <acm@muc.de>
> Date: Fri, 05 Jul 2024 07:06:44 +0200
> From:  Michael Heerdegen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > I already did.
> 
> What about `which-key--get-keymap-bindings-1'?
> 
> 
> For this one I CC Alan M.:
> 
> > There's one case on `comp.el` which may require some update
> 
> Yes, that's more or less the only other one I found:
> `comp--spill-lap-function'.  Alan, we are discussing how relevant the
> code in that function is that checks for lambda and closure cars, and if
> it must be updated to handle the new interpreted function objects.
> 
> > but I don't understand the code enough to know what it intends to
> > do.  It seems to match both `lambda` and `closure`, hence function
> > *values*, but somehow it doesn't try and handle byte-code functions
> > which are far more common function values, so maybe the `closure` is
> > just irrelevant and the code is expected to match source code
> > expressions (whose evaluation will return functions)?
> 
> Dunno.  `comp-trampoline-compile' constructs a lambda form to compile.
> But never a "closure form".  So maybe irrelevant to check for 'closure'
> indeed.
> 
> Alan had added the 'closure' symbol in
> 
> 06e4ebc81a4 "With `native-compile', compile lambdas in a defun or lambda too"
> 
> which seems had been a fix for bug#64646 "Master: Native compiler
> doesn't always compile lambda".  Guess this bug report is also an answer
> to Stefan's question.

Andrea, can you take a look at this, please?

bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 71934-done@debbugs.gnu.org, Alan Mackenzie <acm@muc.de>
>> Date: Fri, 05 Jul 2024 07:06:44 +0200
>> From:  Michael Heerdegen via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 
>> > I already did.
>> 
>> What about `which-key--get-keymap-bindings-1'?
>> 
>> 
>> For this one I CC Alan M.:
>> 
>> > There's one case on `comp.el` which may require some update
>> 
>> Yes, that's more or less the only other one I found:
>> `comp--spill-lap-function'.  Alan, we are discussing how relevant the
>> code in that function is that checks for lambda and closure cars, and if
>> it must be updated to handle the new interpreted function objects.
>> 
>> > but I don't understand the code enough to know what it intends to
>> > do.  It seems to match both `lambda` and `closure`, hence function
>> > *values*, but somehow it doesn't try and handle byte-code functions
>> > which are far more common function values, so maybe the `closure` is
>> > just irrelevant and the code is expected to match source code
>> > expressions (whose evaluation will return functions)?
>> 
>> Dunno.  `comp-trampoline-compile' constructs a lambda form to compile.
>> But never a "closure form".  So maybe irrelevant to check for 'closure'
>> indeed.
>> 
>> Alan had added the 'closure' symbol in
>> 
>> 06e4ebc81a4 "With `native-compile', compile lambdas in a defun or lambda too"
>> 
>> which seems had been a fix for bug#64646 "Master: Native compiler
>> doesn't always compile lambda".  Guess this bug report is also an answer
>> to Stefan's question.
>
> Andrea, can you take a look at this, please?

Yep, I believe that code does not require to be changed, the input of
comp--spill-lap-function is a form not an interpred function.

  Andrea

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Alan Mackenzie]

Hello, Stefan.

On Fri, Jul 05, 2024 at 11:48:10 -0400, Stefan Monnier wrote:
> >> >> Andrea, can you take a look at this, please?
> >> > Yep, I believe that code does not require to be changed, the input of
> >> > comp--spill-lap-function is a form not an interpred function.
> >> But then why does it check for `closure`?
> > Back in 2023, one of the forms this function found itself unable to
> > compile was a closure.  So I fixed this for bug #64646.

> But there is no such thing as a *form* that looks like
> (closure ...), so if we found such a thing either it was a bug or it
> means that other function values like byte-code (or the new
> `interpreted-function`s) could appear there and should arguably be
> handled as well.

Not sure what you mean by "no such thing as a form ... like a closure".
I bumped into one last summer.

In particular (in my development repo fixing bug #64646) I put this into
*scratch*:

    (defconst foo (lambda (baz) (car baz)))

, evaluated it with C-x C-e and then M-: (native-compile foo).  This
threw the error "Cannot native-compile, form is not a lambda".

The value of foo had been turned into a form (closure ....).  So I fixed
comp--spill-lap-function (form version) so as to compile that form.

I've no idea how Emacs would handle that defconst now.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Not sure what you mean by "no such thing as a form ... like a closure".

A form that starts with `closure` is not a valid form because there is
no definition for `closure`: (fboundp 'closure) => nil.

> I bumped into one last summer.
>
> In particular (in my development repo fixing bug #64646) I put this into
> *scratch*:
>
>     (defconst foo (lambda (baz) (car baz)))
>
> , evaluated it with C-x C-e and then M-: (native-compile foo).  This
> threw the error "Cannot native-compile, form is not a lambda".

That error seems right according to the docstring:

   (defun native-compile (function-or-file &optional output)
     "Compile FUNCTION-OR-FILE into native code.
   This is the synchronous entry-point for the Emacs Lisp native
   compiler.  FUNCTION-OR-FILE is a function symbol, a form, or the
   filename of an Emacs Lisp source file.  If OUTPUT is non-nil, use
   it as the filename for the compiled object.  If FUNCTION-OR-FILE
   is a filename, if the compilation was successful return the
   filename of the compiled object.  If FUNCTION-OR-FILE is a
   function symbol or a form, if the compilation was successful
   return the compiled function."

(closure ...) is not a function symbol nor a valid form.  Instead it's
a function value and the docstring doesn't say such are
a valid arguments to `native-compile`.

Admittedly, maybe we should extend `native-compile` to accept function
values, just like `byte-compile`.

> The value of foo had been turned into a form (closure ....).

No, "form" is a specific term which denotes a piece of source code (I
usually used the term "expression" for that, but IIUC in the Lisp world
the more common term for that is "form").

(closure ....) is not a *form* code any more than (1 foo) or (+ . 4)
[ except to the extent that we *could* make it into a valid form by
  providing a definition for `closure` (as a macro, function, or
  special form).  ]

> So I fixed
> comp--spill-lap-function (form version) so as to compile that form.

Why `comp--spill-lap-function` specifically (instead of
`native-compile`, for example)?

> I've no idea how Emacs would handle that defconst now.

Hmm... AFAICT your example doesn't relate to `defconst`.
You'd get the same result with

    M-: (native-compile (lambda (baz) (car baz))) RET


- Stefan

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Alan Mackenzie]

Hello, Stefan.

On Fri, Jul 05, 2024 at 14:17:38 -0400, Stefan Monnier wrote:
> > Not sure what you mean by "no such thing as a form ... like a closure".

> A form that starts with `closure` is not a valid form because there is
> no definition for `closure`: (fboundp 'closure) => nil.

> > I bumped into one last summer.

> > In particular (in my development repo fixing bug #64646) I put this into
> > *scratch*:

> >     (defconst foo (lambda (baz) (car baz)))

> > , evaluated it with C-x C-e and then M-: (native-compile foo).  This
> > threw the error "Cannot native-compile, form is not a lambda".

> That error seems right according to the docstring:

>    (defun native-compile (function-or-file &optional output)
>      "Compile FUNCTION-OR-FILE into native code.
>    This is the synchronous entry-point for the Emacs Lisp native
>    compiler.  FUNCTION-OR-FILE is a function symbol, a form, or the
>    filename of an Emacs Lisp source file.  If OUTPUT is non-nil, use
>    it as the filename for the compiled object.  If FUNCTION-OR-FILE
>    is a filename, if the compilation was successful return the
>    filename of the compiled object.  If FUNCTION-OR-FILE is a
>    function symbol or a form, if the compilation was successful
>    return the compiled function."

> (closure ...) is not a function symbol nor a valid form.  Instead it's
> a function value and the docstring doesn't say such are
> a valid arguments to `native-compile`.

All very clever arguments, no doubt, but in the end it means you cannot
native compile foo.  I've just tried it on emacs-30, and it doesn't work.
But you could compile foo last summer after my fixes for bug #64646.
Between last summer and now, something has gone badly wrong in Emacs's
basic mechanisms.

> Admittedly, maybe we should extend `native-compile` to accept function
> values, just like `byte-compile`.

Or something like that, yes.  But if logical combinations of terms like
"form", "closure", "function value", "valid form" lead to not being able
to compile foo, then I suggest that these terms and their applicability
might need to be thought through somewhat.

[ .... ]

> > So I fixed
> > comp--spill-lap-function (form version) so as to compile that form.

> Why `comp--spill-lap-function` specifically (instead of
> `native-compile`, for example)?

I fixed what was wrong at the time.

> > I've no idea how Emacs would handle that defconst now.

> Hmm... AFAICT your example doesn't relate to `defconst`.
> You'd get the same result with

>     M-: (native-compile (lambda (baz) (car baz))) RET

Whatever.  foo doesn't compile; that should be fixed.

> - Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> (closure ...) is not a function symbol nor a valid form.  Instead it's
>> a function value and the docstring doesn't say such are
>> a valid arguments to `native-compile`.
>
> All very clever arguments, no doubt, but in the end it means you cannot
> native compile foo.

To obey the docstring, if you want to compile a function whose value is
stored in the variable `foo` you can do:

    (let ((sym (gensym)))
      (fset sym foo)
      (native-compile sym))

It's admittedly not the most convenient, which is why `byte-compile`
(in contrast to `native-compile`) accepts function values in addition to
forms and function symbols.

> I've just tried it on emacs-30, and it doesn't work.

As it is allowed to, according to its docstring.

> But you could compile foo last summer after my fixes for bug #64646.

[ But that still failed to make it work for byte-compiled function values,
  and it failed to update the docstring to announce that new behavior.  ]

>> Admittedly, maybe we should extend `native-compile` to accept function
>> values, just like `byte-compile`.
> Or something like that, yes.  But if logical combinations of terms like
> "form", "closure", "function value", "valid form" lead to not being able
> to compile foo, then I suggest that these terms and their applicability
> might need to be thought through somewhat.

Don't worry: they've been thought through aplenty.

>>> So I fixed comp--spill-lap-function (form version) so as to compile
>>> that form.
>> Why `comp--spill-lap-function` specifically (instead of
>> `native-compile`, for example)?
> I fixed what was wrong at the time.

I'd like to implement the feature of `native-compile` accepting function
values correctly rather than in the most expedient way.  If you could
try to remember why you fixed it in this specific way, that would be
very helpful, because I'm not sufficiently familiar with the code of
`comp--spill-lap-function` to be sure of what I'm doing.

>> > I've no idea how Emacs would handle that defconst now.
>> Hmm... AFAICT your example doesn't relate to `defconst`.
>> You'd get the same result with
>>     M-: (native-compile (lambda (baz) (car baz))) RET
> Whatever.  foo doesn't compile; that should be fixed.

All I'm saying is that it's a feature request, rather than a bug to
be fixed.


        Stefan

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Alan Mackenzie]

Hello, Stefan.

On Fri, Jul 05, 2024 at 16:26:02 -0400, Stefan Monnier wrote:
> >> (closure ...) is not a function symbol nor a valid form.  Instead it's
> >> a function value and the docstring doesn't say such are
> >> a valid arguments to `native-compile`.

> > All very clever arguments, no doubt, but in the end it means you cannot
> > native compile foo.

> To obey the docstring, ....

Forget that doc string, just do what is right, expected, and convenient
for Emacs users, and adjust the doc string afterwards.

> > I've just tried it on emacs-30, and it doesn't work.

> As it is allowed to, according to its docstring.

Forget that doc string.  It belongs to lawyers, not reality.

> > But you could compile foo last summer after my fixes for bug #64646.

> [ But that still failed to make it work for byte-compiled function values,
>   and it failed to update the docstring to announce that new behavior.  ]

That is a strawman.  You have never been able to compile from
byte-compiled code to native compiled code, and never will (unless
Andrea has anything new to the contrary to say).  

The point is being able to compile foo, from read source code.  You
don't want to be able to do this for reasons I can't fathom.

> >> Admittedly, maybe we should extend `native-compile` to accept function
> >> values, just like `byte-compile`.
> > Or something like that, yes.  But if logical combinations of terms like
> > "form", "closure", "function value", "valid form" lead to not being able
> > to compile foo, then I suggest that these terms and their applicability
> > might need to be thought through somewhat.

> Don't worry: they've been thought through aplenty.

Clearly not.  The confusion they're apparently causing is affecting Emacs.

> >>> So I fixed comp--spill-lap-function (form version) so as to compile
> >>> that form.
> >> Why `comp--spill-lap-function` specifically (instead of
> >> `native-compile`, for example)?
> > I fixed what was wrong at the time.

> I'd like to implement the feature of `native-compile` accepting function
> values correctly rather than in the most expedient way.  If you could
> try to remember why you fixed it in this specific way, ....

I have no records of my reasons.  Having diagnosed the problem, it was
not difficult to fix.  I just fixed it in the simplest, most obvious,
and most obviously correct way.

> .... that would be very helpful, because I'm not sufficiently familiar
> with the code of `comp--spill-lap-function` to be sure of what I'm
> doing.

> >> > I've no idea how Emacs would handle that defconst now.
> >> Hmm... AFAICT your example doesn't relate to `defconst`.
> >> You'd get the same result with
> >>     M-: (native-compile (lambda (baz) (car baz))) RET
> > Whatever.  foo doesn't compile; that should be fixed.

> All I'm saying is that it's a feature request, rather than a bug to
> be fixed.

Functionality has been lost.  Finding an excuse in the exact meaning of
words rarely used with such precision is not a way to restore that
functionality.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Alan Mackenzie <acm@muc.de> writes:

> > > All very clever arguments, no doubt, but in the end it means you
> > > cannot native compile foo.
>
> > To obey the docstring, ....
>
> Forget that doc string, just do what is right, expected, and convenient
> for Emacs users, and adjust the doc string afterwards.

We are actually trying to do that, but we don't understand the code
because of the lacking or wrong documentation.

Maybe we already had introduced a regression because of that.  And now
three people try to guess what the code does.  Our time is also
valuable, Alan.  This documentation is important.

Michael.

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Andrea Corallo
>  <acorallo@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,  71934@debbugs.gnu.org
> Date: Sat, 06 Jul 2024 03:06:24 +0200
> 
> Alan Mackenzie <acm@muc.de> writes:
> 
> > > > All very clever arguments, no doubt, but in the end it means you
> > > > cannot native compile foo.
> >
> > > To obey the docstring, ....
> >
> > Forget that doc string, just do what is right, expected, and convenient
> > for Emacs users, and adjust the doc string afterwards.
> 
> We are actually trying to do that, but we don't understand the code
> because of the lacking or wrong documentation.

I don't understand this difficulty.  Andrea, who wrote that function
(and everything around it) is here, and is very helpful.  How come
this lack of understanding, let alone lack of documentation, is still
with us?

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Heerdegen <michael_heerdegen@web.de>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Andrea Corallo
>>  <acorallo@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,  71934@debbugs.gnu.org
>> Date: Sat, 06 Jul 2024 03:06:24 +0200
>> 
>> Alan Mackenzie <acm@muc.de> writes:
>> 
>> > > > All very clever arguments, no doubt, but in the end it means you
>> > > > cannot native compile foo.
>> >
>> > > To obey the docstring, ....
>> >
>> > Forget that doc string, just do what is right, expected, and convenient
>> > for Emacs users, and adjust the doc string afterwards.
>> 
>> We are actually trying to do that, but we don't understand the code
>> because of the lacking or wrong documentation.
>
> I don't understand this difficulty.  Andrea, who wrote that function
> (and everything around it) is here, and is very helpful.  How come
> this lack of understanding, let alone lack of documentation, is still
> with us?

Must say I'm really lost in this thread.

First I don't understand the functionality that got lost.

Second the method "comp-spill-lap-function ((form list))" never served the
case (native-compile 'foo) but rather (native-compile '(lambda () 3)).

(Now if the form (closure () 3) does not exist in elisp as valid form
this might translate in 1 line fix in 'comp-spill-lap-function ((form
list))' but let discuss this aside and is not about a lost
functionality).

(native-compile 'foo) is served by 'comp--spill-lap-function ((function-name symbol))'.

Also:

(native-compile 'foo) works (as always did) and even what Alan added
(native compiling lambdas in function native compiled by symbol name)
that is:

(defun foo () "foo doc string"
       (lambda () "lambda doc string" 3))

(subr-native-elisp-p (funcall (native-compile 'foo)))

Still works for me on master.

So I must be really missing something in this discussion.

Let us please stick to exactly what worked in which version and what
does not in which other version, if we identify a case will be easy to
fix.

And even more importantly, I'll make sure we have a test that covers
that case so we can't have any other regression (assuming we had one).

Thanks

  Andrea

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Alan Mackenzie]

Hello, Michael.

On Sat, Jul 06, 2024 at 03:06:24 +0200, Michael Heerdegen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > > > All very clever arguments, no doubt, but in the end it means you
> > > > cannot native compile foo.

> > > To obey the docstring, ....

> > Forget that doc string, just do what is right, expected, and convenient
> > for Emacs users, and adjust the doc string afterwards.

> We are actually trying to do that, but we don't understand the code
> because of the lacking or wrong documentation.

Would that code be comp--spill-lap-function, perhaps?  There are
currently three functions with that name, each for a different type of
argument.

It's apparent that the one that used to work,

    (cl-defmethod comp--spill-lap-function ((form list))                                                                   

, no longer works since function forms were converted to a different
format in March.  It needs modifying to handle the new format.

> Maybe we already had introduced a regression because of that.  And now
> three people try to guess what the code does.  Our time is also
> valuable, Alan.  This documentation is important.

I don't really see where the problem is: comp--spill-lap-function, all
versions, isolates the Lisp source form, passes it to the byte compiler
and receives the intermediate compiled form in the hash table
byte-to-native-lambdas-h.  This intermediate form is then fed to the
native compilation engine.

Or am I not understanding what you're asking?

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Alan Mackenzie <acm@muc.de> writes:

> It's apparent that the one that used to work,
>
>     (cl-defmethod comp--spill-lap-function ((form list))
>
> , no longer works since function forms were converted to a different
> format in March.  It needs modifying to handle the new format.

That was the question.

So, of what kind can the argument FORM be?  Any form (any lisp
expression - any kind of "code") - lambda lists, function values?

As far as I understand the above method originally supported lambda
lists and you made it handle function values as well.  And because
function values are now represented differently the above method does
not handle this case any more.

Is this correct?


Thx,

Michael.

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> It's apparent that the one that used to work,
>>
>>     (cl-defmethod comp--spill-lap-function ((form list))
>>
>> , no longer works since function forms were converted to a different
>> format in March.  It needs modifying to handle the new format.
>
> That was the question.
>
> So, of what kind can the argument FORM be?  Any form (any lisp
> expression - any kind of "code") - lambda lists, function values?
>
> As far as I understand the above method originally supported lambda
> lists and you made it handle function values as well.  And because
> function values are now represented differently the above method does
> not handle this case any more.
>
> Is this correct?

Yeah, I also fail to understand the relationship between
`comp--spill-lap-function` (which sounds internal to the compilation
pipeline and thus might apply to all sorts of subexpressions of the
input code) and `native-compile` (where adding support for function
values affects only the "toplevel" of the input).


        Stefan

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Andrea Corallo]

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

>>> It's apparent that the one that used to work,
>>>
>>>     (cl-defmethod comp--spill-lap-function ((form list))
>>>
>>> , no longer works since function forms were converted to a different
>>> format in March.  It needs modifying to handle the new format.
>>
>> That was the question.
>>
>> So, of what kind can the argument FORM be?  Any form (any lisp
>> expression - any kind of "code") - lambda lists, function values?
>>
>> As far as I understand the above method originally supported lambda
>> lists and you made it handle function values as well.  And because
>> function values are now represented differently the above method does
>> not handle this case any more.
>>
>> Is this correct?
>
> Yeah, I also fail to understand the relationship between
> `comp--spill-lap-function` (which sounds internal to the compilation
> pipeline and thus might apply to all sorts of subexpressions of the
> input code) and `native-compile` (where adding support for function
> values affects only the "toplevel" of the input).

'comp--spill-lap-function' serves 'comp--spill-lap' which is the first
pass of the native compilation pipeline.  So adding a new method there
is the usual way to make native-compile support new kind of inputs.

  Andrea

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Alan Mackenzie]

Hello, Michael.

On Mon, Jul 08, 2024 at 03:35:16 +0200, Michael Heerdegen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > It's apparent that the one that used to work,

> >     (cl-defmethod comp--spill-lap-function ((form list))

> > , no longer works since function forms were converted to a different
> > format in March.  It needs modifying to handle the new format.

> That was the question.

> So, of what kind can the argument FORM be?  Any form (any lisp
> expression - any kind of "code") - lambda lists, function values?

I'm not entirely sure what you mean by "function value".  Before March,
that method handled lists whose car was either lambda or closure.  It
likely still does.

> As far as I understand the above method originally supported lambda
> lists and you made it handle function values as well.

I made it handle lists with a car of closure.

> And because function values are now represented differently the above
> method does not handle this case any more.

> Is this correct?

I think so, yes.  It would appear we need a new version of
comp--spill-lap-function to handle the new format of functions.

> Thx,

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Alan Mackenzie <acm@muc.de> writes:

> I'm not entirely sure what you mean by "function value".

A form is code, an expression, something that can be evaluated.

A value is the result of an evaluation.  A "function value" is a value
that can be funcalled.

The signature (cl-defmethod comp--spill-lap-function ((form list)) ...)
lets the reader think the argument is always a form.  This is why Stefan
missed this occurrence.  You made it handle function values as well.

Although in Lisp forms and values are both objects, or values so to say,
it makes sense to write code in a way that lets the reader see whether
arguments are expressions or not, because else everything soon gets
confusing, as we see here.

And I really have not to say anything about the matter.  I only wanted
to get the thing started.

Michael.

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Stefan.
>
> On Fri, Jul 05, 2024 at 14:17:38 -0400, Stefan Monnier wrote:
>> > Not sure what you mean by "no such thing as a form ... like a closure".
>
>> A form that starts with `closure` is not a valid form because there is
>> no definition for `closure`: (fboundp 'closure) => nil.
>
>> > I bumped into one last summer.
>
>> > In particular (in my development repo fixing bug #64646) I put this into
>> > *scratch*:
>
>> >     (defconst foo (lambda (baz) (car baz)))
>
>> > , evaluated it with C-x C-e and then M-: (native-compile foo).  This
>> > threw the error "Cannot native-compile, form is not a lambda".
>
>> That error seems right according to the docstring:
>
>>    (defun native-compile (function-or-file &optional output)
>>      "Compile FUNCTION-OR-FILE into native code.
>>    This is the synchronous entry-point for the Emacs Lisp native
>>    compiler.  FUNCTION-OR-FILE is a function symbol, a form, or the
>>    filename of an Emacs Lisp source file.  If OUTPUT is non-nil, use
>>    it as the filename for the compiled object.  If FUNCTION-OR-FILE
>>    is a filename, if the compilation was successful return the
>>    filename of the compiled object.  If FUNCTION-OR-FILE is a
>>    function symbol or a form, if the compilation was successful
>>    return the compiled function."
>
>> (closure ...) is not a function symbol nor a valid form.  Instead it's
>> a function value and the docstring doesn't say such are
>> a valid arguments to `native-compile`.
>
> All very clever arguments, no doubt, but in the end it means you cannot
> native compile foo.  I've just tried it on emacs-30, and it doesn't work.
> But you could compile foo last summer after my fixes for bug #64646.
> Between last summer and now, something has gone badly wrong in Emacs's
> basic mechanisms.

(defconst foo (lambda (baz) (car baz)))                                                                                                                                           
(native-compile #'foo)

Never worked AFAIR, the functionality you added was:

(defun foo () "foo doc string"
       (lambda () "lambda doc string" 3))

(subr-native-elisp-p (funcall (native-compile 'foo)))

And this still works for me.

I'm probably missing something sorry.

  Andrea

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Alan Mackenzie]

Hello, Andrea.

On Sat, Jul 06, 2024 at 03:48:50 -0400, Andrea Corallo wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Stefan.

> > On Fri, Jul 05, 2024 at 14:17:38 -0400, Stefan Monnier wrote:
> >> > Not sure what you mean by "no such thing as a form ... like a closure".

> >> A form that starts with `closure` is not a valid form because there is
> >> no definition for `closure`: (fboundp 'closure) => nil.

> >> > I bumped into one last summer.

> >> > In particular (in my development repo fixing bug #64646) I put this into
> >> > *scratch*:

> >> >     (defconst foo (lambda (baz) (car baz)))

> >> > , evaluated it with C-x C-e and then M-: (native-compile foo).  This
> >> > threw the error "Cannot native-compile, form is not a lambda".

> >> That error seems right according to the docstring:

> >>    (defun native-compile (function-or-file &optional output)
> >>      "Compile FUNCTION-OR-FILE into native code.
> >>    This is the synchronous entry-point for the Emacs Lisp native
> >>    compiler.  FUNCTION-OR-FILE is a function symbol, a form, or the
> >>    filename of an Emacs Lisp source file.  If OUTPUT is non-nil, use
> >>    it as the filename for the compiled object.  If FUNCTION-OR-FILE
> >>    is a filename, if the compilation was successful return the
> >>    filename of the compiled object.  If FUNCTION-OR-FILE is a
> >>    function symbol or a form, if the compilation was successful
> >>    return the compiled function."

> >> (closure ...) is not a function symbol nor a valid form.  Instead it's
> >> a function value and the docstring doesn't say such are
> >> a valid arguments to `native-compile`.

> > All very clever arguments, no doubt, but in the end it means you cannot
> > native compile foo.  I've just tried it on emacs-30, and it doesn't work.
> > But you could compile foo last summer after my fixes for bug #64646.
> > Between last summer and now, something has gone badly wrong in Emacs's
> > basic mechanisms.

> (defconst foo (lambda (baz) (car baz)))                                                                                                                                           
> (native-compile #'foo)

> Never worked AFAIR, ....

No.  But (native-compile foo) did work.  It compiled the value of foo,
producing an anonymous subr.

> ....the functionality you added was:

> (defun foo () "foo doc string"
>        (lambda () "lambda doc string" 3))

> (subr-native-elisp-p (funcall (native-compile 'foo)))

Yes.

> And this still works for me.

It still works for me, too.

> I'm probably missing something sorry.

The fact that

	(defconst foo (lambda (baz) (car baz)))
	(native-compile foo)

worked (as of 2023-11-08), but no longer does.  It was not the main topic
of bug #64646 (for which see above), but was fixed in the commit for that
bug anyway.  This was possibly not a good idea.  That commit was:

commit 06e4ebc81a44c709b08ce72c746629c6c77e6f6e
Author: Alan Mackenzie <acm@muc.de>
Date:   Wed Nov 8 20:49:48 2023 +0000

    With `native-compile', compile lambdas in a defun or lambda too

..

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrea.
>
> On Sat, Jul 06, 2024 at 03:48:50 -0400, Andrea Corallo wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > Hello, Stefan.
>
>> > On Fri, Jul 05, 2024 at 14:17:38 -0400, Stefan Monnier wrote:
>> >> > Not sure what you mean by "no such thing as a form ... like a closure".
>
>> >> A form that starts with `closure` is not a valid form because there is
>> >> no definition for `closure`: (fboundp 'closure) => nil.
>
>> >> > I bumped into one last summer.
>
>> >> > In particular (in my development repo fixing bug #64646) I put this into
>> >> > *scratch*:
>
>> >> >     (defconst foo (lambda (baz) (car baz)))
>
>> >> > , evaluated it with C-x C-e and then M-: (native-compile foo).  This
>> >> > threw the error "Cannot native-compile, form is not a lambda".
>
>> >> That error seems right according to the docstring:
>
>> >>    (defun native-compile (function-or-file &optional output)
>> >>      "Compile FUNCTION-OR-FILE into native code.
>> >>    This is the synchronous entry-point for the Emacs Lisp native
>> >>    compiler.  FUNCTION-OR-FILE is a function symbol, a form, or the
>> >>    filename of an Emacs Lisp source file.  If OUTPUT is non-nil, use
>> >>    it as the filename for the compiled object.  If FUNCTION-OR-FILE
>> >>    is a filename, if the compilation was successful return the
>> >>    filename of the compiled object.  If FUNCTION-OR-FILE is a
>> >>    function symbol or a form, if the compilation was successful
>> >>    return the compiled function."
>
>> >> (closure ...) is not a function symbol nor a valid form.  Instead it's
>> >> a function value and the docstring doesn't say such are
>> >> a valid arguments to `native-compile`.
>
>> > All very clever arguments, no doubt, but in the end it means you cannot
>> > native compile foo.  I've just tried it on emacs-30, and it doesn't work.
>> > But you could compile foo last summer after my fixes for bug #64646.
>> > Between last summer and now, something has gone badly wrong in Emacs's
>> > basic mechanisms.
>
>> (defconst foo (lambda (baz) (car baz)))
>> (native-compile #'foo)
>
>> Never worked AFAIR, ....
>
> No.  But (native-compile foo) did work.  It compiled the value of foo,
> producing an anonymous subr.
>
>> ....the functionality you added was:
>
>> (defun foo () "foo doc string"
>>        (lambda () "lambda doc string" 3))
>
>> (subr-native-elisp-p (funcall (native-compile 'foo)))
>
> Yes.
>
>> And this still works for me.
>
> It still works for me, too.
>
>> I'm probably missing something sorry.
>
> The fact that
>
> 	(defconst foo (lambda (baz) (car baz)))
> 	(native-compile foo)
>
> worked (as of 2023-11-08), but no longer does.  It was not the main topic
> of bug #64646 (for which see above), but was fixed in the commit for that
> bug anyway.  This was possibly not a good idea.  That commit was:
>
> commit 06e4ebc81a44c709b08ce72c746629c6c77e6f6e
> Author: Alan Mackenzie <acm@muc.de>
> Date:   Wed Nov 8 20:49:48 2023 +0000
>
>     With `native-compile', compile lambdas in a defun or lambda too

Thanks I see now, at least we never regressed over releases.

I think this functionaly passed under my radar at the time, otherwise I
would have asked for a test covering it, and BTW as a consequence Stefan
would have updated the implementation before upstreaming his patch :)

Anyway as
(defconst foo (lambda (baz) (car baz)))
(byte-compile foo)
works, I is nice to have it functional for native-comp as well.

Reintroducing it should not be too difficult, I can do it myself next
week if no-one does it before.

Thanks

  Andrea

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>> Hello, Andrea.
>>
>> On Sat, Jul 06, 2024 at 03:48:50 -0400, Andrea Corallo wrote:
>>> Alan Mackenzie <acm@muc.de> writes:
>>
>>> > Hello, Stefan.
>>
>>> > On Fri, Jul 05, 2024 at 14:17:38 -0400, Stefan Monnier wrote:
>>> >> > Not sure what you mean by "no such thing as a form ... like a closure".
>>
>>> >> A form that starts with `closure` is not a valid form because there is
>>> >> no definition for `closure`: (fboundp 'closure) => nil.
>>
>>> >> > I bumped into one last summer.
>>
>>> >> > In particular (in my development repo fixing bug #64646) I put this into
>>> >> > *scratch*:
>>
>>> >> >     (defconst foo (lambda (baz) (car baz)))
>>
>>> >> > , evaluated it with C-x C-e and then M-: (native-compile foo).  This
>>> >> > threw the error "Cannot native-compile, form is not a lambda".
>>
>>> >> That error seems right according to the docstring:
>>
>>> >>    (defun native-compile (function-or-file &optional output)
>>> >>      "Compile FUNCTION-OR-FILE into native code.
>>> >>    This is the synchronous entry-point for the Emacs Lisp native
>>> >>    compiler.  FUNCTION-OR-FILE is a function symbol, a form, or the
>>> >>    filename of an Emacs Lisp source file.  If OUTPUT is non-nil, use
>>> >>    it as the filename for the compiled object.  If FUNCTION-OR-FILE
>>> >>    is a filename, if the compilation was successful return the
>>> >>    filename of the compiled object.  If FUNCTION-OR-FILE is a
>>> >>    function symbol or a form, if the compilation was successful
>>> >>    return the compiled function."
>>
>>> >> (closure ...) is not a function symbol nor a valid form.  Instead it's
>>> >> a function value and the docstring doesn't say such are
>>> >> a valid arguments to `native-compile`.
>>
>>> > All very clever arguments, no doubt, but in the end it means you cannot
>>> > native compile foo.  I've just tried it on emacs-30, and it doesn't work.
>>> > But you could compile foo last summer after my fixes for bug #64646.
>>> > Between last summer and now, something has gone badly wrong in Emacs's
>>> > basic mechanisms.
>>
>>> (defconst foo (lambda (baz) (car baz)))
>>> (native-compile #'foo)
>>
>>> Never worked AFAIR, ....
>>
>> No.  But (native-compile foo) did work.  It compiled the value of foo,
>> producing an anonymous subr.
>>
>>> ....the functionality you added was:
>>
>>> (defun foo () "foo doc string"
>>>        (lambda () "lambda doc string" 3))
>>
>>> (subr-native-elisp-p (funcall (native-compile 'foo)))
>>
>> Yes.
>>
>>> And this still works for me.
>>
>> It still works for me, too.
>>
>>> I'm probably missing something sorry.
>>
>> The fact that
>>
>> 	(defconst foo (lambda (baz) (car baz)))
>> 	(native-compile foo)
>>
>> worked (as of 2023-11-08), but no longer does.  It was not the main topic
>> of bug #64646 (for which see above), but was fixed in the commit for that
>> bug anyway.  This was possibly not a good idea.  That commit was:
>>
>> commit 06e4ebc81a44c709b08ce72c746629c6c77e6f6e
>> Author: Alan Mackenzie <acm@muc.de>
>> Date:   Wed Nov 8 20:49:48 2023 +0000
>>
>>     With `native-compile', compile lambdas in a defun or lambda too
>
> Thanks I see now, at least we never regressed over releases.
>
> I think this functionaly passed under my radar at the time, otherwise I
> would have asked for a test covering it, and BTW as a consequence Stefan
> would have updated the implementation before upstreaming his patch :)
>
> Anyway as
> (defconst foo (lambda (baz) (car baz)))
> (byte-compile foo)
> works, I is nice to have it functional for native-comp as well.
>
> Reintroducing it should not be too difficult, I can do it myself next
> week if no-one does it before.

Okay should be done with b9b9322a8e6 in master adding a test and
updating 'native-compile' doc-string.

Is there anything left to do for this bug?

  Andrea

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Alan Mackenzie]

Hello, Andrea.

On Tue, Jul 09, 2024 at 16:49:26 -0400, Andrea Corallo wrote:
> Andrea Corallo <acorallo@gnu.org> writes:

> > Alan Mackenzie <acm@muc.de> writes:

> >> On Sat, Jul 06, 2024 at 03:48:50 -0400, Andrea Corallo wrote:
> >>> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > Thanks I see now, at least we never regressed over releases.

> > I think this functionaly passed under my radar at the time, otherwise I
> > would have asked for a test covering it, and BTW as a consequence Stefan
> > would have updated the implementation before upstreaming his patch :)

Yes.  ;-)

> > Anyway as
> > (defconst foo (lambda (baz) (car baz)))
> > (byte-compile foo)
> > works, I is nice to have it functional for native-comp as well.

> > Reintroducing it should not be too difficult, I can do it myself next
> > week if no-one does it before.

> Okay should be done with b9b9322a8e6 in master adding a test and
> updating 'native-compile' doc-string.

Thanks.  I haven't actually tried the fix, but it looks absolutely
routine, so there shouldn't be problems with it.

> Is there anything left to do for this bug?

I don't think so.

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrea.
>
> On Tue, Jul 09, 2024 at 16:49:26 -0400, Andrea Corallo wrote:
>> Andrea Corallo <acorallo@gnu.org> writes:
>
>> > Alan Mackenzie <acm@muc.de> writes:
>
>> >> On Sat, Jul 06, 2024 at 03:48:50 -0400, Andrea Corallo wrote:
>> >>> Alan Mackenzie <acm@muc.de> writes:
>
> [ .... ]
>
>> > Thanks I see now, at least we never regressed over releases.
>
>> > I think this functionaly passed under my radar at the time, otherwise I
>> > would have asked for a test covering it, and BTW as a consequence Stefan
>> > would have updated the implementation before upstreaming his patch :)
>
> Yes.  ;-)
>
>> > Anyway as
>> > (defconst foo (lambda (baz) (car baz)))
>> > (byte-compile foo)
>> > works, I is nice to have it functional for native-comp as well.
>
>> > Reintroducing it should not be too difficult, I can do it myself next
>> > week if no-one does it before.
>
>> Okay should be done with b9b9322a8e6 in master adding a test and
>> updating 'native-compile' doc-string.
>
> Thanks.  I haven't actually tried the fix, but it looks absolutely
> routine, so there shouldn't be problems with it.
>
>> Is there anything left to do for this bug?
>
> I don't think so.

Okay cool, I think the bug is already closed.

Thanks

  Andrea

bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Stefan.
>
> On Fri, Jul 05, 2024 at 11:48:10 -0400, Stefan Monnier wrote:
>> >> >> Andrea, can you take a look at this, please?
>> >> > Yep, I believe that code does not require to be changed, the input of
>> >> > comp--spill-lap-function is a form not an interpred function.
>> >> But then why does it check for `closure`?
>> > Back in 2023, one of the forms this function found itself unable to
>> > compile was a closure.  So I fixed this for bug #64646.
>
>> But there is no such thing as a *form* that looks like
>> (closure ...), so if we found such a thing either it was a bug or it
>> means that other function values like byte-code (or the new
>> `interpreted-function`s) could appear there and should arguably be
>> handled as well.
>
> Not sure what you mean by "no such thing as a form ... like a closure".
> I bumped into one last summer.
>
> In particular (in my development repo fixing bug #64646) I put this into
> *scratch*:
>
>     (defconst foo (lambda (baz) (car baz)))
>
> , evaluated it with C-x C-e and then M-: (native-compile foo).  This
> threw the error "Cannot native-compile, form is not a lambda".

I'm a little confused, I believe #64646 was about:

(defun foo ())
(native-compile 'foo)

Which still works for me on emacs-30, no?

  Andrea