On Mon, Sep 30, 2024 at 08:05:18PM +0200, Pavel Sanda wrote:
> On Sun, Sep 29, 2024 at 10:47:39PM +0200, Pavel Sanda wrote:
> > On Thu, Sep 26, 2024 at 11:10:04AM +0100, José Matos wrote:
> > > On Wed, 2024-09-25 at 11:54 +0200, Pavel Sanda wrote:
> > > > > The issue is that I see this even without changes tracking.
> > > >
> > > > Do you have some recipy to reproduce?
> > >
> > > No, I do not and that is bothering me. :-)
> >
> > Not that I have clue what is going on, but I think I do have recipy:
> >
> > 1. Checkout master at 475d8e643306 in some directory.
> > 2. Checkout branch 2.4.x at 2051bfed437fa in another directory.
> >
> > 3. Open user guides of both master and branch *in branch* (two tabs opened
> > within single window, both UGs are still in 2.4 format).
> > 4. Go to the section 6.10 of master UG. Copy footnote 6.11 from master UG
> > into the same spot of branch UG.
> > 5. Save branch UG.
> >
> > If you inspect branch UG via git diff you will see 4 unrelated newlines
> > in different part of UG and later the footnote itself (like in commit
> > e29cd17ceaf).
>
> And if you open UG again, disable CT, fix the typo in section B.9, enable CT,
> and save, the newlines are gone again. Like in commit 63dbd54e624...
Ok, I got some time to actually look in the mysterious dis/appearance of
newlines
in our .lyx fileformat and this is my current understanding:
The superfluous newline is coming from the beginning of Font::lyxWriteChanges
where it's uncoditionally written to ostream output.
Now, Font::lyxWriteChanges is called from Paragraph::write only when
font1(inherit_font, bparams.language) != (getFontSettings(bparams, i)).
When pasting footnote in CT mode in point 4 above, fonts in this condition
suddenly differ for the verbatim environment (but in completely different
part of the document - perhaps CT pasting changes something in
bparams.language?).
Now although these two fonts differ, no condition of specific members of fonts
in lyxWriteChanges is actually true and so the result is just "\n" automatically
written out.
One option how to fix is attached. Essentially output "\n" iff at least one
condition
returns something in lyxWriteChanges. The bit I am little unsure is whether
it's safe
to use ostringstream for any encoding of characters. But I see it being used in
other parts of bufferparams, so hopefully ok.
UG changes in bunch of places when saving with this patch, I did not check
whether our load machinery is robust against superfluous newlines.
I am spent for today, but if more eyes can double check, that would be good.
Pavel
diff --git a/src/Font.cpp b/src/Font.cpp
index 92308fd1d8..25f735af51 100644
--- a/src/Font.cpp
+++ b/src/Font.cpp
@@ -158,9 +158,9 @@ string const Font::latexSize() const
/// Writes the changes from this font to orgfont in .lyx format in file
void Font::lyxWriteChanges(Font const & orgfont,
- ostream & os) const
+ ostream & ret_os) const
{
- os << "\n";
+ ostringstream os;
if (orgfont.fontInfo().family() != bits_.family())
os << "\\family " << LyXFamilyNames[bits_.family()] << "\n";
if (orgfont.fontInfo().series() != bits_.series())
@@ -219,6 +219,9 @@ void Font::lyxWriteChanges(Font const & orgfont,
else
os << "\\lang unknown\n";
}
+
+ if (!os.str().empty())
+ ret_os << "\n" << os.str();
}
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
