Uwe Stöhr wrote:
> Am 21.02.2012 22:09, schrieb Georg Baum:
>
>> this is far more complicated than what you implemented. Believe me, if it
>> was that easy I would have added verbatim support a long time ago.
>
> I think we could not support verbatim before as we had no feature to
> convert to.
OK, to be more precise: I would have implemented a correct conversion of
verbatim to ERT. But even that is much more complicated.
>>> + os<< "\n\\begin_layout Verbatim\n";
>>> + string const s = p.verbatimEnvironment("verbatim");
>>
>> The environment nesting in verbatimEnvironment() is not suitable for
>> verbatim environments. Instead, you need to implement exactly the same
>> algorithm as used by TeX for detecting the environment end. In order to
>> do this, you probably also need to temporarily change the cat codes in
>> the parser.
>
> Why not. I played around with all constructs that came into my mind and
> verbatimEnvironment does what I want.
> Can you give ma an example TeX code where my code fails?
Your test code in test-structure.tex fails already. LyX complains like this:
Paragraph ended in line 1032
Missing \end_layout.
The reason for this is probably that you did not follow Jean-Marcs advice to
use the context machinery.
If you want a more fancy test, try this:
\begin{verbatim}
\begin{foo}
\end{verbatim}
This will convert everything what follows to verbatim. If you look how
verbatimEnvironment() is implemented, you can also see why this is the case.
Andf if this works, there is more funny stuff, e.g.
\begin{verbatim}
foo
\end{verbatim} some stuff on the same line
which needs to be parsed differently, depending whether verbatim.sty is
loaded or not.
>> "\n\\end_layout\n\\begin_layout Verbatim\n";
>>> + } else
>>> + os<< *it;
>>
>> This test for consecutive space looks wrong. In a verbatim block you
>> should be able to write as many consecutive spaces (even at the end), and
>> LyX should output them as is.
>
> But it does. I only had to add this special code for the case it is at the
> end because of http://www.lyx.org/trac/ticket/8049
But this is exactly what I was telling! There is obviously a bug in LyX
which should be fixed in LyX, not in tex2lyx.
>> If this special treatment is really needed the
>> verbatim implementation in LyX looks wrong.
>
> What exactly?
Bug 8049 (but I did not know that it has a number).
>>> + os<< "\n\\end_layout\n\n";
>>> + p.skip_spaces();
>>> + skip_braces(p); // eat {} that might by set by LyX
>> behind comments
>>
>> skip_braces() is wrong.
>
> Why? We are now behind \end{verbatim} so if there are braces we can eat
> then, no?
No. They must be eaten iff LyX writes them.
Georg
