Re: [Vim-latex-devel] Path expansion

[Srinath A. <sri...@gm...>]

Hi Christian,

On 3/28/06, Christian Ebert <bla...@gm...> wrote:
> r1005 works -- up to a certain extent:
>
> 1. It almost freezes vim; symptoms:
>
> a) It takes ages (ca. 20 secs) to display the explorer.
>
> b) Reaction to pressing eg. "C" or "?" takes about the same
> amount of time.
>
> c) Choosing a file with <CR> works instantly.
>
> d) What does "C" actually do? I don't see a difference.
>

It looks like maybe your setting of Tex_ImageDir points to a directory
with a _lot_ of files. Basically, all of these symptoms point to the
function FB_DisplayFiles() taking a lot of time. This function basically
does a glob('*'), i.e, gets a list of all files and then "filters" them
according to FB_AllowRegexp and FB_RejectRegexp. This function is in
~/.vim/plugin/filebrowser.vim, which ships with latex-suite. Its
actually a small function, so you could if you want take a look at it.

The most probable cause of the slow-down is the FB_Strntok() function,
which FB_DisplayFiles() files uses to get the i^th line of the <NL>
seperated string returned by glob('*'). If the string is huge, the time
it takes to split the list grows exponentially. I tested that on my
computer, if I say:

    :call FB_OpenFileBrowser('c:/WINDOWS/system32')

which contains about 2200 files, then the time it takes is around 20
seconds or so. So if you have on the order of these many files then it
will take a lot of time.

The maps are:
    C: display the files in the current directory. i.e, if you do
        :cd /some/dir
       and then press "C" it will display the contents of /some/dir.

    ?: Basically expands the help section. Unfortunately, since I wrote
       it very inefficiently, it also completely re-reads and re-parses
       the file list.

Both these functions call FB_DisplayFiles().

I remember that in another place in latex-suite, I got a very
significant speed up by using stridx() rather than *Strntok(). Maybe
thats the way to go here.

> [ collect files with python? ]
>
??

> 2. Feature proposal:
>
> At the moment it inserts the relative path. I might not be the
> only one who puts (links to) the image file in $TEXINPUTS (that's
> what it's for after all) or (less friendly on resources) declares
> \graphicspath. That way you can move around your source-file and
> don't have to worry about paths. Wouldn't it make sense to have
> an option to get just the basename (w/o suffix) of the image? --
> Unless that's what's "C" for.

No thats not what C is for... This seems like an easy thing to add
though... I'm personally do not use this feature of latex though, so
you'll have to explain this in a little bit more detail to have it
become a feature.

HTH
Srinath