GNU bug report logs - #17685
24.3.91.1; help-C-file-name failes to create temp buffer " *DOC*"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17685 in the body.
You can then email your comments to 17685 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Guath <stefan <at> automata.se>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.91.1; help-C-file-name failes to create temp buffer " *DOC*"
Date: Wed, 4 Jun 2014 10:47:44 +0200

VERSION:
GNU Emacs 24.3.91.1 (x86_64-apple-darwin13.2.0, NS apple-appkit-1265.20) of 2014-05-23 on angelofdeaths-MacBook-Air.local

TO REPRODUCE BUG:
emacs -Q
(find-lisp-object-file-name 'visible-bell 'defvar) ;visible-bell is just an example and can be replaced with any variable.

RESULT:
C-source

EXPECTED RESULT:
"src/dispnew.c"
Note that I've compiled Emacs from source, and the source files are available. This is also proved by the work-around below.

WORK-AROUND:
emacs -Q
(get-buffer-create " *DOC*") ;That's a crazy line...
(find-lisp-object-file-name 'visible-bell 'defvar) ;...but now it suddenly works!

If you manually kill buffer " *DOC*", it stops working again.

GUESS OF SOLUTION:
According to help-fns.el, find-lisp-object-file-name calls help-C-file-name that in turn tries to create a temp buffer " *DOC*". Maybe this buffer creation somehow fails? It seems like it, since the bug disappears if we create the buffer in advance, and comes back when we manually delete the buffer. Or maybe there is some other error in help-C-file-name or even in get-buffer-create that manifests itself in this strange way?

Message #8 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Stefan Guath <stefan <at> automata.se>
Cc: 17685 <at> debbugs.gnu.org
Subject: Re: bug#17685: 24.3.91.1;
 help-C-file-name failes to create temp buffer " *DOC*"
Date: Wed, 04 Jun 2014 09:15:41 -0400

> emacs -Q
> (find-lisp-object-file-name 'visible-bell 'defvar) ;visible-bell is just an
> example and can be replaced with any variable.

> RESULT:
> C-source

> EXPECTED RESULT:
> "src/dispnew.c"

Here's the reason for the behavior:
the DOC file is moderately large, so we don't want to load it into
memory just because the user did C-h v visible-bell RET.

So we only populate the *DOC* buffer when the user actually clicks on
the "C-source" link to jump to the source code.  And once the buffer is
populated, then there's no reason not to use it, so if *DOC* exists then
we do use it.

We could probably change it so that we always populate the *DOC* buffer
in the case where the C sources are available (so the behavior would
stay unchanged for users running pre-compiled Emacs, while it would
work better for those users who compile it themselves and keep the
source in place).  But I'm not sure it'd really be an improvement.


        Stefan

Message #11 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, Stefan Guath
 <stefan <at> automata.se>
Cc: 17685 <at> debbugs.gnu.org
Subject: RE: bug#17685: 24.3.91.1; help-C-file-name failes to create temp
 buffer " *DOC*"
Date: Wed, 4 Jun 2014 07:08:05 -0700 (PDT)

> > emacs -Q
> > (find-lisp-object-file-name 'visible-bell 'defvar) ;visible-bell is just
> > an example and can be replaced with any variable.
> > RESULT:          C-source
> > EXPECTED RESULT: "src/dispnew.c"
> 
> Here's the reason for the behavior:
> the DOC file is moderately large, so we don't want to load it into
> memory just because the user did C-h v visible-bell RET.
> 
> So we only populate the *DOC* buffer when the user actually clicks on
> the "C-source" link to jump to the source code.  And once the buffer is
> populated, then there's no reason not to use it, so if *DOC* exists then
> we do use it.

Is this behavior new (e.g. since 24.3)?  Do you think it might be related
to bug #17564: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17564
(That report is about `C-source' being passed as the FILE-NAME arg to
`help-fns--autoloaded-p'.)

emacs -Q
(fset 'ORIG-top-level (symbol-function 'top-level))
(defun top-level () (interactive) (ORIG-top-level))

C-h f top-level
Debugger entered--Lisp error: (wrong-type-argument arrayp C-source)
  file-truename(C-source)
  ...

