Re: [AUCTeX-devel] Full file names in style system

[Ralf Angeli]

* David Kastrup (2006-01-03) writes:

> Ralf Angeli <address@hidden> writes:
>
>> you will get the following auto/style-test.tex.el:
>>
>> (TeX-add-style-hook "style-test.tex"
>>  (lambda ()
>>     (TeX-run-style-hooks
>>      '("graphicx.sty" :type package :options nil)
>>      "latex2e"
>>      "scrartcl11"
>>      '("scrartcl.cls" :type class :options ("11pt" "a4paper" "ngerman"))
>>      '("foo.tex" :type file))))
>
> Is the :type stuff actually necessary?  What it is used for?

It's not necessary and not yet used for anything.  The idea was to
make identifying the different types of entries easier.  For example
if you wanted to determine options of the documentclass you could just
look for the entry with :type class in `TeX-active-styles' instead of
having to parse all the cars in the list for a .cls extension.  So
yes, to some extent the information in :type is redundant.

>> Until now we had only strings in `TeX-active-styles' which made it
>> very easy to look for certain styles by means of regular expressions
>> (e.g. in case of `LaTeX-command-style').  With the scheme above this
>> will be more difficult because there will have to be a way to look
>> for partially matching property lists.
>
> We could just use several data structures, one for each property.  I

Yeah, maybe this will also be a result of sorting out the current
usage of `TeX-active-styles'.  At the moment all sorts of stuff is
dumped into it; included files and packages, package and document
options, the LaTeX engine, these obscure "art10", "scrartcl11",
etc. options, and probably other stuff.  It would probably be good to
use different variables for different purposes or use something like
the already proposed :type specifier for classifying the stuff.

> actually would prefer to use hash tables instead of lists: faster
> access.  However, regular expression matching would not really be
> feasible or at least efficient, then.  Could you remind me where we
> actually make use of it?  Maybe it can be done without them.

Hm, there is `LaTeX-command-style', `TeX-view-style',
`TeX-output-view-style', and `TeX-print-style'.  So basically the
stuff which uses `TeX-style-check'.

>> That means one should be able to say "do a certain action if option
>> foo is given for style bar".  The interface for the user could
>> probably allow for the specification of regular expressions for file
>> names and properties.  For example if you wanted to match all
>> KOMA-Script classes in connection with 11 or 12 point font size you
>> could specify ("\\`scr.+\\.cls\\'" :options "\\`1[12]pt\\'") Usually
>> one does not need complicated stuff like that but rather match a
>> single option of a single file but I don't consider this overly
>> user-friendly in any way.
>
> Who is bothered about the users?  We are working with internal
> interfaces here.

Not if you take the *-style options into account.  And I think it
would be nice to have an easy way for users to perform certain actions
if e.g. package foo was loaded with options bar and baz.

> I think that exiting autogenerated and user-created style trees will
> be common enough to make us want to support them.  So
> */graphicx.el should get used as fallback if */graphicx.sty.el can't
> be found.
>
> So we should use something like
> (let ((load-suffixes
>        (nconc
>          (delq nil
>            (mapcar (lambda(x) (unless (string= x "")
>                                       (conc ".sty" x)))))
>          load-suffixes)))
>   (load "graphicx"))
>
> to load the style file.

Looks feasible.

>> graphicx and babel are the packages I used for testing.  For the
>> transition all file-related style files will have to be renamed and
>> changed, of course.
>
> I'd like to avoid making this mandatory.  I think there are still
> externally maintained AUCTeX style files around, and it would be nice
> if they were not required to get renamed for basic functionality.

Well, how do you want to distinguish the style file for foo.tex from
the one for foo.sty then?

-- 
Ralf