Hi,
I tried the t-vim module today and I had a line-break problem with \inlineX. I
found the thread started by Peter Münster (last week). So I downloaded the
last context beta and this problem is gone.
But I got another problem : there is an unwanted additional space at the
begining of the \inlineX content.
See this minimal example (copy paste from Peter Münster mail):
\usemodule[vim]
\definevimtyping[C][syntax=c]
\starttext
bla \inlineC{void func(void)} bla
\stoptext
Thanks for help.
--
Romain Diss
On Wed, 21 Sep 2011, Romain Diss wrote:
I tried the t-vim module today and I had a line-break problem with \inlineX. I found the thread started by Peter Münster (last week). So I downloaded the last context beta and this problem is gone.
But I got another problem : there is an unwanted additional space at the begining of the \inlineX content.
See this minimal example (copy paste from Peter Münster mail):
\usemodule[vim] \definevimtyping[C][syntax=c] \starttext bla \inlineC{void func(void)} bla \stoptext
\ReadFile introduces a spurious space when reading the file! Here is a minimal example (compare the output of \ReadFile and \input): \startbuffer[test] {\bf bold} \stopbuffer \savebuffer[test][test] \starttext »{\bf bold}« \endlinechar\minusone %to prevent line break after reading file »\ReadFile{\jobname-test.tmp}« »\input\jobname-test.tmp\relax« \stoptext t-vim uses \ReadFile internally and hence inherits the bug. Aditya
On Wed, 21 Sep 2011, Romain Diss wrote:
Aditya Mahajan wrote:
\ReadFile introduces a spurious space when reading the file! (...) t-vim uses \ReadFile internally and hence inherits the bug. Is this a long known bug which nobody can solve
No, I just noticed this.
or is it possible to solve the problem ?
\def\InputFile#1{\input#1\relax} \setupvimtyping[readcommand=\InputFile] Aditya
On Wed, 21 Sep 2011, Aditya Mahajan wrote:
On Wed, 21 Sep 2011, Romain Diss wrote:
Aditya Mahajan wrote:
\ReadFile introduces a spurious space when reading the file! (...) t-vim uses \ReadFile internally and hence inherits the bug. Is this a long known bug which nobody can solve
No, I just noticed this.
In file-res.mkvi change \long\def\dodoreadfile#true#false% - {#true + {#true% \relax \normalinput{\readfilename}% \relax} Aditya
On tue, 22 Sep 2011, Aditya Mahajan wrote:
In file-res.mkvi change
\long\def\dodoreadfile#true#false% - {#true + {#true% \relax \normalinput{\readfilename}% \relax} This change does nothing here but the following works:
\def\InputFile#1{\input#1\relax} \setupvimtyping[readcommand=\InputFile]
Another not so linked question: what is the .mkvi extension for (in file-
res.mkvi)? The future of mkiv?
--
Romain Diss
On Thu, 22 Sep 2011, Romain Diss wrote:
On tue, 22 Sep 2011, Aditya Mahajan wrote:
In file-res.mkvi change
\long\def\dodoreadfile#true#false% - {#true + {#true% \relax \normalinput{\readfilename}% \relax} This change does nothing here but the following works:
You also need to regenerate the format.
\def\InputFile#1{\input#1\relax} \setupvimtyping[readcommand=\InputFile]
Another not so linked question: what is the .mkvi extension for (in file- res.mkvi)? The future of mkiv?
Yes. This allows you to write symbolic variable names (#true, #false) rather than numeric variables (#1, #2). I think this is documented in the mkiv manual. Aditya
On tue, 22 Sep 2011, Aditya Mahajan wrote:
This change does nothing here but the following works: You also need to regenerate the format. Done... and it works of course! So obvious but I forgot to do it.
Another not so linked question: what is the .mkvi extension for (in file- res.mkvi)? The future of mkiv?
Yes. This allows you to write symbolic variable names (#true, #false) rather than numeric variables (#1, #2). I think this is documented in the mkiv manual. Ok thank you very much for all these informations.
Nevertheless, I made some search on the wiki and I didn’t found much about
mkvi. It only says that the syntax is different.
I also made a search with 'pdfgrep' on all the context documents, examples,
magazines, manuals... and I found nothing.
Is the mkiv manual you mentioned something very recent?
All the best.
--
Romain Diss
participants (2)
-
Aditya Mahajan -
Romain Diss