* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
@ 2022-07-19 13:45 defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-19 16:49 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-19 13:45 UTC (permalink / raw)
To: 56643
Overview:
With native compilation enabled, adding a bookmark in a help buffer seems to work normally for the duration of the Emacs session, but when Emacs is restarted an "Invalid read syntax: '#'" error is thrown and the entire bookmark list fails to load. This appears to be caused by a compiled lambda being serialized to the bookmark file in a way that is unreadable to the reader.
Emacs version:
29.0.5, compiled from latest master branch on 7-18-2022, and started with emacs -Q for both scenarios below.
Steps to reproduce:
1. Ensure that native compilation is enabled by running M-x native-comp-available-p
2. Run M-x describe-function {{any-function}} and move to the resulting *Help* buffer
3. Create a bookmark with C-x r m
4. Without quitting Emacs, kill the *Help* buffer, then run C-x r b to jump back to the bookmark (this works as expected)
5. Quit Emacs (C-x C-c), and restart
6. Attempt to jump to the same bookmark again (running C-x r b), and observe that the bookmark list fails to load and throws an "Invalid read syntax: '#'" error
Here is an example of a help bookmark as it was serialized to the bookmarks file (note the "help-fn" value):
("native-comp-bookmark"
(position . 1)
(last-modified 25301 49750 590832 312000)
(help-fn . #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9>)
(help-args switch-to-buffer "*scratch*")
(position . 1)
(handler . help-bookmark-jump))
For comparison, I compiled Emacs without the native compilation flag (and verified that native-comp-available-p returned nil), and went through the same steps above, creating a new bookmark. Jumping back to the bookmark after restarting works as expected, and here is an example of that bookmark serialized without native comp:
("vanilla-bookmark"
(position . 1)
(last-modified 25301 49238 861856 736000)
(help-fn .
#[514 "\301\x01!\205\a\0\211\x18\302\x02!)\207"
[describe-function-orig-buffer buffer-live-p describe-function]
4 "\n\n(fn FUNCTION BUFFER)"])
(help-args switch-to-buffer "*scratch*")
(position . 1)
(handler . help-bookmark-jump))
I did find an older similar bug (#24573 https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-09/msg00971.html) which was causing the same error due to a buffer object being serialized. This was fixed by saving just the buffer name, but I'm not sure there's any comparable way to save a reference to a compiled lambda. Any advice would be much appreciated though!
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-19 13:45 bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-19 16:49 ` Eli Zaretskii
2022-07-19 22:22 ` defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-07-19 16:49 UTC (permalink / raw)
To: defun.foo; +Cc: 56643
> Date: Tue, 19 Jul 2022 13:45:19 +0000
> From: defun.foo--- via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> 1. Ensure that native compilation is enabled by running M-x native-comp-available-p
> 2. Run M-x describe-function {{any-function}} and move to the resulting *Help* buffer
> 3. Create a bookmark with C-x r m
> 4. Without quitting Emacs, kill the *Help* buffer, then run C-x r b to jump back to the bookmark (this works as expected)
> 5. Quit Emacs (C-x C-c), and restart
> 6. Attempt to jump to the same bookmark again (running C-x r b), and observe that the bookmark list fails to load and throws an "Invalid read syntax: '#'" error
>
> Here is an example of a help bookmark as it was serialized to the bookmarks file (note the "help-fn" value):
>
> ("native-comp-bookmark"
> (position . 1)
> (last-modified 25301 49750 590832 312000)
> (help-fn . #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9>)
> (help-args switch-to-buffer "*scratch*")
> (position . 1)
> (handler . help-bookmark-jump))
>
> For comparison, I compiled Emacs without the native compilation flag (and verified that native-comp-available-p returned nil), and went through the same steps above, creating a new bookmark. Jumping back to the bookmark after restarting works as expected, and here is an example of that bookmark serialized without native comp:
>
> ("vanilla-bookmark"
> (position . 1)
> (last-modified 25301 49238 861856 736000)
> (help-fn .
> #[514 "\301\x01!\205\a\0\211\x18\302\x02!)\207"
> [describe-function-orig-buffer buffer-live-p describe-function]
> 4 "\n\n(fn FUNCTION BUFFER)"])
> (help-args switch-to-buffer "*scratch*")
> (position . 1)
> (handler . help-bookmark-jump))
Thanks.
I started looking into this, but gave up when I got to help-mode.el
(which is where the bookmark support for *Help* lives, and which is
where we signal an error trying to read an unreadable object.)
We basically have no usable documentation for what bookmark support in
help-mode does. Someone who knows what that code does will have to
see how to process a help-fn that is a natively-compiled function.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-19 16:49 ` Eli Zaretskii
@ 2022-07-19 22:22 ` defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 9:51 ` Andrea Corallo
2022-07-20 11:21 ` Andrea Corallo
0 siblings, 2 replies; 16+ messages in thread
From: defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-19 22:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 56643
I dug into that a little when I was trying to find a work-around. It looks like help-mode maintains a stack of previously-visited help items which is what enables users to jump back and forth between different items they've viewed. From "C-h v help-xref-stack":
"A stack of ways by which to return to help buffers after following xrefs.
Used by ‘help-follow-symbol’ and ‘help-xref-go-back’.
An element looks like (POSITION FUNCTION ARGS...).
To use the element, do (apply FUNCTION ARGS) then goto the point."
So basically the FUNCTION element is a recipe for recreating a specific help item, and "help-bookmark-make-record" just drops that FUNCTION element intact into "help-fn" when creating a bookmark:
`(,@(bookmark-make-record-default 'NO-FILE 'NO-CONTEXT)
(help-fn . ,(car help-xref-stack-item))
(help-args . ,(mapcar (lambda (a)
(if (bufferp a) (buffer-name a) a))
(cdr help-xref-stack-item)))
(position . ,(point))
(handler . help-bookmark-jump))
The catch is that every function that generates a help buffer also defines its own way of setting up an xref stack item. Some pass in a symbol while some pass in a lambda, so after a while the stack might end up looking like this:
((1 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_20>
(("\x18\x03" .
[24 3]))
#<buffer *Help*>)
(232 describe-variable help-xref-stack #<buffer *Help*>)
(1 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_7> describe-package #<buffer *Help*>))
Then when bookmark.el saves all the bookmarks ("bookmark-write-file"), it just calls "pp" on each one:
(dolist (i bookmark-alist) (pp i (current-buffer)))
which apparently is able to create a readable representation of byte-compiled lambdas, but not native-compiled ones.
And that's where my knowledge ends. :) I have very little C programming experience and have no idea if it's even possible to serialize a compiled thing into something the reader can understand, or whether there's some processing help-mode could do on each function before it even becomes part of a bookmark.
------- Original Message -------
On Tuesday, July 19th, 2022 at 12:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Thanks.
>
> I started looking into this, but gave up when I got to help-mode.el
> (which is where the bookmark support for Help lives, and which is
> where we signal an error trying to read an unreadable object.)
>
> We basically have no usable documentation for what bookmark support in
> help-mode does. Someone who knows what that code does will have to
> see how to process a help-fn that is a natively-compiled function.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-19 22:22 ` defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-20 9:51 ` Andrea Corallo
2022-07-20 11:21 ` Andrea Corallo
1 sibling, 0 replies; 16+ messages in thread
From: Andrea Corallo @ 2022-07-20 9:51 UTC (permalink / raw)
Cc: defun.foo, 56643, @mx.sdf.org, eliz
"defun.foo--- via \"Bug reports for GNU Emacs, the Swiss army knife of
text editors\"" <bug-gnu-emacs@gnu.org> writes:
> I dug into that a little when I was trying to find a work-around. It looks like help-mode maintains a stack of previously-visited help items which is what enables users to jump back and forth between different items they've viewed. From "C-h v help-xref-stack":
>
> "A stack of ways by which to return to help buffers after following xrefs.
> Used by ‘help-follow-symbol’ and ‘help-xref-go-back’.
> An element looks like (POSITION FUNCTION ARGS...).
> To use the element, do (apply FUNCTION ARGS) then goto the point."
>
> So basically the FUNCTION element is a recipe for recreating a specific help item, and "help-bookmark-make-record" just drops that FUNCTION element intact into "help-fn" when creating a bookmark:
>
> `(,@(bookmark-make-record-default 'NO-FILE 'NO-CONTEXT)
> (help-fn . ,(car help-xref-stack-item))
> (help-args . ,(mapcar (lambda (a)
> (if (bufferp a) (buffer-name a) a))
> (cdr help-xref-stack-item)))
> (position . ,(point))
> (handler . help-bookmark-jump))
>
> The catch is that every function that generates a help buffer also defines its own way of setting up an xref stack item. Some pass in a symbol while some pass in a lambda, so after a while the stack might end up looking like this:
>
> ((1 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_20>
> (("\x03" .
> [24 3]))
> #<buffer *Help*>)
> (232 describe-variable help-xref-stack #<buffer *Help*>)
> (1 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_7> describe-package #<buffer *Help*>))
>
> Then when bookmark.el saves all the bookmarks ("bookmark-write-file"), it just calls "pp" on each one:
>
> (dolist (i bookmark-alist) (pp i (current-buffer)))
>
> which apparently is able to create a readable representation of byte-compiled lambdas, but not native-compiled ones.
>
> And that's where my knowledge ends. :) I have very little C programming experience and have no idea if it's even possible to serialize a compiled thing into something the reader can understand, or whether there's some processing help-mode could do on each function before it even becomes part of a bookmark.
It is unfortunatelly not possible to serialize native compiled code so
that the reader can read it back. Native code can only stay in shared
libraries (eln files) and be loaded from there.
Not sure if help-mode can use a different strategy.
BR
Andrea
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-19 22:22 ` defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 9:51 ` Andrea Corallo
@ 2022-07-20 11:21 ` Andrea Corallo
2022-07-20 11:45 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Andrea Corallo @ 2022-07-20 11:21 UTC (permalink / raw)
To: defun.foo; +Cc: Eli Zaretskii, 56643
"defun.foo--- via \"Bug reports for GNU Emacs, the Swiss army knife of
text editors\"" <bug-gnu-emacs@gnu.org> writes:
> I dug into that a little when I was trying to find a work-around. It looks like help-mode maintains a stack of previously-visited help items which is what enables users to jump back and forth between different items they've viewed. From "C-h v help-xref-stack":
>
> "A stack of ways by which to return to help buffers after following xrefs.
> Used by ‘help-follow-symbol’ and ‘help-xref-go-back’.
> An element looks like (POSITION FUNCTION ARGS...).
> To use the element, do (apply FUNCTION ARGS) then goto the point."
>
> So basically the FUNCTION element is a recipe for recreating a specific help item, and "help-bookmark-make-record" just drops that FUNCTION element intact into "help-fn" when creating a bookmark:
>
> `(,@(bookmark-make-record-default 'NO-FILE 'NO-CONTEXT)
> (help-fn . ,(car help-xref-stack-item))
> (help-args . ,(mapcar (lambda (a)
> (if (bufferp a) (buffer-name a) a))
> (cdr help-xref-stack-item)))
> (position . ,(point))
> (handler . help-bookmark-jump))
>
> The catch is that every function that generates a help buffer also defines its own way of setting up an xref stack item. Some pass in a symbol while some pass in a lambda, so after a while the stack might end up looking like this:
>
> ((1 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_20>
> (("\x03" .
> [24 3]))
> #<buffer *Help*>)
> (232 describe-variable help-xref-stack #<buffer *Help*>)
> (1 #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_7> describe-package #<buffer *Help*>))
>
> Then when bookmark.el saves all the bookmarks ("bookmark-write-file"), it just calls "pp" on each one:
>
> (dolist (i bookmark-alist) (pp i (current-buffer)))
>
> which apparently is able to create a readable representation of byte-compiled lambdas, but not native-compiled ones.
>
> And that's where my knowledge ends. :) I have very little C programming experience and have no idea if it's even possible to serialize a compiled thing into something the reader can understand, or whether there's some processing help-mode could do on each function before it even becomes part of a bookmark.
It is unfortunatelly not possible to serialize native compiled code so
that the reader can read it back. Native code can only stay in shared
libraries (eln files) and be loaded from there.
Not sure if help-mode can use a different strategy.
BR
Andrea
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-20 11:21 ` Andrea Corallo
@ 2022-07-20 11:45 ` Eli Zaretskii
2022-07-20 18:31 ` Andrea Corallo
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-07-20 11:45 UTC (permalink / raw)
To: Andrea Corallo; +Cc: defun.foo, 56643
> From: Andrea Corallo <akrl@sdf.org>
> Cc: 56643@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 20 Jul 2022 11:21:06 +0000
>
> It is unfortunatelly not possible to serialize native compiled code so
> that the reader can read it back. Native code can only stay in shared
> libraries (eln files) and be loaded from there.
Can we deduce the name of the Lisp function (a symbol) whose
native-compilation result is a given natively-compiled subr? If so,
perhaps we could substitute the function's symbol for the subr name.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-20 11:45 ` Eli Zaretskii
@ 2022-07-20 18:31 ` Andrea Corallo
2022-07-20 19:16 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Andrea Corallo @ 2022-07-20 18:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: defun.foo, 56643
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 56643@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>> Date: Wed, 20 Jul 2022 11:21:06 +0000
>>
>> It is unfortunatelly not possible to serialize native compiled code so
>> that the reader can read it back. Native code can only stay in shared
>> libraries (eln files) and be loaded from there.
>
> Can we deduce the name of the Lisp function (a symbol) whose
> native-compilation result is a given natively-compiled subr? If so,
> perhaps we could substitute the function's symbol for the subr name.
Not that I'm aware.
I guest would be necessary to keep some global (or per native function)
hash table that is updated in Fset?
I hope there's some workaround to this in the help / bookmarks machinery
cause this does not look very neat to me.
Andrea
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-20 18:31 ` Andrea Corallo
@ 2022-07-20 19:16 ` Eli Zaretskii
2022-07-20 22:47 ` Michael Heerdegen
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-07-20 19:16 UTC (permalink / raw)
To: Andrea Corallo; +Cc: defun.foo, 56643
> From: Andrea Corallo <akrl@sdf.org>
> Cc: defun.foo@proton.me, 56643@debbugs.gnu.org
> Date: Wed, 20 Jul 2022 18:31:56 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Can we deduce the name of the Lisp function (a symbol) whose
> > native-compilation result is a given natively-compiled subr? If so,
> > perhaps we could substitute the function's symbol for the subr name.
>
> Not that I'm aware.
>
> I guest would be necessary to keep some global (or per native function)
> hash table that is updated in Fset?
>
> I hope there's some workaround to this in the help / bookmarks machinery
> cause this does not look very neat to me.
The relevant code looks like this:
(help-setup-xref
(list (lambda (function buffer)
(let ((describe-function-orig-buffer
(if (buffer-live-p buffer) buffer)))
(describe-function function)))
function describe-function-orig-buffer)
(called-interactively-p 'interactive))
In a natively-compiled Emacs, this lambda produces a native-compiled
subr. Is there a way of telling Emacs not to produce such a subr, but
instead to produce byte-code for this lambda? If yes, that could be a
(somewhat ugly) workaround in this case.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-20 19:16 ` Eli Zaretskii
@ 2022-07-20 22:47 ` Michael Heerdegen
2022-07-21 5:13 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Michael Heerdegen @ 2022-07-20 22:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: defun.foo, 56643, Andrea Corallo
Eli Zaretskii <eliz@gnu.org> writes:
> (help-setup-xref
> (list (lambda (function buffer)
> (let ((describe-function-orig-buffer
> (if (buffer-live-p buffer) buffer)))
> (describe-function function)))
> function describe-function-orig-buffer)
> (called-interactively-p 'interactive))
>
> In a natively-compiled Emacs, this lambda produces a native-compiled
> subr. Is there a way of telling Emacs not to produce such a subr, but
> instead to produce byte-code for this lambda? If yes, that could be a
> (somewhat ugly) workaround in this case.
Alternatively we could introduce a named helper function. Note there
are more calls of `help-setup-xref' using lambdas in arguments.
I see a more general problem: anywhere where printing an anonymous
function readably is necessary there is a potential breakage when using
natively compiled Emacs - right? That would be quite a limitation.
Michael.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-20 22:47 ` Michael Heerdegen
@ 2022-07-21 5:13 ` Eli Zaretskii
2022-07-21 10:01 ` defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-07-21 5:13 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: defun.foo, 56643, akrl
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Andrea Corallo <akrl@sdf.org>, defun.foo@proton.me, 56643@debbugs.gnu.org
> Date: Thu, 21 Jul 2022 00:47:30 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > (help-setup-xref
> > (list (lambda (function buffer)
> > (let ((describe-function-orig-buffer
> > (if (buffer-live-p buffer) buffer)))
> > (describe-function function)))
> > function describe-function-orig-buffer)
> > (called-interactively-p 'interactive))
> >
> > In a natively-compiled Emacs, this lambda produces a native-compiled
> > subr. Is there a way of telling Emacs not to produce such a subr, but
> > instead to produce byte-code for this lambda? If yes, that could be a
> > (somewhat ugly) workaround in this case.
>
> Alternatively we could introduce a named helper function. Note there
> are more calls of `help-setup-xref' using lambdas in arguments.
And that would solve the problem? Did you try that?
> I see a more general problem: anywhere where printing an anonymous
> function readably is necessary there is a potential breakage when using
> natively compiled Emacs - right?
Only if the function is serialized and written somewhere, and then
some code wants to read it. Natively-compiled code cannot be read,
AFAIU.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-21 5:13 ` Eli Zaretskii
@ 2022-07-21 10:01 ` defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-21 12:33 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-21 10:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Michael Heerdegen, 56643, akrl
> > Alternatively we could introduce a named helper function. Note there
> > are more calls of `help-setup-xref' using lambdas in arguments.
>
>
> And that would solve the problem? Did you try that?
I tried it with describe-function and it does solve the problem, although as noted above there are many other functions that generate help buffers and pass in a lambda.
Named helper:
(defun describe-function-xref-func (function buffer)
(let ((describe-function-orig-buffer
(if (buffer-live-p buffer) buffer)))
(describe-function function)))
Revised describe-function snippet:
(help-setup-xref
(list 'describe-function-xref-func function describe-function-orig-buffer)
(called-interactively-p 'interactive))
This produces the following bookmark, which I confirmed still works after restarting Emacs:
("named-function-help-bookmark"
(position . 1)
(last-modified 25305 7198 806743 243000)
(help-fn . describe-function-xref-func)
(help-args completing-read "*scratch*")
(position . 1)
(handler . help-bookmark-jump))
> > I see a more general problem: anywhere where printing an anonymous
> > function readably is necessary there is a potential breakage when using
> > natively compiled Emacs - right? That would be quite a limitation.
I had the same thought. I'd bet there are other packages that rely on being able to read code back reliably. I"m curious if there is any metadata at all attached to a natively-compiled function?
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-21 10:01 ` defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-21 12:33 ` Eli Zaretskii
2022-07-22 13:40 ` Eli Zaretskii
2022-07-22 13:41 ` Andrea Corallo
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2022-07-21 12:33 UTC (permalink / raw)
To: defun.foo; +Cc: michael_heerdegen, 56643, akrl
> Date: Thu, 21 Jul 2022 10:01:57 +0000
> From: defun.foo@proton.me
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, akrl@sdf.org, 56643@debbugs.gnu.org
>
> > > Alternatively we could introduce a named helper function. Note there
> > > are more calls of `help-setup-xref' using lambdas in arguments.
> >
> >
> > And that would solve the problem? Did you try that?
>
> I tried it with describe-function and it does solve the problem, although as noted above there are many other functions that generate help buffers and pass in a lambda.
I know very well there are other instances, I just wanted us to stay
focused.
> Named helper:
>
> (defun describe-function-xref-func (function buffer)
> (let ((describe-function-orig-buffer
> (if (buffer-live-p buffer) buffer)))
> (describe-function function)))
>
> Revised describe-function snippet:
>
> (help-setup-xref
> (list 'describe-function-xref-func function describe-function-orig-buffer)
> (called-interactively-p 'interactive))
>
> This produces the following bookmark, which I confirmed still works after restarting Emacs:
>
> ("named-function-help-bookmark"
> (position . 1)
> (last-modified 25305 7198 806743 243000)
> (help-fn . describe-function-xref-func)
> (help-args completing-read "*scratch*")
> (position . 1)
> (handler . help-bookmark-jump))
Thanks. If Andrea confirms that this won't have any problems with
native-compilation, I will install such changes on the release branch
(since AFAIU this issue is a regression in Emacs 28).
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-21 12:33 ` Eli Zaretskii
@ 2022-07-22 13:40 ` Eli Zaretskii
2022-07-22 13:41 ` Andrea Corallo
1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2022-07-22 13:40 UTC (permalink / raw)
To: akrl; +Cc: michael_heerdegen, defun.foo, 56643
> Cc: michael_heerdegen@web.de, 56643@debbugs.gnu.org, akrl@sdf.org
> Date: Thu, 21 Jul 2022 15:33:52 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > > > Alternatively we could introduce a named helper function. Note there
> > > > are more calls of `help-setup-xref' using lambdas in arguments.
> > >
> > >
> > > And that would solve the problem? Did you try that?
> >
> > I tried it with describe-function and it does solve the problem, although as noted above there are many other functions that generate help buffers and pass in a lambda.
>
> I know very well there are other instances, I just wanted us to stay
> focused.
>
> > Named helper:
> >
> > (defun describe-function-xref-func (function buffer)
> > (let ((describe-function-orig-buffer
> > (if (buffer-live-p buffer) buffer)))
> > (describe-function function)))
> >
> > Revised describe-function snippet:
> >
> > (help-setup-xref
> > (list 'describe-function-xref-func function describe-function-orig-buffer)
> > (called-interactively-p 'interactive))
> >
> > This produces the following bookmark, which I confirmed still works after restarting Emacs:
> >
> > ("named-function-help-bookmark"
> > (position . 1)
> > (last-modified 25305 7198 806743 243000)
> > (help-fn . describe-function-xref-func)
> > (help-args completing-read "*scratch*")
> > (position . 1)
> > (handler . help-bookmark-jump))
>
> Thanks. If Andrea confirms that this won't have any problems with
> native-compilation, I will install such changes on the release branch
> (since AFAIU this issue is a regression in Emacs 28).
Andrea, could you please tell if using a named function there will fix
the problem?
Thanks.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-21 12:33 ` Eli Zaretskii
2022-07-22 13:40 ` Eli Zaretskii
@ 2022-07-22 13:41 ` Andrea Corallo
2022-07-22 14:40 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Andrea Corallo @ 2022-07-22 13:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, defun.foo, 56643
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Thu, 21 Jul 2022 10:01:57 +0000
>> From: defun.foo@proton.me
>> Cc: Michael Heerdegen <michael_heerdegen@web.de>, akrl@sdf.org, 56643@debbugs.gnu.org
>>
>> > > Alternatively we could introduce a named helper function. Note there
>> > > are more calls of `help-setup-xref' using lambdas in arguments.
>> >
>> >
>> > And that would solve the problem? Did you try that?
>>
>> I tried it with describe-function and it does solve the problem,
>> although as noted above there are many other functions that generate
>> help buffers and pass in a lambda.
>
> I know very well there are other instances, I just wanted us to stay
> focused.
>
>> Named helper:
>>
>> (defun describe-function-xref-func (function buffer)
>> (let ((describe-function-orig-buffer
>> (if (buffer-live-p buffer) buffer)))
>> (describe-function function)))
>>
>> Revised describe-function snippet:
>>
>> (help-setup-xref
>> (list 'describe-function-xref-func function describe-function-orig-buffer)
>> (called-interactively-p 'interactive))
>>
>> This produces the following bookmark, which I confirmed still works after restarting Emacs:
>>
>> ("named-function-help-bookmark"
>> (position . 1)
>> (last-modified 25305 7198 806743 243000)
>> (help-fn . describe-function-xref-func)
>> (help-args completing-read "*scratch*")
>> (position . 1)
>> (handler . help-bookmark-jump))
>
> Thanks. If Andrea confirms that this won't have any problems with
> native-compilation, I will install such changes on the release branch
> (since AFAIU this issue is a regression in Emacs 28).
I confirm it should just work.
Actually I think the use of a lambda there was not really optimal in
first place as is not capturing anything and we were serializing and
deserializing the same code over and over again for no good reason.
BTW, I mention this for other similar cases, another fix would be to add
(declare (speed -1)) to `describe-function'. Ideally would be _really_
nice to add it directly to the lambda we want to be able to
se/deserialize, but AFAIK the declare semantinc is not available to
lambdas :( Probably an improvement to keep in mind...
Thanks
Andrea
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-22 13:41 ` Andrea Corallo
@ 2022-07-22 14:40 ` Eli Zaretskii
2022-07-23 9:57 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2022-07-22 14:40 UTC (permalink / raw)
To: Andrea Corallo; +Cc: michael_heerdegen, defun.foo, 56643
> From: Andrea Corallo <akrl@sdf.org>
> Cc: defun.foo@proton.me, michael_heerdegen@web.de, 56643@debbugs.gnu.org
> Date: Fri, 22 Jul 2022 13:41:32 +0000
>
> >> ("named-function-help-bookmark"
> >> (position . 1)
> >> (last-modified 25305 7198 806743 243000)
> >> (help-fn . describe-function-xref-func)
> >> (help-args completing-read "*scratch*")
> >> (position . 1)
> >> (handler . help-bookmark-jump))
> >
> > Thanks. If Andrea confirms that this won't have any problems with
> > native-compilation, I will install such changes on the release branch
> > (since AFAIU this issue is a regression in Emacs 28).
>
> I confirm it should just work.
Thanks, so I will make those changes on the release branch.
> Actually I think the use of a lambda there was not really optimal in
> first place as is not capturing anything and we were serializing and
> deserializing the same code over and over again for no good reason.
Right.
> BTW, I mention this for other similar cases, another fix would be to add
> (declare (speed -1)) to `describe-function'.
Thanks, good to know. I guess we should document that in the ELisp
manual.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
2022-07-22 14:40 ` Eli Zaretskii
@ 2022-07-23 9:57 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2022-07-23 9:57 UTC (permalink / raw)
To: akrl, michael_heerdegen, defun.foo; +Cc: 56643-done
> Cc: michael_heerdegen@web.de, defun.foo@proton.me, 56643@debbugs.gnu.org
> Date: Fri, 22 Jul 2022 17:40:48 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > > Thanks. If Andrea confirms that this won't have any problems with
> > > native-compilation, I will install such changes on the release branch
> > > (since AFAIU this issue is a regression in Emacs 28).
> >
> > I confirm it should just work.
>
> Thanks, so I will make those changes on the release branch.
Done.
> > BTW, I mention this for other similar cases, another fix would be to add
> > (declare (speed -1)) to `describe-function'.
>
> Thanks, good to know. I guess we should document that in the ELisp
> manual.
Also done.
Closing.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-07-23 9:57 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-19 13:45 bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-19 16:49 ` Eli Zaretskii
2022-07-19 22:22 ` defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 9:51 ` Andrea Corallo
2022-07-20 11:21 ` Andrea Corallo
2022-07-20 11:45 ` Eli Zaretskii
2022-07-20 18:31 ` Andrea Corallo
2022-07-20 19:16 ` Eli Zaretskii
2022-07-20 22:47 ` Michael Heerdegen
2022-07-21 5:13 ` Eli Zaretskii
2022-07-21 10:01 ` defun.foo--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-21 12:33 ` Eli Zaretskii
2022-07-22 13:40 ` Eli Zaretskii
2022-07-22 13:41 ` Andrea Corallo
2022-07-22 14:40 ` Eli Zaretskii
2022-07-23 9:57 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).