[Top][All Lists]

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

Re: [AUCTeX-devel] About commonly used and "expert" macros/environments

From: David Kastrup
Subject: Re: [AUCTeX-devel] About commonly used and "expert" macros/environments
Date: Fri, 08 Nov 2013 11:10:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Tassilo Horn <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>>>   (when (TeX-add-advanced-macros/envs-p "packagename")
>>>     (TeX-add-symbols ...)
>>>     (LaTeX-add-environments ...))
>> Uh, that interface does not seem to offer restrained completion (where
>> some commands are offered for completion only when no "ordinary"
>> commands fit completion any more).
> Yes, I know.  Admittedly, it's a poor-man's solution.
>> Worse, it does nothing for making restrained completion implementable
>> at a latter point of time.
> On the other hand, it doesn't make it any harder, too.  Anyway, I've
> reverted the changes.
> How about that: The arguments given to `TeX-add-symbols' and
> `LaTeX-add-environments' may also have the form
>   '(:pkg-name "foobar" <argspec as before>)
> with the meaning that foobar is an advanced macro/env of pkg-name.  Like
> with my previous patch, there would be a user option being a list of
> packages from which a user also wants to complete the advanced
> commands.

Personally, I'd just mark macros/environments as "expert" in some manner
without bothering to enable/disable them per-package.  Then when
creating completions/menus, the expert commands get filtered from the
visual set.

Do people think that there is some market for making expert commands
specifically more visible for selected packages?

> Then `TeX-complete-symbol', `TeX-insert-macro', and `LaTeX-environment'
> would need to be adapted to complete foobar only if
>   (1) the user has that advanced-stuff-list-option set to t or to a list
>       containing :pkg-name, or

One question is whether anybody will ever be tempted to use anything but
t or possibly nil (the "give me everything" crowd) here.

On the other hand, if the information is cheap to provide _and_ to
interpret, there does not seem much wrong with it.

>   (2) there are no other completions matching the current user input.
> Does that sound reasonable?  (Of course, all other usages of
> `TeX-symbol-list' and `LaTeX-environment-list' would need to be
> checked and maybe adapted, too.)

That might make it nicer to store the information elsewhere, such as a
property or hash list.  But then it is getting used in core functions
making use of those data structures, and having another non-trivial
lookup per element is undesirable.  So placing this information along
with the rest seems desirable.

David Kastrup

reply via email to

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