From: Stefan Guath <stefan@automata.se>
To: martin rudalics <rudalics@gmx.at>
Cc: 17685@debbugs.gnu.org
Subject: 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 [thread overview]
Message-ID: <C7BBA5AA-5460-46C2-B1F2-AEBAD6C3686E@automata.se> (raw)
In-Reply-To: <539020EA.6080307@gmx.at>
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
next prev parent reply other threads:[~2014-06-05 8:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 8:47 bug#17685: 24.3.91.1; help-C-file-name failes to create temp buffer " *DOC*" Stefan Guath
2014-06-04 13:15 ` Stefan Monnier
2014-06-04 14:08 ` Drew Adams
2014-06-04 14:21 ` Stefan Monnier
2014-06-05 6:46 ` Stefan Guath
2014-06-05 7:48 ` martin rudalics
2014-06-05 8:35 ` Stefan Guath [this message]
2014-06-05 8:45 ` martin rudalics
2014-06-05 9:00 ` Stefan Guath
2014-06-05 13:51 ` Stefan Monnier
2022-02-08 10:11 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C7BBA5AA-5460-46C2-B1F2-AEBAD6C3686E@automata.se \
--to=stefan@automata.se \
--cc=17685@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.