[Top][All Lists]

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

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

From: Arne Jørgensen
Subject: [AUCTeX-devel] Re: Make TeX-insert-macro behave intelligently on \usepackage
Date: Mon, 10 Oct 2005 22:07:31 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

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

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

>> 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 Jørgensen <>

reply via email to

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