[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: Tassilo Horn
Subject: Re: [AUCTeX-devel] About commonly used and "expert" macros/environments
Date: Fri, 08 Nov 2013 12:32:30 +0100
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)

David Kastrup <address@hidden> writes:

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

Well, I do think so, and that's probably the norm.  I mean, even the
experts take advantage of only the advanced stuff of some packages and
are normal users of other packages.  (And that might also depend on the
document one writes.)

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

I think it's 

--8<---------------cut here---------------start------------->8---
(delq nil
      (mapcar (lambda (entry)
                 ((stringp (car entry) entry))
                 (TeX-use-expert-commands (cdr entry))
                 (t nil)))
--8<---------------cut here---------------end--------------->8---


--8<---------------cut here---------------start------------->8---
(delq nil
      (mapcar (lambda (entry)
                 ((stringp (car entry) entry))
                 ((or (eq t TeX-use-expert-commands)
                      (and (member (car entry) TeX-use-expert-commands)))
                  (cdr entry))
                 (t nil)))
--8<---------------cut here---------------end--------------->8---

It's (length TeX-use-expert-commands) times more expensive, but only if
you've set it to a list, so the gimme-all-user wouldn't have to pay.
And I don't think anybody will have it set to a list of more than, say,
10 packages.

>>   (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.

Another reason for not using a separate data structure is that this
would force a separation for adding a macro/env and declaring it


reply via email to

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