Hi everybodyoy Hi Aditya I like your t-vim module. I think it's a nice concept not te reinvent the wheel and to take advantage of the hundreds of syntax files of the vim contributors. 1) You have »Add line numbers« on your TODO list. What's the progress? 2) To set the font size I do the following, is there a better solution like bodyfont=xyz for definetyping or is it just fine like this? \definevimtyping [PHP] [ syntax=php, before={\switchtobodyfont[small]}, ] Marco
On Sat, 19 Feb 2011, Marco wrote:
I like your t-vim module. I think it's a nice concept not te reinvent the wheel and to take advantage of the hundreds of syntax files of the vim contributors.
1) You have »Add line numbers« on your TODO list. What's the progress?
No. I will look into them. I think that I should just be able to plug in ConTeXt's line numbering mechanism.
2) To set the font size I do the following, is there a better solution like bodyfont=xyz for definetyping or is it just fine like this?
\definevimtyping [PHP] [ syntax=php, before={\switchtobodyfont[small]}, ]
I think that the best idea is to add a style=..., and color=..., key. In fact, I have added these keys to t-filter module. If you get the latest version of the module from github[1], then you should be able to say: \definevimtyping [PHP] [syntax=php, style={\switchtobodyfont[small]\setupinterlinespace}, ] I will upload a new version soon. Aditya [1]: https://github.com/adityam/filter/blob/dev/t-filter.tex PS: The style=.. and color=... attributes only work with MkIV. I need to think of a good way to get them to work in MkII.
On 2011-02-21 Aditya Mahajan
1) You have »Add line numbers« on your TODO list. What's the progress?
No. I will look into them. I think that I should just be able to plug in ConTeXt's line numbering mechanism.
I like the »just« in your sentence :) That would be awesome.
2) To set the font size I do the following, is there a better solution like bodyfont=xyz for definetyping or is it just fine like this?
\definevimtyping [PHP] [ syntax=php, before={\switchtobodyfont[small]}, ]
I think that the best idea is to add a style=..., and color=..., key.
ACK
In fact, I have added these keys to t-filter module. If you get the latest version of the module from github[1],
done
then you should be able to say:
\definevimtyping [PHP] [syntax=php, style={\switchtobodyfont[small]\setupinterlinespace}, ]
That works/looks nice.
PS: The style=.. and color=... attributes only work with MkIV.
That's fine for me. Regards Marco
On Tue, 22 Feb 2011, Marco wrote:
On 2011-02-21 Aditya Mahajan
wrote: 1) You have »Add line numbers« on your TODO list. What's the progress?
No. I will look into them. I think that I should just be able to plug in ConTeXt's line numbering mechanism.
I like the »just« in your sentence :) That would be awesome.
Check the latest dev version of t-vim. https://github.com/adityam/filter/blob/dev/t-vim.tex I have not documented all the details, but the example at https://github.com/adityam/filter/blob/dev/tests/vim/line.tex should get you started. Aditya
On 2011-02-22 Aditya Mahajan
Check the latest dev version of t-vim. https://github.com/adityam/filter/blob/dev/t-vim.tex
Brilliant. Works like a charm. I stumbled over one thing: When set directory=tmp the temporary files are sent to the tmp directory except the md5 hashes of external file code, these are put in the working dir. Example: %%% t.tex %%% \usemodule [vim] \definevimtyping [CON] [ syntax=context, directory=tmp, ] \starttext \typeCONfile {t.tex} \startCON % empty \stopCON \stoptext %%%%%%%%%%%%% Is it possible to convince the context script to remove the temporary stuff when called with the --purgeall option? Thanks for your work. Regards Marco
On Wed, 23 Feb 2011, Marco wrote:
I stumbled over one thing: When set directory=tmp the temporary files are sent to the tmp directory except the md5 hashes of external file code, these are put in the working dir.
The md5 hashes are in the same directory as the file. So, in case you are including a file from the current directory, the md5 hash will also be there. So, the easiest solution is to move (or perhaps simlink) the file to the temporary directory. Then you can include the file tmp/t.tex and the md5 hash will be created in the tmp directory.
Is it possible to convince the context script to remove the temporary stuff when called with the --purgeall option?
I will look into that. I guess that the easiest way out is that, instead of using .vimout extension, I use .tmp extension. Then, all the temporary files will be removed by --purgeall. Aditya
On 2011-02-23 Aditya Mahajan
The md5 hashes are in the same directory as the file. So, in case you are including a file from the current directory, the md5 hash will also be there.
So it's on purpose. I wasn't sure about that.
So, the easiest solution is to move (or perhaps simlink) the file to the temporary directory. Then you can include the file tmp/t.tex and the md5 hash will be created in the tmp directory.
It will probably work, but is not a nice solution in my opinion. It looks strange that the document includes files from the tmp directory. From a tmp directory I expect to be able to delete the content without any effects. Anyway, I don't really care, since I usually don't delete the temporary files.
Is it possible to convince the context script to remove the temporary stuff when called with the --purgeall option?
I will look into that. I guess that the easiest way out is that, instead of using .vimout extension, I use .tmp extension. Then, all the temporary files will be removed by --purgeall.
I don't think so. AFAIK --purgeall only deletes .tmp files with the basename as the document itself. I think it would make sense to convince --purgeall to be more grabby and to remove all .tmp files in the working dir + all files in the »directory« dir (here tmp). But I'm not sure about possible displeasing side effects, though. Regards Marco
On Wed, 23 Feb 2011, Marco wrote:
So, the easiest solution is to move (or perhaps simlink) the file to the temporary directory. Then you can include the file tmp/t.tex and the md5 hash will be created in the tmp directory.
It will probably work, but is not a nice solution in my opinion. It looks strange that the document includes files from the tmp directory. From a tmp directory I expect to be able to delete the content without any effects.
I do not make that assumption in t-vim. Currently there is no way to specify the output directory to mtxrun --ifchanged. So, the only way that I can implement this feature is to either manually copy the input file, or manually copy the md5 file. I do not think that either of these options is worth the trouble.
Is it possible to convince the context script to remove the temporary stuff when called with the --purgeall option?
I will look into that. I guess that the easiest way out is that, instead of using .vimout extension, I use .tmp extension. Then, all the temporary files will be removed by --purgeall.
I don't think so. AFAIK --purgeall only deletes .tmp files with the basename as the document itself.
I think it would make sense to convince --purgeall to be more grabby and to remove all .tmp files in the working dir + all files in the »directory« dir (here tmp). But I'm not sure about possible displeasing side effects, though.
I am not sure what you want. Do you want context --purge filename to remove all the temp files that t-vim creates, or do you want context --purgeall to delete all the files created by t-vim that reside in the current directory? Aditya
On 2011-02-23 Aditya Mahajan
[...] I do not think that either of these options is worth the trouble.
No, definitely not.
I am not sure what you want.
Do you want [...]
context --purgeall
This will probably be difficult to implement, since the complete directory tree has to be scanned to find xyz-externalfilter-abc-X.___ remains. However context --purgeall filename should remove all temporary files belonging to the document like filename-externalfilter-CON-0.tmp % not removed filename-externalfilter-CON-0.tmp.md5 % not removed filename-externalfilter-CON-0.vimout % not removed So after the project is done one can run context --purgeall filename to get a clean directory structure without having to archive 30 temporary files. Regards Marco
On Wed, 23 Feb 2011, Marco wrote:
Do you want [...]
context --purgeall
This will probably be difficult to implement, since the complete directory tree has to be scanned to find xyz-externalfilter-abc-X.___ remains.
Actually, `context --purgeall` deteles all the files with .tmp and .md5 extension in the current directory. Only the .vimout files remain.
However context --purgeall filename
should remove all temporary files belonging to the document like
filename-externalfilter-CON-0.tmp % not removed filename-externalfilter-CON-0.tmp.md5 % not removed filename-externalfilter-CON-0.vimout % not removed
So after the project is done one can run context --purgeall filename to get a clean directory structure without having to archive 30 temporary files.
Why not simply run `context --purgeall` (no filename)? I will check how to ensure that .vimout files are also removed. The t-gnuplot module does something similar. So, perhaps I can borrow code from that. Aditya
On 2011-02-23 Aditya Mahajan
Actually, `context --purgeall` deteles all the files with .tmp and .md5 extension in the current directory. Only the .vimout files remain.
Does it on your system? Not on mine. If I compile the example posted earlier in the thread and execute context --purgeall afterwards, the files t-externalfilter-CON-0.tmp.md5 and t.tex.md5 still remain.
Why not simply run `context --purgeall` (no filename)?
See above. Regards Marco
On Wed, 23 Feb 2011, Marco wrote:
On 2011-02-23 Aditya Mahajan
wrote: Actually, `context --purgeall` deteles all the files with .tmp and .md5 extension in the current directory. Only the .vimout files remain.
Does it on your system? Not on mine. If I compile the example posted earlier in the thread and execute context --purgeall afterwards, the files
t-externalfilter-CON-0.tmp.md5 and t.tex.md5
still remain.
You are right. Only the .tmp files are removed. @Hans: Can I somehow "register" temporary files that will be later removed by `context --purgeall`? Aditya
On 23-2-2011 5:54, Marco wrote:
On 2011-02-23 Aditya Mahajan
wrote: [...] I do not think that either of these options is worth the trouble.
No, definitely not.
I am not sure what you want.
Do you want [...]
context --purgeall
This will probably be difficult to implement, since the complete directory tree has to be scanned to find xyz-externalfilter-abc-X.___ remains. However
you can register to-be-cleaned-up temp files with luatex.registertempfile(name) (namespace might change at some point) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, 23 Feb 2011, Marco wrote:
context --purgeall filename
should remove all temporary files belonging to the document like
filename-externalfilter-CON-0.tmp % not removed filename-externalfilter-CON-0.tmp.md5 % not removed filename-externalfilter-CON-0.vimout % not removed
So after the project is done one can run context --purgeall filename to get a clean directory structure without having to archive 30 temporary files.
I don't know how to implement this functionality and still provide a working pdf. To save time, t-vim (actually t-filter with continue=yes) runs the external filter only in the first run; in the subsequent runs the cached file is used. So, if I want to delete the temporary files, they must be deleted in the last run. Right now, there is no means of detecting the last run in MkIV. In MkII, we can force a final run with --final, but there is no means to detect that run. Even if the mode could be detected, asking context to delete temporary files forces another run, so the attachments will be missing in the final run. I am happy to provide the 'purge temp files' as a MkIV only feature, but I don't know how to force (and detect) a final run in MkIV. Aditya
On 2011-02-26 Aditya Mahajan
So after the project is done one can run context --purgeall filename to get a clean directory structure without having to archive 30 temporary files.
I don't know how to implement this functionality and still provide a working pdf.
No problem. I'm very satisfied with the module at this state. It would just be a nice-to-have feature.
To save time, t-vim (actually t-filter with continue=yes) runs the external filter only in the first run; in the subsequent runs the cached file is used. So, if I want to delete the temporary files, they must be deleted in the last run. Right now, there is no means of detecting the last run in MkIV.
The only thing that comes to my mind is to delete the files (of course only when --purgeall is set) after *every* run. That's quite inefficient (since vim is run every time again) but it would produce correct ouput and delete the files.
Even if the mode could be detected, asking context to delete temporary files forces another run,
I don't understand the reason behind this behaviour. Does it make sense? Marco
On Sun, 27 Feb 2011, Marco wrote:
To save time, t-vim (actually t-filter with continue=yes) runs the external filter only in the first run; in the subsequent runs the cached file is used. So, if I want to delete the temporary files, they must be deleted in the last run. Right now, there is no means of detecting the last run in MkIV.
The only thing that comes to my mind is to delete the files (of course only when --purgeall is set) after *every* run. That's quite inefficient (since vim is run every time again) but it would produce correct ouput and delete the files.
The next version of t-filter will name the generated files as: \jobname-temp-<filtername>.<filterextension> and these files will be deleted by context --purge (in the next beta). Note that this will **not** delete the files in the temp directory. Neither will it delete "filename.ext.md5" if you use \type<vim>file{filename.ext} Perhaps, in the future, it might be better to store the md5 sums in the tuc files; but, right now, that is a low priority feature. Aditya
participants (3)
-
Aditya Mahajan
-
Hans Hagen
-
Marco