[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 20:33:41 +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:
> I am wondering if inserting independent arguments first and depending
> ones later should become a general rule.  If we do this differently
> for every macro the resulting inconsistency in the user interface
> might confuse the user.  But maybe I am taking this too far again.

I think you are right, but I don't think the problem is bigger than it
can be solved over time. IMO putting the independent arguments first
and dependent ones later should be the way to go in the future.

>> I have been thinking about more flexibel, beautiful and powerful ways
>> to do this. Could we use alist's for storing keyval options and their
>> values? and stuff like that. but none of them seems to be more
>> flexible, beautiful or powerful.
> 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?

> | +(defun TeX-arg-usepackage (optional)
> | +  "Insert arguments to usepackage."
> | +  (let ((TeX-file-extensions '("sty")))
> | +    (TeX-arg-input-file nil "Package")
> | +    (save-excursion
> | +      (search-backward-regexp "{\\(.*\\)}")
> | +      (let* ((package (match-string 1))
> | +            (var (intern (format "LaTeX-%s-options" package)))
> This scares me a bit.  I think we mostly try to stick with
> `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. 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). Maybe the symbol could be called something else that is not as
likely to be used by others -- maybe LaTeX-<package>-package-options?

> | +            (crm-separator ",")
> | +            (TeX-arg-opening-brace LaTeX-optop)
> | +            (TeX-arg-closing-brace LaTeX-optcl)
> | +            options)
> | +       (if (or (and (boundp var)
> | +                    (listp var))
> | +               (fboundp var))
> | +           (if (functionp var)
> | +               (setq options (funcall var))
> | +             (setq options (mapconcat 'identity (completing-read-multiple 
> "Options: " (symbol-value var)) ",")))
> AFAICS `completing-read-multiple' is not avaible on XEmacs.  Can you
> code around that?

I will definitely look into this before committing this.

Thanks very much for your comments!

Kind regards,
Arne Jørgensen <>

reply via email to

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