[Top][All Lists]

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

[AUCTeX-devel] About commonly used and "expert" macros/environments (was

From: Tassilo Horn
Subject: [AUCTeX-devel] About commonly used and "expert" macros/environments (was: auctex-devel Digest, Vol 103, Issue 2)
Date: Wed, 06 Nov 2013 09:03:48 +0100
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)

Mads Jensen <address@hidden> writes:

Hi Mads and all,

>> That should not be a criterion for being less helpful.  It might be
>> an argument to divide stuff into two classes, like file completion
>> does: you can still complete on ignored files if your prefix rules
>> out any non-ignored file.
> I like the idea about having some variable to discard some macros from
> the completion.

Yes, me too.  But I'm not sure which way to tackle that.  The cheapest
solution was to have a new defcustom `TeX-include-advanced-macros/envs'
which would either be t (include all commands) or a list of package
names whose advanced commands to include.  Then we also had a function

(defun TeX-include-advanced-macros/envs-p (style)
   ((null TeX-include-advanced-macros/envs) nil)
   ((listp TeX-include-advanced-macros/envs)
    (member style TeX-include-advanced-macros/envs))
   (t t)))

Using that, style files could do:

  ;; The commonly used macros and environments
  (TeX-add-symbols ...)
  (LaTeX-add-environments ...)

  ;; The stuff only expert users of a package will use
  (when (TeX-include-advanced-macros/envs "this-style")
    (TeX-add-symbols ...)
    (LaTeX-add-environments ...))

Does that sound reasonable to anyone?  If noone objects, I'll implement
it that way.

> Does somebody want to commit my patch? I'm not really sure if an
> average user will ever use \DeclareGraphicsRule, so somebody makes the
> executive decision.

If we go the route I've sketched above, I'm very happy to accept all
your patches that add missing macros/environments when the addition is
done like above.  And I'd also welcome patches adding that "common
macro" / "expert macro" split to existing packages.  (Of course, the
distinction what's commond and what's expert is a bit subjective.
Usually, I'd go with common is everything that's shown in a package's
quick intro or overview, in case it's documentation has something like


reply via email to

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