Tassilo Horn <[email protected]> writes: > David Kastrup <[email protected]> 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 _______________________________________________ auctex-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/auctex-devel
