>>>>> "Edmar" == Edmar Wienskoski <[EMAIL PROTECTED]> writes:
Edmar> No, that is not entirely true. Actually, the fact that "return"
Edmar> ends a layout is not even a concern (I can use alt-return
Edmar> instead of plain ret...) The problem, is that if you define
Edmar> the Scrap layout to be anything different than "Environment" or
Edmar> "Item_Environment" then each line in the code will be treated
Edmar> as a paragraph, and the output will have many empty
Edmar> lines. Example:
Well, each line in the code *is* a paragraph, so it is normal to treat
it as a paragraph...
Edmar> If I define the Scrap layout as an Environment, and environment
Edmar> name is "bar", I will get:
LaTeX> \begin{bar} <<test>>= j = i; i = i + 1; print(); @ \end{bar}
You mean an Item_Environment, right? A real environment should add the
empty lines too. As far as Item_Environment are concerned, you rely on
the fact that they are output as
\begin{foo}
\item aaa
\item bb
\end{foo}
But any developper could decide one day to change it to
\begin{foo}
\item aaa
\item bb
\end{foo}
because that does not make any difference for LaTeX (AFAIK) and is
perfectly valid. In short, you are relying on an undocumented feature
of LyX which is subject to change at any time.
Edmar> Which is the closest of the desired "Noweb>" output. The patch
Edmar> I provided will get rid of the \begin{} and \end{}, *if* you
Edmar> declare the environment name to be "dummy".
What you do here is add a backdoor to the definition of environments
in order to add a feature. This is definitely not the way to go. The
textclass definition format is already full of these ad hoc
modifications and they are a real pain.
I'd rather come up with a solution which works correctly in other
cases. For example, your problem is not different from the problem
encountered for LyX-Code environment. This environment as it stands is
a painful hack and we will have to do some clean up there anyway. So
why not come up with a generic solution?
Edmar> But the purpose of having a file that describes the layouts, is
Edmar> to make it easier to create different layouts with existing
Edmar> tools, isn't it ? That is what I did.
Sure, but you modified the syntax of textclass just for the sake of
having *one* textclass working. Defining a new LatexType would have
been a better solution, for example (but probably not the best).
Edmar> Eventually, we can duplicate all the latex classes, this is
Edmar> pretty easy to do, and the "Scrap" layout will not show up in
Edmar> the list, when the user selects standard
Edmar> "article/report/book/letter...", but only when defining the
Edmar> document as "web-article/web-report/web-letter..."
Edmar> If you all agree on this, I can go ahead and define the
Edmar> classes.
Yes, defining the classes is a good idea. Then we can add code to
lib/configure to detect whether noweb is installed and make the
classes available only when it makes sense.
JMarc
