Bo Peng wrote:
>> 1) (what you want): Declare that it was never intended to swallow the
>> space. Then the current behaviour is buggy.
>
> Yes. I do consider this as a bug. A comment inset should not change
> the output of the original paragraph.
I think we all agree that the comment inset should not change anything
coming after it. The point where we differ is how to treat this behaviour.
>> 2) (what I think is correct): Realize that the current behaviour is a
>> mistake, but acknowledge that it is like that and implement the new
>> behaviour with a file format change and lyx2lyx support.
>
> What I can not see is where lyx2lyx is involved. Do you want to tell
> lyx: for format xxx, do not add {} before ' b', and for xxx+1, add it?
> Even for this scenario, lyx2lyx is not involved, only lyx.
No, I don't want to do that. On upgrade, lyx2lyx would simply go through all
comment insets, and remove a space that may be directly after the comment
inset. On downgrade, lyx2lyx would add a {} in ERT if there is a space
directly after the comment inset. That would not be difficult to code, we
have more complicated tasks already solved in lyx2lyx.
>> Since I would be very upset if an upgrade from 1.4.2 to 1.4.3 would
>> rearrange the output of e.g. a carefully crafted book.
>
> The only case this can affect the user is that he had this problem and
> changed his lyx file to
>
> a[comment]\ b
>
> so that he can force a blank between a and b. Adding {} will not
> change this.
Sure it will change the output, since the {} will prevent the space from
being swalloed.
> I would be really surprised that someone would
> *intentionally* write a[comment] b for an output of ab.
Me too, but consider the case where the space is there (unintentionally).
Then is suddenly appears in the output, the line is too full and gets
broken differently, resulting in an additional line in the paragraph,
resulting in a figure going to another page etc.
This scenario is IMO not as artificial as it may sound. In our lecture notes
we have several pages that are very sensitive to small changes, e.g.
because of a chapter with lots of figure, or another one with just figures.
>> Please don't commit anything until Jean-Marc is back. If he accepts 1)
>> the patch can go both in 1.4 and trunk, but if he does not we should
>> change the file format in trunk at the same time when the patch goes in.
>
> I can register the patch to bugzilla.
Good idea.
>> BTW, did you check what happens to the other note environments?
>
> lyxcomment does not generate latex output, so it is fine. Grayout
> works fine as well. I did not test other environments.
It would be great if you could. I know that this is boring, but I did such
work several times, and that did discover other bugs.
>> Maybe it is even better to remove the offending % and output \end{...} at
>> the end of the previous line?
>
> No. \end{comment} is required, and % is not involved in the processing
> of the ' b' line.
I understood from your original mail that the % was the reason for
swallowing the space, but if that is not the case then I think that the {}
solution is the best.
Georg
