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

On Wed, 3 Jan 2007, Hans Hagen wrote:

Aditya Mahajan wrote:

...

...

...

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?

dunno, depends on the texmf.cnf file

I am using the default texmf.cnf that ships with the stand-alone distribution. Mine says texmf-local/web2c/texmf.cnf progname = unsetprogname engine = unsetengine backend = unsetbackend texmf/web2c/texmf.cnf progname = unset engine = unset

...

...

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!

ancient ; and no warranty either

This is the one that ships with windows stand-alone distribution. I just reinstalled everything.

maybe the scripts path in texmf.cnf has no \\ appended (recurse)

There is // at the end of TEXMFSCRITPS and RUBYINPUTS, etc.in texmf/web2c/texmf.cnf But the file texmf-local/web2c/texmf.cnf did not have // at the end. I added it, but that did not change anything. kpsewhich texexec.rb still does not return anything.

anyhow, maybe it's about time to kick out kpsewhich and use luatools which is faster too and more clever

Ok. So for the time being, we will put 2context.vim in the same directory as the module. Assuming that the module ends up somewhere in tex/context/third/t-<whatever> kpsewhich will be able to find it. Once, luatools become available, we may choose a different packaging structure. To Mojca: 1) What should we name the module? I was thinking t-syn-vim.tex, that way, if someone uses a different highlighting engine, say scite, that module can be named t-syn-scite etc. (Hans, did you get the hint ;) 2) I will try to get the system call correct. If 2context.vim is in texmf-<whatever>/tex/context/third/t-syn-vim/ then, something like this should work \executesystemcommand{ texmfstart bin:vim -e (and other options) -c "source kpse:2context" ...etc...} We need to play around a bit to get " (quotes) to work inside a call to texmfstart. Right now, texmfstart eats the quotes. Aditya

concerning scite ... i wrote an xml export + module for that but cannot find back the related style and may even have lost the style

What about "stealing" scite's highlighting algorithm and include that one into a lua module? I don't know if that's possible though since I don't know in which language it has been implemented, but in case it was lua ... Mojca

Ok. So for the time being, we will put 2context.vim in the same directory as the module. Assuming that the module ends up somewhere in tex/context/third/t-<whatever> kpsewhich will be able to find it. Once, luatools become available, we may choose a different packaging structure.

That should also be OK. There's only one file anyway.

To Mojca: 1) What should we name the module? I was thinking t-syn-vim.tex,

I'm OK with that name, but perhaps t-syntax-vim, I don't like shortcuts, syn could stand for just about anything.

that way, if someone uses a different highlighting engine, say scite, that module can be named t-syn-scite etc. (Hans, did you get the hint ;)

If I'm/was thinking about the same thing as you are thinking ... ... then Hans will have to implement that anyway ;) Mojca

On Wed, 3 Jan 2007, Aditya Mahajan wrote:

\executesystemcommand{ texmfstart bin:vim -e (and other options) -c "source kpse:2context" ...etc...}

We need to play around a bit to get " (quotes) to work inside a call to texmfstart. Right now, texmfstart eats the quotes.

How does write18 handle quotes? Right now, on a command prompt this works fine texmfstart --verbose bin:vim -c "set nu" t-vim.tex but in a test file \executesystemcommand{texmfstart --verbose bin:vim -c "set nu" t-vim.tex} gives system(texmfstart --verbose bin:vim -c "set nu" t-vim.tex)...executed. Notice that the quotes '..' went missing. How to get this to run. I want texmfstart to run vim as vim -c "command" file How do I save these quotes from texmfstart? Aditya

On Wed, 3 Jan 2007, Hans Hagen wrote:

...

Basically need to esacpe the quote inside quote.

oh, so actually we should patch texexec to escape the tui stuff?

No, I think that texexec is working in an expeted manner. I did not clearly understand how it worked, and that is why the confusion. The module is finally ready. It works well for small snippets (<1000 lines). I have uploaded it to http://modules.contextgarden.net/t-vim I made a mistake while naming the module, so all the files are in t-vim.tar.gz directory instead of t-vim. Hopefully, this will not cause any trouble. The documentation is at http://dl.contextgarden.net/modules/t-vim.tar.gz/doc/context/t-vim/t-vim.pdf and a sample matlab and context pretty output at http://dl.contextgarden.net/modules/t-vim.tar.gz/doc/context/t-vim/t-vim-dem... The context output is very similar to what I see on the vim screen :) Aditya

On Thu, 4 Jan 2007, Hans Hagen wrote:

Aditya Mahajan wrote:

...

On Wed, 3 Jan 2007, Hans Hagen wrote:

...

...

Basically need to esacpe the quote inside quote.

oh, so actually we should patch texexec to escape the tui stuff?

No, I think that texexec is working in an expeted manner. I did not clearly understand how it worked, and that is why the confusion.

The module is finally ready. It works well for small snippets (<1000 lines). I have uploaded it to http://modules.contextgarden.net/t-vim I made a mistake while naming the module, so all the files are in t-vim.tar.gz directory instead of t-vim. Hopefully, this will not cause any trouble.

The documentation is at http://dl.contextgarden.net/modules/t-vim.tar.gz/doc/context/t-vim/t-vim.pdf

and a sample matlab and context pretty output at

http://dl.contextgarden.net/modules/t-vim.tar.gz/doc/context/t-vim/t-vim-dem...

The context output is very similar to what I see on the vim screen :) looks like there is a problem around line 35

%D \starttyping %D \definevimtyping [RUBY] [syntax=ruby] %D \stoptyping %D after which you can get ruby highlighting by %D \starttyping %D \startRUBY %D .... %D \stopRUBY %D \stoptyping

has funny colloring

Yes, vim does that. Any line starting with % is a comment. Of these, any line that starts with %D honors context command highlighting regions. When it sees a \starttyping syntax highlighting is switched off until the next \stoptyping. So, everything between a \starttyping and \stoptyping is in black (the default \maincolor). What I use is the the default vim colorscheme (by Nikolai Weibull). Mojca had made some improvements to the context highlighting, which had a few improvements (mp syntax highlighting inside \startMPcode \stopMPcode etc, C syntax highlighting inside \startC \stopC, and so on). I do not remember whether it took care of \starttyping. Redoing, vim syntax highlighting for context and metapost has been on my todo list for a long time. Someday the vim syntax highlighting rules will make sense to me. Aditya

On Wed, 3 Jan 2007, Mojca Miklavec wrote:

On 1/3/07, Hans Hagen wrote:

...

Aditya Mahajan wrote:

...

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

I don't think that using additional environmental variables makes sense either.

...

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

...

texmfstart --locate context.vim

works OK on linux and returns the proper path to the vim script.

It works ok here also, but kpse: expansion is not working. Try texmfstart bin:vim kpse:core-ver.tex and texmfstart bin:vim kpse:2context.vim Aditya

Mojca Miklavec wrote:

On 1/3/07, Aditya Mahajan wrote:

...

On Wed, 3 Jan 2007, Mojca Miklavec wrote:

...

...

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

texmfstart --locate context.vim

works OK on linux and returns the proper path to the vim script.

It works ok here also, but kpse: expansion is not working.

Try texmfstart bin:vim kpse:core-ver.tex and texmfstart bin:vim kpse:2context.vim

If I put 2context.vim into [texmf]/scripts/context/vim/2context.vim, then it doesn't work. If I put it into [texmf]/context/data/2context.vim, then it works.

Don't ask me about the reason.

ok, the reason is that kpse only knows a limited set of suffixes, and everything else is 'other text file' and that's what the data path is for in luatex i'll make this configurable (after all, we no longer have a hard coded kpse) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------