Can anybody tell me what's the deal with the interface of
`TeX-search-files-kpathsea'? A few months ago I already added a
FIXME comment about it being inconsistent with `TeX-search-files' and
now I found a real bug related to it.
When one tries to insert a \usepackage macro, `LaTeX-arg-usepackage'
will let-bind `TeX-file-extensions' to '("sty"). Then (in
`TeX-arg-input-file') `TeX-search-files' will be called with that
value as argument for the EXTENSIONS parameter. `TeX-search-files'
will pass that value on to `TeX-search-files-kpathsea' also as the
EXTENSIONS parameter. But it is not used as a list of extensions.
Rather its car is used as a format key for looking up some extensions
mapped in `TeX-kpathsea-format-alist'. Apart from that construction
being completely insane, in this case it leads to a `kpsewhich
-expand-path=' call (i.e. no argument for -expand-path is supplied)
because there is no entry for "sty" extensions in
`TeX-kpathsea-format-alist'. A failing kpsewhich call alone would not
be so problematic but when this happens `TeX-kpathsea-path-delimiter'
is set to nil and the kpathsea-based search will be disabled globally.
I found all of this while trying to do a completion with TAB on
"babel" after a `C-c RET usep TAB RET'. The said thing is that the
fact I noticed the problem means that `TeX-search-files' without the
kpathsea-based search does not find babel.sty. Duh.
Okay, in order to fix the former bug I can add a
("sty" "${TEXINPUTS}" '("sty"))
to `TeX-kpathsea-format-alist', but I am not really feeling
comfortable with this because it is a misuse of the variable and the
interface of `TeX-search-files-kpathsea'. Sooner or later we will
have to do this right.
--
Ralf
_______________________________________________
auctex-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/auctex-devel
