[dev-context] Script files for third party modules.

Aditya Mahajan adityam at umich.edu
Wed Jan 3 16:23:42 CET 2007


On Wed, 3 Jan 2007, Hans Hagen wrote:

> Aditya Mahajan wrote:
> > Hi Hans,
> >
> >   Mojca and I are writing a module that uses a vim script to highlight 
> > source code. What is the best way to "package" this module. That is, 
> > where should the script file go? The ideal location will be
> >
> > scripts/context/vim/macros/
> >
> > Are third party modules allowed to "pollute" the scripts/ directory?
> > 
> hm, never thought of it; i suppose it is ok that way
> > We have another concern while calling the script. We need to call vim 
> > using
> >
> >    vim [options] -c "source path-to-script/2context.vim" filename
> >
> > This command is called using \externalprogram. We do not want to 
> > hard code the location of path to the scirpt. Does it make sense to 
> > add VIMINPUTS environment variable to texmfstart, to reduce the search 
> > time?
> > 
> hm, maybe but adding a truckload of editor paths will also slow down; an 
> option is to add 'vim' as suffix someplace
> > Is there a way to locate the file in the texmf-tree and pass the 
> > arguments to another program? I copied 2context.vim to texmf-tree and
> >
> >    texmfstart --locate 2context.vim
> >
> > gives its location. However
> >
> >    texmfstart bin:vim kpse:2context.vim
> >
> > does not load the file. I get
> >
> > texmfstart version 2.0.2
> > kpse     : direct (forced)
> > locating '2context.vim' in program space 'context'
> > locating '2context.vim' in program space 'context' using format 'other 
> > text files' 2context.vim is not resolved using 'system' call: vim  2context.vim
> >
> > What is the correct way of finding something in the texmf-tree but 
> > outside program space 'context'?
> > 
> --program=yourtex

what should yourtex be in this case?

> but i wonder, isn't the vim stuff in the context tree? can kpse find it?

Aparantly not. Something seems to be broken.

        kpsewhich --version
        kpathsea version
        Copyright 2005 Karl Berry & Olaf Weber.
        There is NO warranty.  You may redistribute this software
        under the terms of the GNU General Public License.
        For more information about these matters, see the files named
        GPL and LGPL.

Notice no version number!

     kpsewhich texexec.rb

does not give anything.

    kpsewhich --debug=10 texexec.rb

gives
   ...[lots of lines]
   ...[ending with repeats of]
   kdebug:hash_shared_lookup(texexec.rb.tex) => (nil)
   kdebug:hash_shared_lookup(texexec.rb) =>
   e:\isoimage\usr\local\context\tex\texmf-local/scripts/context/ruby/
   e:\isoimage\usr\local\context\tex\texmf-local/scripts/context/ruby/

Notice that the complete path is not output. That is compare from

   kpsewhich --debug=10 core-ver.tex

which gives
   ...[lots of lines]
   kdebug:hash_shared_lookup(core-ver.tex) =>
   e:\isoimage\usr\local\context\tex\texmf-local/tex/context/base/
   e:\isoimage\usr\local\context\tex\texmf-local/tex/context/base/
   kdebug:hash_shared_lookup(core-ver.tex) =>
   e:\isoimage\usr\local\context\tex\texmf-local/tex/context/base/
   e:\isoimage\usr\local\context\tex\texmf-local/tex/context/base/
   e:\isoimage\usr\local\context\tex\texmf-local/tex/context/base/core-ver.tex

The last line is the location of the file, which is output to stdout. 
So even though kpsewhich is able to find the file in scripts/, it does 
not give any output. I do not know what is happening here. Is there a 
bug in kpsewhich? The binaries are from context stand alone 
distribution overwritten by pdftex-1.40.0-beta-20060213 binaries (I do 
not know where the kpsewhich binary came from, context stand alone or 
pdftex).


Aditya



More information about the dev-context mailing list