GNU bug report logs - #56643
29.0.50; Help-mode bookmarks not loading with native compilation

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: defun.foo <at> proton.me, 56643 <at> debbugs.gnu.org
Subject: bug#56643: 29.0.50; Help-mode bookmarks not loading with native compilation
Date: Wed, 20 Jul 2022 22:16:11 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: defun.foo <at> proton.me, 56643 <at> debbugs.gnu.org
> Date: Wed, 20 Jul 2022 18:31:56 +0000
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.