Message #14 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 17685 <at> debbugs.gnu.org, Stefan Guath <stefan <at> automata.se>
Subject: Re: bug#17685: 24.3.91.1;
 help-C-file-name failes to create temp buffer " *DOC*"
Date: Wed, 04 Jun 2014 10:21:17 -0400

> Is this behavior new (e.g. since 24.3)?

No, it's as old as the code that lets you jump to the C source code.


        Stefan

Message #17 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Guath <stefan <at> automata.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17685 <at> debbugs.gnu.org
Subject: Re: bug#17685: 24.3.91.1;
 help-C-file-name failes to create temp buffer " *DOC*"
Date: Thu, 5 Jun 2014 08:46:57 +0200

I understand. But it seems an unsatisfactory solution to demand callers of find-lisp-object-file-name to pre-evaluate (get-buffer-create " *DOC*") in order to activate its c-source search ability (i.e. convoluted code, code breaks when buffer name changes etc). Maybe just add an optional argument in find-lisp-object-file-name? Something like enable-c-search with the explanation "Please note that this will be memory consuming."?

/Stefan Guath

On 4 jun 2014, at 15:15, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

>> emacs -Q
>> (find-lisp-object-file-name 'visible-bell 'defvar) ;visible-bell is just an
>> example and can be replaced with any variable.
> 
>> RESULT:
>> C-source
> 
>> EXPECTED RESULT:
>> "src/dispnew.c"
> 
> Here's the reason for the behavior:
> the DOC file is moderately large, so we don't want to load it into
> memory just because the user did C-h v visible-bell RET.
> 
> So we only populate the *DOC* buffer when the user actually clicks on
> the "C-source" link to jump to the source code.  And once the buffer is
> populated, then there's no reason not to use it, so if *DOC* exists then
> we do use it.
> 
> We could probably change it so that we always populate the *DOC* buffer
> in the case where the C sources are available (so the behavior would
> stay unchanged for users running pre-compiled Emacs, while it would
> work better for those users who compile it themselves and keep the
> source in place).  But I'm not sure it'd really be an improvement.
> 
> 
>        Stefan

Message #20 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Guath <stefan <at> automata.se>, 
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17685 <at> debbugs.gnu.org
Subject: Re: bug#17685: 24.3.91.1; help-C-file-name failes to create temp
 buffer " *DOC*"
Date: Thu, 05 Jun 2014 09:48:58 +0200

> I understand. But it seems an unsatisfactory solution to demand
> callers of find-lisp-object-file-name to pre-evaluate
> (get-buffer-create " *DOC*") in order to activate its c-source search
> ability (i.e. convoluted code, code breaks when buffer name changes
> etc). Maybe just add an optional argument in
> find-lisp-object-file-name? Something like enable-c-search with the
> explanation "Please note that this will be memory consuming."?

How about reserving an extra value for `help-enable-auto-load' which, if
set, would trigger auto-creating the *DOC* buffer.

martin

Message #23 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Guath <stefan <at> automata.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 17685 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17685: 24.3.91.1;
 help-C-file-name failes to create temp buffer " *DOC*"
Date: Thu, 5 Jun 2014 10:35:50 +0200

But would such a solution really fix the problem when calling find-lisp-object-file-name programmatically? E.g. (simplifed version just to illustrate the concept):

(defun show-elisp-src-at-point ()
  (interactive)
  (message (find-lisp-object-file-name (variable-at-point) 'defvar)))

Now, executing show-elisp-src-at-point with point on a C variable just returns the symbol 'C-source. With an optional variable enable-c-search in find-lisp-object-file-name, it could instead return the actual C source file name.

I don't think an extra value in help-enable-auto-load would be of any help in these kind of cases (i.e. when used programmatically).

/Stefan Guath

On 5 jun 2014, at 09:48, martin rudalics <rudalics <at> gmx.at> wrote:

> > I understand. But it seems an unsatisfactory solution to demand
> > callers of find-lisp-object-file-name to pre-evaluate
> > (get-buffer-create " *DOC*") in order to activate its c-source search
> > ability (i.e. convoluted code, code breaks when buffer name changes
> > etc). Maybe just add an optional argument in
> > find-lisp-object-file-name? Something like enable-c-search with the
> > explanation "Please note that this will be memory consuming."?
> 
> How about reserving an extra value for `help-enable-auto-load' which, if
> set, would trigger auto-creating the *DOC* buffer.
> 
> martin

