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

[Arne Jørgensen]

Ralf Angeli <address@hidden> writes:

> * 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.

OK. That makes sense. Keyval's can be a nightmare in applications, but
in the application called LaTeX I really like them :-)

> 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.

It's of course easy to store a given keyval in an alist, but
representing all possible keyval's in an alist is de facto impossible.
That's why I think I have found a good trad off for this particular
problem.

>>> `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:

Well, I tend to be a consistency freak, but I also try to be
pragmatic.

>> 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.

Another solution would be to provide a hook and have the style file
add a function to the hook and after wards run the hook. Or something
similar. But I think that will end up being to complicated: clearing
the hook again what about the simple case where there is just a list
of options, etc.

I think I will go for my first solution but use the
LaTeX-<package>-package-options symbol instead. I don't suspect it
will ever result in problems (other than people wanting to do the
right thing in a wrong way).

>>> 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;

Now there's a trip down memory lane. I haven't had as much fun since
... well ... never mind.

Kind regards,

     /arne
-- 
Arne Jørgensen <http://arnested.dk/>