[Top][All Lists]

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

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

From: Ralf Angeli
Subject: [AUCTeX-devel] Re: Full file names in style system
Date: Sat, 28 Jan 2006 00:11:24 +0100

* Ralf Angeli (2006-01-04) writes:

> * David Kastrup (2006-01-03) writes:
>> 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.

I've looked at this more thoroughly now and found that it doesn't
work.  But that's no problem because I know what you meant and can
construct working code.  Unfortunately it does not do what we need.
At least not if we want to distinguish styles for different file types
in a single variable; `TeX-active-styles' currently.  Styles will be
included with their extensions in this variable.  That means if we
pass such a style, e.g. "foo.sty", to `TeX-load-style' (and
subsequently to `TeX-load-style-file') we could achieve compatibility
with user-created style trees following the old pattern if we try to
load the file "foo.sty.el" first and if that does not succeed we strip
the .sty extension (or any other) and try to load "foo.el".

This leaves us with another part of the problem.  We have "foo.sty" in
`TeX-active-styles' and load foo.el.  Now foo.el is likely to contain
something like `(TeX-add-style-hook "foo" ...)'.  We'd have to map
"foo" to "foo.sty" somehow.  Of course we will run into trouble if
`TeX-active-styles' additionally contains "foo.bib", "foo.tex", etc.
Then it is impossible to decide which item "foo" should be mapped to.

Actually I am not really fond of trying to be compatible with older
AUCTeX versions in this respect.  If we implement these changes I'd
give the next release a version number of 12 and mark it as
incompatible with the old style system.  Of course it would be nice to
have some major new features apart from an incompatibility which would
warrant a new major version.


reply via email to

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