Martin Vermeer wrote:
On Wed, Oct 24, 2007 at 12:51:00AM +0200, Dov Feldstern wrote:
But anyhow, IMO both r21153 and r21121 should be reverted. I think it's
best that we leave ERT out of this, at least for now. I don't really see
what we gain by making it use the "verbatim" layout --- the code being
replaced in r21121 is well encapsulated, I don't think that making it
use a more general mechanism gives us anything. And besides, ERT is a
very special case, and I think that involving it in something more
generalized is just asking for trouble...
Well, yes. But the code simplification is worth it I think.
Code simplification is *always* worth it.
Fact of the
matter is that this part of the code is so complex now that _any_ change
will produce surprises. Not good. I am happy that Abdel is looking into
this.
Well, I am not sure I'll have the energy to touch at TeXOnePar(); this
beast is 360 lines of code!!!
Beyond that, it seems like the "verbatim" layout itself --- or its use
in custom insets --- requires more thought and/or work. Perhaps
collecting a few examples of where it would be useful (URL, Listings,
...) can help figuring out how it should work...
Haven't looked at Listings yet... should I?
I _hope_ the encoding problem was the only one remaining... can you say
'spaghetti'?
It wasn't so bad in the end, was it? ;)
I circumvented the spaghetti rather than addressing it ;-/ "Not good"
again. This is often what happens: a new layer of code is piled on top,
and the "wart" gets encapsulated.
Yep, a lot of LyX source code is like this. People adding code to
methods instead of encapsulating new code in new smaller methods...
We should put a hard rule that anyone adding more than 10 lines of code
to a method should do so in a new method. Or is it in the coding rules
already?
Abdel.
