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

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

[Stefan Guath]

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?

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

[Stefan Monnier]

> 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

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

[Drew Adams]

> > 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)
  ...

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

[Stefan Monnier]

> 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

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

[Stefan Guath]

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@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

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

[martin rudalics]

 > 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

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

[Stefan Guath]

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@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

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

[martin rudalics]

 > (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

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

[Stefan Guath]

Ok, I understand!

On 5 jun 2014, at 10:45, martin rudalics <rudalics@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

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

[Stefan Monnier]

> 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

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

[Lars Ingebrigtsen]

martin rudalics <rudalics@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