auctex-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AUCTeX-devel] Re: Make TeX-insert-macro behave intelligently on \usepac


From: Ralf Angeli
Subject: [AUCTeX-devel] Re: Make TeX-insert-macro behave intelligently on \usepackage
Date: Mon, 10 Oct 2005 21:42:12 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

* Arne Jørgensen (2005-10-10) writes:

> Ralf Angeli <address@hidden> writes:
>
>> I'd appreciate it if we could at least parse this stuff.  But this can
>> get kinda tricky with things like
>> \foo[bar,baz={Some%
>>   random crap.}]{blu}
>
> I'm not sure I'm following you -- why parsing it? In this case we are
> asking the user for the options?

Sorry, I was just taken away by the association I had.  The comment
was not actually meant as a direct answer to your statements but
rather a more general rambling about the problems with key=value
options.

I tried to make the parser aware of key=value options before but gave
up due to time constraints and a lack of backend in the style system
for storing them.  That's what you were talking about, namely the
proposal to use an alist.  This seems like a natural approach.  The
question then is how to integrate it (or not) with the style system.

>> `LaTeX-<package>' prefixes for functions and variables in style files,
>> but I don't know if we can be strict enough to have this as a
>> mandatory convention.
>
> It's not that mandatory at all.

It is if you are a consistency freak. (c:

> If it is not defined you will just be
> asked about options like you do today. So this won't break anything.
>
> Unless someone decides to put something completely different into the
> LaTeX-<package>-options symbol (for what i know nobody does that
> today).

I think it is not very likely that this happens either.  It's
basically a cosmetic issue of consistent naming.  I just briefly
looked through some style files and it doesn't seem to be a problem.

>> AFAICS `completing-read-multiple' is not avaible on XEmacs.  Can you
>> code around that?
>
> I will definitely look into this before committing this.

Thanks.  Caring for XEmacs-compatibility is actually a lot of fun.
After writing a really nice and clean chunk of code working in Emacs
you can be sure to have the opportunity to obfuscate it in all sorts
of ways to make it work on XEmacs. (c;

-- 
Ralf





reply via email to

[Prev in Thread] Current Thread [Next in Thread]