[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17685: 126.96.36.199; help-C-file-name failes to create temp buffer " *D
bug#17685: 188.8.131.52; help-C-file-name failes to create temp buffer " *DOC*"
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 ()
(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
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).
On 5 jun 2014, at 09:48, martin rudalics <address@hidden> 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.