Message #26 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Guath <stefan <at> automata.se>
Cc: 17685 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17685: 24.3.91.1; help-C-file-name failes to create temp
 buffer " *DOC*"
Date: Thu, 05 Jun 2014 10:45:35 +0200

> (defun show-elisp-src-at-point ()
>    (interactive)
>    (message (find-lisp-object-file-name (variable-at-point) 'defvar)))
>
> Now, executing show-elisp-src-at-point with point on a C variable just returns the symbol 'C-source. With an optional variable enable-c-search in find-lisp-object-file-name, it could instead return the actual C source file name.
>
> I don't think an extra value in help-enable-auto-load would be of any help in these kind of cases (i.e. when used programmatically).

I thought about something like

(if (or (and (eq help-enable-auto-load 'create-doc)
	     (get-buffer-create " *DOC*"))
	(get-buffer " *DOC*"))
    (help-C-file-name type 'subr)
  'C-source)

in `find-lisp-object-file-name'.

martin

Message #29 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Guath <stefan <at> automata.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 17685 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17685: 24.3.91.1;
 help-C-file-name failes to create temp buffer " *DOC*"
Date: Thu, 5 Jun 2014 11:00:59 +0200

Ok, I understand!

On 5 jun 2014, at 10:45, martin rudalics <rudalics <at> gmx.at> wrote:

> > (defun show-elisp-src-at-point ()
> >    (interactive)
> >    (message (find-lisp-object-file-name (variable-at-point) 'defvar)))
> >
> > Now, executing show-elisp-src-at-point with point on a C variable just returns the symbol 'C-source. With an optional variable enable-c-search in find-lisp-object-file-name, it could instead return the actual C source file name.
> >
> > I don't think an extra value in help-enable-auto-load would be of any help in these kind of cases (i.e. when used programmatically).
> 
> I thought about something like
> 
> (if (or (and (eq help-enable-auto-load 'create-doc)
> 	     (get-buffer-create " *DOC*"))
> 	(get-buffer " *DOC*"))
>    (help-C-file-name type 'subr)
>  'C-source)
> 
> in `find-lisp-object-file-name'.
> 
> martin

Message #32 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Guath <stefan <at> automata.se>
Cc: 17685 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#17685: 24.3.91.1;
 help-C-file-name failes to create temp buffer " *DOC*"
Date: Thu, 05 Jun 2014 09:51:39 -0400

> Maybe just add an optional argument in find-lisp-object-file-name?

I'd be OK with that, yes.

> (defun show-elisp-src-at-point ()
>   (interactive)
>   (message (find-lisp-object-file-name (variable-at-point) 'defvar)))

This call to `message' is erroneous (e.g. if the file name contains % chars).
You can fix it with

   (defun show-elisp-src-at-point ()
     (interactive)
     (message "%s" (find-lisp-object-file-name (variable-at-point) 'defvar)))

At which point the `C-source' return value is not nearly as problematic.

> I don't think an extra value in help-enable-auto-load would be of any help
> in these kind of cases (i.e. when used programmatically).

Agreed, tho the caller could let-bind help-enable-auto-load (in effect
passing it an implicit additional argument).


        Stefan

Message #35 received at 17685 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 17685 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Guath <stefan <at> automata.se>
Subject: Re: bug#17685: 24.3.91.1; help-C-file-name failes to create temp
 buffer " *DOC*"
Date: Tue, 08 Feb 2022 11:11:07 +0100

martin rudalics <rudalics <at> gmx.at> writes:

> How about reserving an extra value for `help-enable-auto-load' which, if
> set, would trigger auto-creating the *DOC* buffer.

I've now done this in Emacs 29 -- it seemed the interface that made the
most sense (out of always reading DOC if we had the source, or a new
value for help-enable-auto-load).

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

Previous Next

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