auctex-devel
[Top][All Lists]
Advanced

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

[AUCTeX-devel] Interface of kpathsea file search


From: Ralf Angeli
Subject: [AUCTeX-devel] Interface of kpathsea file search
Date: Wed, 23 Nov 2005 13:56:30 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

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





reply via email to

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