From: "Richard M. Stallman" <rms@gnu.org>
Cc: p.galbraith@globetrotter.net, wohler@newt.com, emacs-devel@gnu.org
Subject: Re: custom-set-variables fails to set variable
Date: Sat, 12 Nov 2005 16:21:52 -0500 [thread overview]
Message-ID: <E1Eb2oq-0002zW-6Y@fencepost.gnu.org> (raw)
In-Reply-To: <200511120441.jAC4fJI25860@raven.dms.auburn.edu> (message from Luc Teirlinck on Fri, 11 Nov 2005 22:41:19 -0600 (CST))
A more automatic solution could be: define-derived-mode
could automatically produce an autoload definition
of the defvar. That would solve the problem, right?
It is not normal for update-file-autoloads to generate
an autoload with no autoload cookie, but we could do that.
Unless I am confused, this also has the disadvantage that it is not
going to work for uses of define-derived-mode in third party packages.
You are right. So that approach won't work.
Meanwhile, another point occurs to me.
Why is the defvar that comes from the define-derived-mode
executed before the defcustom? Could that be solved
by putting the defcustom earlier in the file?
Another idea: replace the defvar with a put call that will put on a
variable-documentation property.
Yes, but both the manual and the automated solutions have the
potential for problems. Somebody supplying a defcustom may want a
tailor-made docstring for the defcustom, mentioning typical uses for
the hook and the defvar's docstring could overwrite that.
We don't want the automatically generated doc string to override
an explicit one, so perhaps the define-derived-mode should generate
(unless (get VAR 'variable-documentation)
(put VAR 'variable-documentation STRING))
next prev parent reply other threads:[~2005-11-12 21:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <11859.1131656026@olgas.newt.com>
[not found] ` <87lkzwxduk.fsf@olgas.newt.com>
[not found] ` <200511110043.jAB0hhc17895@raven.dms.auburn.edu>
2005-11-12 3:38 ` custom-set-variables fails to set variable Richard M. Stallman
2005-11-12 4:05 ` Luc Teirlinck
2005-11-12 4:49 ` Luc Teirlinck
2005-11-12 21:19 ` Juri Linkov
2005-11-12 4:41 ` Luc Teirlinck
2005-11-12 21:21 ` Richard M. Stallman [this message]
2005-11-12 23:36 ` Luc Teirlinck
2005-11-14 4:55 ` Richard M. Stallman
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1Eb2oq-0002zW-6Y@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=p.galbraith@globetrotter.net \
--cc=wohler@newt.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).