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

[David Kastrup]

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