Emacs setup assistants
David Kastrup
dak at gnu.org
Thu May 20 03:25:23 EDT 2004
Juri Linkov <juri at jurta.org> writes:
> Per Abrahamsen <abraham at dina.kvl.dk> writes:
> > The idea is to skip info altogether, and write an texinfo reader.
> > This way, we could extend the texinfo format with tags needed for
> > wizards (or saints, or assistants).
>
> Why not use something more Lispish?
>
> (defsaint enable-multifile-documents
> (checkbox :format "%v Enable multifile documents." (not TeX-master))
> "When @LaTeX{} documents grow large, they are often split up in
> multiple files. One file is a "master" file, which includes a number
> of nested files. When formatting the document, you need to run
> @code{latex} on the master file. If you enable multifile support, AUC
> @TeX{} will automatically run @code{latex} on the master file, even if
> you invoke @kbd{C-c C-c} from one of the nested files. In order to do
> this, AUC TeX will prompt you for a name of a master file first time
> you edit a file, and insert the name in a comment at the end of the
> file."
> (require 'tex)
> (setq saint-on-next-function
> (lambda (customize-save-variable 'TeX-master
> (not (widget-value enable-multifile-parsing))
> "Saint"))))
>
> But then it looks very much like defcustom.
>
> So there is a more general question: why not extend Customize
> for a guided tour through options?
Because it does not lend itself to writing? For Texinfo, we have
modes that facilitate getting a nice, human-manageable document
source. We don't have that for some weird stuff of Lisp functions.
And this approach does not lend itself to decentralized translation
efforts: you need to translate an entire Emacs Lisp file, including
customizations, completely, or a translated version will break. In
contrast, my proposal would give a fallback for assisting on new
options when the current translation is not yet featuring it.
We'll get more people willing to manage and translate a Texinfo
document than the DOC strings of some Elisp file.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
More information about the XEmacs-Beta
mailing list