Re: Regressions in 2.4 xhtml export [was: TESTING Tarballs for 2.4.0]

[Thibaut Cuvelier]

On Mon, 20 May 2024 at 15:50, Pavel Sanda  wrote:

> On Mon, May 20, 2024 at 03:24:30AM +0200, Thibaut Cuvelier wrote:
> > > InsetInfo shortcuts export to xhtml is borken compared to 2.3.
> > >
> > > In 2.3 we exported: Ctrl+N
> > > In 2.4 we expor: Ct+r+l+++N
> > >
> > > Thibaut, I guess this is due to new xml routines, could you have a
> look?
> > >
> >
> > Actually, it was due to the refactoring for direction in HTML5. I have
> > pushed 7cfe36e6aa4460ae8641cd36f4aab5f013390326 and
> > e3f2b10842cdc808e9f2bf235692f283009d3734 to fix that. This could make it
> to
> > 2.4.0, as it is a bit serious.
>
> I vote for 2.4.0 as well, the fix is restricted to xhtml code which
> shows regression anyway.
> Riki?
>
> > Related issue:
> >
> > When exporting the document (User's guide) as XHTML (I haven't configured
> > LaTeX with my development LyX), I am repeatedly getting this message:
> >
> > Warning: No bibliography processor found!
> > 
> > The bibliography processor requested by this document (bibtex) is not
> > available and no appropriate alternative has been
> > found. No bibliography and references will be generated.
> > Please fix your installation!
> >
> > The problem is that it appears repeatedly, meaning more than 10 times for
> > the user's guide at HEAD, apparently at each call to Inkscape to
> transform
> > SVGZ to PNG.
>
> Seems as two independent problems to me. Isn't it that you actually miss
> both svg converter and bibtex?
>

The problem is that LyX tells me there is a problem more than 10 times for
one document, 10 times the same error, with a modal window that seems to
block further processing of the document. I can just set the PATH in LyX'
configuration for these messages not to appear any longer, but they
shouldn't be that present if you haven't configured LaTeX. In other words,
my only complaint is about the number of errors that LyX shows the user, a
single occurrence would be better.


> > > - nested bullet points in listings shifted by an inch and overlap with
> > > text - e.g. section 2.8, 3.1.4, 3.7.6 etc
> > >
> >
> > That's both a CSS and an HTML issue: CSS for the subitems (like Ctrl in
> > 2.8), HTML for continuing items (like Alt in 2.8). For the CSS part,
> adding
> > this rule seems to help:
> >
> > li.labeling_item ul,  li.labeling_item ol {
> >   text-indent: 0;
> >   margin-left: -5em;
> > }
> >
> > However, the result with nested lists is still very poor (with ".."
> being a
> > subitem to Home and End):
> >
> > [image: image.png]
>
> Not great indeed, but better than the current situation.
>
> > The problem is that this is configured in most layouts (HTMLStyle block),
> > so it is painful to fix.
> >
> > The best solution in the long term, in my opinion, is to switch to HTML
> > definition lists, which is semantically correct (while the current output
> > is not a good use of lists). It mostly works out of the box, with no CSS
> > changes. I believe the C++ changes would be quite minimal, but it would
> > break any custom CSS. I am attaching an excerpt from the User's guide:
> > `UserGuide_list.xhtml` for the current output, `UserGuide_list -
> > Copy.xhtml` for my proposed refactoring. The result is quite close to
> what
> > we have in LyX. I bet this change should be delayed to 2.4.1, as it might
> > break a bit more, or even 2.5 if we consider this kind of change
> breaking.
>
> Riki, might want to chime in here as he was behind original xhtml design.
> I find switch to html lists conceptually better, though they are visually
> somewhat distinct - label is on it's own line AFAICS.
>

That's fixable, for instance
https://stackoverflow.com/questions/1713048/how-to-style-dt-and-dd-so-they-are-on-the-same-line.



> When it comes to timing:
> - CSS change could go IMHO into 2.4.0, but it will break custom CSS anyway
> right?
>

It might break some of the custom CSS.


> - I do not know how C++ changes would look like, if they are indeed minimal
>   I would consider them for 2.4 as well. I understand that it might break
>   custom CSS but at the moment we are producing trash by default.
>

I dug deeper into the problem. Actually, it will require some change in the
module format to specify that the label must be output outside the item in
InsetText. With the current code, here is the best I can get:



Label

desc



The change is that a Style should allow an HTMLInnerTag. A layout
configuration like this should suffice, otherwise:

Style Labeling
HTMLTag 

Re: Layout file format change proposal

[Thibaut Cuvelier]

On Thu, 28 Mar 2024 at 12:41, Lorenzo Bertini 
wrote:

> Il giorno gio 28 mar 2024 alle ore 11:40 José Matos
>  ha scritto:
> >
> > On Wed, 2024-03-27 at 11:02 -0400, Scott Kostyshak wrote:
> > > Cool idea, Lorenzo! There have been some discussions in the past on
> > > using standard formats, even for the .lyx file itself. I can see the
> > > advantages of that but I don't know what the cost of converting to
> > > them
> > > is.
> > >
> > > Scott
> >
> > Typical answer to this:
> > https://xkcd.com/927/
> >
> > :-)
> >
> > It makes sense for us to use a standard format.
> > Some of the questions then are:
> >  * which one is chosen (what is the most appropriate for our needs)?
> >  * what the are advantages and drawbacks from this change?
> >  * what is the transition plan?
> >  * what is the effort required for this transition?
> >
> > Best regards,
> > --
> > José Abílio
> > --
>
> Ah, a classic xkcd. For once, however, the talk is about "removing"
> one standard :)
>

Many standards aim at removing older standards :)!


> * Which one to choose?
> See research below.
>
> * The advantages and drawbacks
> As already mentioned, using a more common format means
>   - people generally more familiar with the format
>   - having more tools able to produce them, easing the efforts of
> publishers trying to provide layouts
>   - having parsers already available, for LyX and for people wanting
> to manipulate them externally
> The drawbacks that i can think of are
>   - migration always takes developer effort
>   - migration can take user effort too, to adapt to the new format
> (this can be greatly mitigated by which format is chosen)
>
> * The transition plan:
> The new format is introduced *alongside* the old format. The LyX
> version that brings the format will have all layouts converted, but
> will accept the old format too. This "transition period" can last
> indefinitely.
>

In a way, that's how LyX works right now: you can import a very old
document or layout, it should still work thanks to upgrade scripts. YAML,
TOML, or something else would just be a new version (which means you must
keep the version field: the format evolves a lot between versions). Here is
the script that does the conversion:
https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=lib/scripts/layout2layout.py;h=611639412a78e4235a55e41c890546f4e080c06f;hb=HEAD.



> * The efforts required for the transition
> We need to:
>   - write or choose a parser for the new format that maps a file to a
> LyX's params
>   - write a converter from the old format to the new one
>   - convert all the files to the new formats and test them
>
> Here is some info I dug up regarding configuration formats. For pros
> and cons I tried to limit them to one single aspect where they excel
> or fail
> - JSON:
>   . pros: most widely supported
>   . cons: not concise or readable, very distant from .layout
> - TOML:
>   . pros: very easy to read and write, even for humans
>   . cons: not widespread, distant from .layout
> - YAML:
>   . pros: very easy to read and write, very close to .layout
>   . cons: indentation is prone to syntax errors
> - XML:
>   . pros: the one and only, supports validation through schemas,
> widely supported
>   . cons: hard to read and write, very distant from .layout
>

All of these formats are rather well supported and far from shiny new
things (I think all of them have at least a decade of existence).

Regarding validation: XML Schema has many offsprings, such as JSON Schema (
https://json-schema.org/), with implementations that work on YAML and TOML (
https://json-schema-everywhere.github.io/toml). In any case, these schemas
are extremely lacking compared to 21st-century XML validation (RelaxNG with
Schematron).
We currently have no validation, but it would be great to have it as part
of the test suite.

How well do these formats work with (long) strings? What's great with the
current format is that you don't need to escape anything when LyX expects a
string. This aspect of the design removes a huge source of typos.


> I asked a chatbot to convert LyX's following layout extract into those
> formats:
>
> LYX'S LAYOUT
>
> InsetLayout Marginal
> LabelString   Margin
> LatexType command
> Font
>   SizeSmall
> EndFont
> LabelFont
>   Color   marginlabel
>   SizeSmall
> EndFont
> HTMLStyle
> div.marginal {
> border: 2px solid black;
> font-style: normal;
> }
> EndHTMLStyle
> End
>
> JSON:
>
> {
>   "InsetLayout": {
> "LabelString": "Margin",
> "LatexType": "command",
> "Font": {
>   "Size": "Small"
> },
> "LabelFont": {
>   "Color": "marginlabel",
>   "Size": "Small"
> },
> "HTMLStyle": {
>   "div.marginal": {
> "border": "2px solid black",
> "font-style": "normal"
>   }
> }
>   }
> }
>
> TOML:
>
> [InsetLayout]
>   LabelString = 

Re: DocBook tests failing AASTeX changes

[Thibaut Cuvelier]

On Fri, 8 Mar 2024 at 19:01, Scott Kostyshak  wrote:

> On Fri, Mar 08, 2024 at 06:58:35PM +0100, Thibaut Cuvelier wrote:
> > On Fri, 8 Mar 2024 at 18:39, Scott Kostyshak  wrote:
> >
> > > I get 2 out of 3 failing tests with the following:
> > >
> > > ctest -R "American_Astronomical_Society_.*docbook5"
> > >
> > > The failing tests:
> > >
> > > 3606 -
> > >
> export/examples/Articles/American_Astronomical_Society_%28AASTeX_v._6.3.1%29_docbook5
> > > (Failed)
> > > 6401 -
> > >
> export/templates/Articles/American_Astronomical_Society_%28AASTeX_v._6.3.1%29_docbook5
> > > (Failed)
> > >
> > > For example, I see in the log the following:
> > >
> > > -- Calling: /usr/bin/xmllint --loaddtd --noout
> > >
> "/home/scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_ykbINP/templates/Articles/American_Astronomical_Society_%28AASTeX_v._6.
> > > 3.1%29.xml"
> > > -- Errors from xmllint:
> > >
> templates/Articles/American_Astronomical_Society_%28AASTeX_v._6.3.1%29.xml:6:
> > > parser error : Specification mandates value for attribute Author
> > > 
> > >  ^
> > >
> templates/Articles/American_Astronomical_Society_%28AASTeX_v._6.3.1%29.xml:8:
> > > parser error : expected '>'
> > > 
> > > ^
> > >
> > >
> > It doesn't sound super hard to fix, I'll try to do it this week-end.
>
> Thanks!
> Scott
>

Your errors were quite strange, I couldn't reproduce them :/. (Is
reconfiguration required also to run the tests?)
I fixed a layout for AASTeX, though; the result is still far from perfect,
but it's a very good starting point for DocBook processing (i.e. the ePub
output will have problems). Like the previous version, the tests are
inverted (04beccca4c).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Fwd: DocBook test now failing on master

[Thibaut Cuvelier]

On Mon, 26 Feb 2024 at 16:00, Scott Kostyshak  wrote:

> On Mon, Feb 26, 2024 at 03:07:12PM +0100, Thibaut Cuvelier wrote:
> > On Mon, 26 Feb 2024 at 10:46,  wrote:
> >
> > > Thank you so much, Thibaut.
> > >
> > > Could you send the patch to lyx-devel, so Scott can test it? I am too
> > > unsure about all things docbook to judge.
> > >
> >
> > I tried sending it to the mailing list, but my emails from my @lyx.org
> > alias are still refused :/.
> >
> >
> > > I will submit the bookauthor change this evening when I am back at my
> > > home machine.
> > >
> >
> > I didn't really test bookauthor, not knowing exactly what you had in mind
> > (the code for authors is more complex that I thought).
> >
> > @Scott: I have just pushed a fix for the initial issue! I tested it on
> the
> > basic test case, it seems to work (as tested with my usual DocBook setup,
> > which is not identical to LyX tests, but hopefully close enough).
>
> Thanks for working on a fix. Did you run jing on it? I still get the
> following after pulling in your fix:
>
> -- Calling: /usr/bin/java -jar
> "/home/scott/lyxbuilds/master-master/repo/development/tools/jing.jar" "
> https://docbook.org/xml/5.2b09/rng/docbook.rng; "/home/
> scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_ZafZvY/export/docbook/basic.xml"
> -- _err = 1, jingout =
> /home/scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_ZafZvY/export/docbook/basic.xml:379:1:
> error: text not allowed   here; expected the element end-tag, element
> "abbrev", "abstract", "acronym", "address", "annotation", "artpagenums",
> "author", "authorgroup", "authorinitials",
> "bibliocoverage", "biblioid", "bibliomisc", "bibliomset", "bibliorelation",
> "biblioset", "bibliosource", "citebiblioid", "citerefentry",
> "citetitle", "collab", "confgroup", "contractnum", "contractsponsor",
> "copyright", "coref", "cover", "date", "edition", "editor", "emphasis",
> "extendedlink", "firstterm", "footnote", "footnoteref", "foreignphrase",
> "glossterm", "issuenum", "itermset", "keywordset", "legalnotice",
> "mediaobject", "org", "orgname",   "othercredit", "pagenums", "person",
> "personblurb", "personname", "phrase", "printhistory", "productname",
> "productnumber", "pubdate", "publisher",   "publishername",
> "quote", "releaseinfo", "revhistory", "revnumber", "seriesvolnums",
> "subjectset", "subscript", "subtitle", "superscript", "title",
>  "titleabbrev", "volumenum" or "wordasword" or an element from another
> namespace
>

I had trouble replicating this one locally, it should no longer appear as
of 2be72a15.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LYX 2.4 RC1 — Unable to export a Lyx archive (zip)

[Thibaut Cuvelier]

On Tue, 30 Jan 2024 at 19:27, Enrico Forestieri  wrote:

> On Sun, Jan 28, 2024 at 12:59:12AM +0100, Enrico Forestieri wrote:
> >
> >On Sat, Jan 27, 2024 at 10:09:05PM +, José Matos wrote:
> >>
> >>On Sat, 2024-01-27 at 20:49 +0100, didiergab...@free.fr wrote:
> >>>20:37:37.977: Exportation en cours...
> >>>20:37:37.993: (buffer-export lyxzip)
> >>>20:37:38.150: python -tt "C:/Users/Didier/AppData/Local/Programs/LyX
> >>>2.4/Resources/scripts/lyxpak.py" "K:/CPGE/PTSI/DS/DS-2023-
> >>>2024/DS3/"/"MWE-PDF preview.lyx"
> >>>20:37:38.375: Traceback (most recent call last):
> >>>20:37:38.376:   File "C:\Users\Didier\AppData\Local\Programs\LyX
> >>>2.4\Resources\scripts\lyxpak.py", line 396, in 
> >>>20:37:38.377: if not argv[0].startswith("-"):
> >>>20:37:38.378:^^^
> >>>20:37:38.378: TypeError: startswith first arg must be bytes or a
> >>>tuple of bytes, not str
> >>>support\Systemcall.cpp (306): Systemcall: 'python -tt
> >>>"C:/Users/Didier/AppData/Local/Programs/LyX
> >>>2.4/Resources/scripts/lyxpak.py" "K:/CPGE/PTSI/DS/DS-2023-
> >>>2024/DS3/"/"MWE-PDF preview.lyx"' finished with exit code 1
> >>>Error: Conversion du fichier impossible
> >>
> >>The problem here is that argv members are of type bytes instead of
> >>being str (string).
> >>
> >>This comes from the fact that the lyxpak.py script has special code to
> >>deal with Python 2 on Windows.
> >>
> >>@Enrico could it be that most of the specific windows code is not need
> >>any more with Python 3?
> >
> >I don't know (I don't use the native windows version). However,
> >skipping that code when using Python3 the script fails as follows:
> >
> >python -tt "C:/Program Files/LyX/Resources/scripts/lyxpak.py"
> "C:/work/"/"a.lyx"
> >Traceback (most recent call last):
> >  File "C:\Program Files\LyX\Resources\scripts\lyxpak.py", line 401, in
> 
> >main(sys.argv)
> >  File "C:\Program Files\LyX\Resources\scripts\lyxpak.py", line 302, in
> main
> >input = gzopen(lyxfile)
> >^^^
> >  File "C:\Program Files\LyX\Resources\scripts\lyxpak.py", line 77, in
> gzopen
> >input = open(file.decode('utf-8'), 'rb')
> > ^^^
> >AttributeError: 'str' object has no attribute 'decode'. Did you mean:
> 'encode'?
> >
> >
> >I don't think it was ever tested on Windows with Python3.
>
> For making it work with Python 3 on Windows I had to patch both our
> lyxpak.py script and getopt.py from Python.
>
> Attached you will find the patch to be applied to lyxpak.py, the patch I
> had to apply to getopt.py and the patched version (lyxwin_getopt.py)
> that should be distributed with LyX.
>
> In this way lyxpak.py works for me with both Python 2 and 3, in both
> Windows and Linux.
>
> Please test, especially on Windows.
>

It's going to be a bit hard to test the patch for getopt.py, as the default
LyX installer ships the Python libraries in a .zip file ("C:\Program
Files\LyX 2.4\Python\python311.zip") containing only .pyc files (like
getopt.pyc).

Nevertheless, copying your module lyxwin_getopt and patching lyxpak.py
solves the problem for me! (Windows 11 x64 23H2.)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Graphics Conversion

[Thibaut Cuvelier]

On Tue, 23 Jan 2024 at 18:35, Pavel Sanda  wrote:

> On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote:
> > pdftoppm -r 72 -png -singlefile $$i >  $$o
>
> This is new route in 2.4 which can be used to avoid IM problems in linux.
> We perhaps triggerred unnecessary problems on Windows.
> This could be sovled by making pdftoppm addition conditional on IM fail.
>
> And we should perhaps chech, whether accented characters are not problem
> on linux too...
>
> Could anyone on Windows post the output of Reconfigure command (you should
> be
> able to see that list in Messages pane)?
>

Here it is, copied from the Messages pane. It's really from Reconfigure, as
the first call to configure.py happens with the installer.
21:13:12.436: (dialog-show aboutlyx)
21:13:17.534: Running configure...
21:13:17.664: python -tt "C:/Program Files/LyX 2.4/Resources/configure.py" 
--binary-dir="C:/Program Files/LyX 2.4/bin/"
21:13:17.768: +Running LyX configure with Python 3.11.2
21:13:17.770: checking for DVI to DTL converter...
21:13:17.774: +checking for "dv2dt"...  yes
21:13:17.775: checking for DTL to DVI converter...
21:13:17.778: +checking for "dt2dv"...  yes
21:13:17.779: checking for a Latex2e program...
21:13:17.780: +checking for "latex"...  yes
21:13:17.781: checking for pLaTeX, the Japanese LaTeX...
21:13:17.781: +checking for "platex"...  yes
21:13:44.327: (guessed encoding #3: ASCII = utf8)checking for a java 
interpreter...
21:13:44.332: +checking for "java"...  yes
21:13:44.333: checking for a perl interpreter...
21:13:44.343: +checking for "perl"...  yes
21:13:44.345: checking for xsltproc...
21:13:44.354: +checking for "xsltproc"...  yes
21:13:45.988: checking for a Tgif viewer and editor...
21:13:46.003: +checking for "tgif"...  no
21:13:46.004: checking for a FIG viewer and editor...
21:13:46.018: +checking for "xfig"...  no
21:13:46.034: +checking for "jfig3-itext.jar"...  no
21:13:46.049: +checking for "jfig3.jar"...  no
21:13:46.051: checking for a Dia viewer and editor...
21:13:46.065: +checking for "dia"...  no
21:13:46.066: checking for an OpenDocument drawing viewer and editor...
21:13:46.080: +checking for "libreoffice"...  no
21:13:46.096: +checking for "lodraw"...  no
21:13:46.111: +checking for "ooffice"...  no
21:13:46.126: +checking for "oodraw"...  no
21:13:46.142: +checking for "soffice"...  no
21:13:46.144: checking for a Grace viewer and editor...
21:13:46.157: +checking for "xmgrace"...  no
21:13:46.159: checking for a FEN viewer and editor...
21:13:46.176: +checking for "xboard"...  no
21:13:46.178: checking for a SVG viewer and editor...
21:13:46.192: +checking for "inkscape.exe"...  yes
21:13:46.193: checking for a raster image viewer...
21:13:46.209: +checking for "xv"...  no
21:13:46.226: +checking for "gwenview"...  no
21:13:46.242: +checking for "kview"...  no
21:13:46.256: +checking for "eog"...  no
21:13:46.271: +checking for "xviewer"...  no
21:13:46.285: +checking for "ristretto"...  no
21:13:46.300: +checking for "gpicview"...  no
21:13:46.315: +checking for "lximage-qt"...  no
21:13:46.329: +checking for "xdg-open"...  no
21:13:46.344: +checking for "gimp-remote"...  no
21:13:46.359: +checking for "gimp"...  no
21:13:46.361: checking for a raster image editor...
21:13:46.374: +checking for "gimp-remote"...  no
21:13:46.388: +checking for "gimp"...  no
21:13:46.389: checking for a text editor...
21:13:46.404: +checking for "xemacs"...  no
21:13:46.418: +checking for "gvim"...  no
21:13:46.433: +checking for "kedit"...  no
21:13:46.448: +checking for "kwrite"...  no
21:13:46.463: +checking for "kate"...  no
21:13:46.476: +checking for "nedit"...  no
21:13:46.490: +checking for "gedit"...  no
21:13:46.504: +checking for "geany"...  no
21:13:46.519: +checking for "leafpad"...  no
21:13:46.532: +checking for "mousepad"...  no
21:13:46.552: +checking for "xed"...  no
21:13:46.556: +checking for "notepad"...  yes
21:13:46.571: +checking for "WinEdt"...  no
21:13:46.587: +checking for "WinShell"...  no
21:13:46.603: +checking for "PSPad"...  no
21:13:46.604: checking for a lilypond editor...
21:13:46.618: +checking for "frescobaldi"...  no
21:13:46.632: +checking for "xemacs"...  no
21:13:46.646: +checking for "gvim"...  no
21:13:46.659: +checking for "kedit"...  no
21:13:46.674: +checking for "kwrite"...  no
21:13:46.689: +checking for "kate"...  no
21:13:46.704: +checking for "nedit"...  no
21:13:46.721: +checking for "gedit"...  no
21:13:46.736: +checking for "geany"...  no
21:13:46.754: +checking for "leafpad"...  no
21:13:46.771: +checking for "mousepad"...  no
21:13:46.786: +checking for "xed"...  no
21:13:46.792: +checking for "notepad"...  yes
21:13:46.809: +checking for "WinEdt"...  no
21:13:46.824: +checking for "WinShell"...  no
21:13:46.838: +checking for "PSPad"...  no
21:13:46.839: checking for gnumeric spreadsheet software...
21:13:46.854: +checking for "gnumeric"...  no
21:13:46.856: checking for an HTML previewer...
21:13:46.869: +checking for 

Re: RC1: Unable to read files with accents in names on Windows

[Thibaut Cuvelier]

On Mon, 22 Jan 2024 at 23:53, Thibaut Cuvelier  wrote:

> On Mon, 22 Jan 2024 at 23:00, Richard Kimberly Heck 
> wrote:
>
>> On 1/22/24 16:53, didiergab...@free.fr wrote:
>>
>> I also realize that I can no longer load images whose names contain accents.
>> In any case, that’s what’s happening with the file I just sent you. If I 
>> rename the file:
>> SchemaCinematique.pdf to SchemaCinématique.pdf
>> then I can read “Error converting to a readable format.”
>>
>> That's a serious bug. Can anyone on Windows check this?
>>
> I can reproduce with PDF files whose names have accents, but not PNG (with
> the same file name apart from the extension). If I export the file to LyX
> 2.3 and load it with LyX 2.3.7, the PDF file doesn't have any issue (with
> MikTeX, up to date).
>
> I'm attaching the logs (View > Messages Pane, with all logs enabled) and
> the corresponding test files (LyX 2.3 and 2.4).
>

Another data point: in the temporary folder LyX uses for this document
(lyx_tmpdir.bsUGvNMjILjF), I have six files, all of them empty (size: zero
byte).

PS C:\Users\Thibaut\AppData\Local\Temp\lyx_tmpdir.bsUGvNMjILjF> ls -R


Directory: C:\Users\Thibaut\AppData\Local\Temp\lyx_tmpdir.bsUGvNMjILjF


Mode LastWriteTime Length Name
 - -- 
d- 22-Jan-24 23:47 lyx_tmpbuf0
-a 22-Jan-24 23:43 0 CacheItem.EtXrBH
-a 22-Jan-24 23:44 0 CacheItem.nbPvek
-a 22-Jan-24 23:42 0 CacheItem.OYeYzR
-a 22-Jan-24 23:42 0 gconvertAvdsxC.pdf
-a 22-Jan-24 23:43 0 gconvertFgslXV.pdf
-a 22-Jan-24 23:44 0 gconvertIdshbV.pdf


Directory:
C:\Users\Thibaut\AppData\Local\Temp\lyx_tmpdir.bsUGvNMjILjF\lyx_tmpbuf0


Mode LastWriteTime Length Name
 - -- 
-a 22-Jan-24 23:47 2598 test.23.lyx
-a 22-Jan-24 23:47 2938 test.lyx
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Fwd: New Defects reported by Coverity Scan for LyX

[Thibaut Cuvelier]

-- Forwarded message -
From: Thibaut Cuvelier 
Date: Thu, 26 Oct 2023, 03:35
Subject: Fwd: New Defects reported by Coverity Scan for LyX
To: LyX Developers 


Dear list,

I am attaching a patch that fixes two Coverity warnings. Could anyone
commit this to the Git repo (given I currently have no access to it)? As it
was generated with git format-patch, it should be easy to do while keeping
the commit message that explains the rationale behind the fix.

Thanks in advance!
Thibaut

-- Forwarded message -
From: 
Date: Thu, 19 Oct 2023 at 22:54
Subject: New Defects reported by Coverity Scan for LyX
To: 


Hi,

Please find the latest report on new defect(s) introduced to LyX found with
Coverity Scan.

2 new defect(s) introduced to LyX found with Coverity Scan.


New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)


** CID 403673:  Incorrect expression  (IDENTICAL_BRANCHES)
/home/lasgoutt/src/lyx/coverity/lyx/src/tex2lyx/text.cpp: 4351 in
lyx::parse_text(lyx::Parser &, std::basic_ostream>&, unsigned int, bool, lyx::Context &, const
std::__cxx11::basic_string,
std::allocator> &, const std::__cxx11::basic_string, std::allocator> &)()



*** CID 403673:  Incorrect expression  (IDENTICAL_BRANCHES)
/home/lasgoutt/src/lyx/coverity/lyx/src/tex2lyx/text.cpp: 4351 in
lyx::parse_text(lyx::Parser &, std::basic_ostream>&, unsigned int, bool, lyx::Context &, const
std::__cxx11::basic_string,
std::allocator> &, const std::__cxx11::basic_string, std::allocator> &)()
4345parse_text_snippet(p, os, FLAG_ITEM, outer,
context);
4346bool xcolorulem =
LaTeXPackages::isAvailable("ulem") &&
4347
LaTeXPackages::isAvailable("xcolor");
4348// No need to test for luatex, since luatex
comes in
4349// two flavours (dvi and pdf), like latex,
and those
4350// are detected by pdflatex.
>>> CID 403673:  Incorrect expression  (IDENTICAL_BRANCHES)
>>> The same code is executed regardless of whether "lyx::pdflatex ||
lyx::xetex" is true, because the 'then' and 'else' branches are identical.
Should one of the branches be modified, or the entire 'if' statement
replaced?
4351if (pdflatex || xetex) {
4352if (xcolorulem) {
4353
preamble.registerAutomaticallyLoadedPackage("ulem");
4354
preamble.registerAutomaticallyLoadedPackage("xcolor");
4355}
4356} else {

** CID 403672:  Error handling issues  (CHECKED_RETURN)
/home/lasgoutt/src/lyx/coverity/lyx/src/insets/InsetInfo.cpp: 1587 in
lyxxhtmlShortcutInfo(lyx::XMLStream &, const
lyx::InsetInfoParams &)()



*** CID 403672:  Error handling issues  (CHECKED_RETURN)
/home/lasgoutt/src/lyx/coverity/lyx/src/insets/InsetInfo.cpp: 1587 in
lyxxhtmlShortcutInfo(lyx::XMLStream &, const
lyx::InsetInfoParams &)()
1581string const lcode = params.lang->code();
1582docstring trans;
1583for (size_t i = 0; i < sequence.length(); ++i) {
1584char_type const c = sequence[i];
1585const auto keyMapping = keyToString.find(c);
1586if (keyMapping != keyToString.end()) {
>>> CID 403672:  Error handling issues  (CHECKED_RETURN)
>>> Calling "translateString" without checking return value (as is done
elsewhere 15 out of 18 times).
1587
translateString(from_ascii(keyMapping->second), trans, lcode);
1588xs << trans;
1589} else {
1590xs << c;
1591}
1592



To view the defects in Coverity Scan visit,
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yoTScfh6B8koVa-2BsXrqsH2r7zUmO9t1iEi-2FFYNyEDxxSQ-3D-3DsI5y_EaoV9iDrwluI0GGUrbM7yWAc9ILy2qIm0bzgdOF2o6OvKSta0m1PyhfKtFZpqs5rxkZ0WyT4tDIrKOVdRzCQUcgJBhEZL-2FoBWogZGuZsQC-2Bq0AbrFZDRbh6FzKvH7PuKIgIPnV5R1jUXR4Pa7I5qkEG-2FqT5uQIViXTNlHVpGxd3kG3fmlowNDXT2qSzXiuqPTFSxrInHD6j7Cz-2FWufFoDw-3D-3D

  To manage Coverity Scan email notifications for "dourou...@gmail.com",
click
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxxF-2FO44sWaogU6jGZMVL91U2CAiKpstwf-2F8GS1cLm5bQFa2vNdaMB9I0sFa-2FifkyGPDQ9lPJpxrLzv5JkQQq3cko-2Bs4SC3hxsw-2BPRRBy49SI-3D7CxO_EaoV9iDrwluI0GGUrbM7yWAc

Re: Big number of inverted docbook5 tests

[Thibaut Cuvelier]

On Thu, 12 Oct 2023, 11:11 Kornel Benko,  wrote:

>
> Master trunk as of today:
> I count 406 tests for docbook5. 149 of them are inverted.
> Thibaut, is there a reason for such a huge ratio?


There are two major reasons.
- Many tests are for Beamer: someone would need to write the layouts for
it, there is little from the other documents that can be used for Beamer.
- There are modules that are hard to support (they would need a lot of
custom code only for one module). Basically, that means that LaTeX and
DocBook are vastly different in terms of concepts and levels of abstraction.
I think I "documented" the inversion in the commit messages. Overall,
having all tests pass would require tens of hours of work, which I
preferred to invest in improving the quantity of the existing
implementation.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Added some options to configure.py allowing for faster partial-reconfigures.

[Thibaut Cuvelier]

On Wed, 11 Oct 2023 at 11:03, Pavel Sanda  wrote:

> On Tue, Oct 10, 2023 at 02:38:01PM +0200, Jürgen Spitzmüller wrote:
> >> 4) *lot* of latex packages
> > All we query is needed for something for sure.
>
> Let's stick with point 4.
>
> By *needed* you mean that we have e.g. some specific feature requiring it
> for
> proper typesetting (I agree with that) or that we actively use the
> information
> gathered by configure somewhere in UI (that's what I'm doubting, except of
> the
> insetinfo case)?
>

When you open a document that your LaTeX installation cannot compile, LyX
warns you (something like "this class is not available" or module).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] ctest: invert es/Intro_docbook5

[Thibaut Cuvelier]

On Sun, 8 Oct 2023 at 21:35, Thibaut Cuvelier  wrote:

> On Sun, 8 Oct 2023 at 17:05, Scott Kostyshak  wrote:
>
>> On Sun, Oct 08, 2023 at 02:48:45PM +0200, Thibaut Cuvelier wrote:
>> > Just a quick amendment to a previous patch (#1 in the series): there
>> was a
>> > quite big typo there... It should solve the largest issue with the newly
>> > failing test, but not all. I'm having a look at this test to improve the
>> > situation a bit more.
>> >
>> > Thibaut Cuvelier
>>
>> Sounds good. Riki OK to commit these to master?
>>
>
> I've taken some time to solve the issue with that test. I am adding one
> more patch to the list to solve it, plus another one to fix a crash I
> noticed while debugging this example.
>
> (FYI, the patch #4 in the sequence is a cleanup I made while having a look
> at https://www.lyx.org/trac/ticket/12891.)
>

I took the time to do the XHTML version too. It's almost the same code,
again without touching anything about LaTeX.


0003-DocBook-fix-closing-formatting-after-deleted-text.patch
Description: Binary data


0005-DocBook-in-InsetInfo-ensure-that-no-db-date-is-inser.patch
Description: Binary data


0007-XHTML-implement-InsetInfo.patch
Description: Binary data


0001-DocBook-add-support-for-InsetInfo.patch
Description: Binary data


0006-DocBook-fix-a-crash-in-docbookSimpleAllParagraphs.patch
Description: Binary data


0002-DocBook-fix-formatting-of-TODOs.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] ctest: invert es/Intro_docbook5

[Thibaut Cuvelier]

On Sun, 8 Oct 2023 at 17:05, Scott Kostyshak  wrote:

> On Sun, Oct 08, 2023 at 02:48:45PM +0200, Thibaut Cuvelier wrote:
> > Just a quick amendment to a previous patch (#1 in the series): there was
> a
> > quite big typo there... It should solve the largest issue with the newly
> > failing test, but not all. I'm having a look at this test to improve the
> > situation a bit more.
> >
> > Thibaut Cuvelier
>
> Sounds good. Riki OK to commit these to master?
>

I've taken some time to solve the issue with that test. I am adding one
more patch to the list to solve it, plus another one to fix a crash I
noticed while debugging this example.

(FYI, the patch #4 in the sequence is a cleanup I made while having a look
at https://www.lyx.org/trac/ticket/12891.)
From 8b5836d493afd689f327384c69f501b04f2c590d Mon Sep 17 00:00:00 2001
From: Thibaut Cuvelier 
Date: Sun, 8 Oct 2023 21:06:46 +0200
Subject: [PATCH 5/6] DocBook: in InsetInfo, ensure that no db:date is inserted
 within a db:date.

---
 autotests/export/docbook/insetinfo.lyx | 11 +++
 autotests/export/docbook/insetinfo.xml |  3 +++
 src/Paragraph.cpp  | 11 ++-
 src/insets/InsetInfo.cpp   | 27 ++
 4 files changed, 43 insertions(+), 9 deletions(-)

diff --git a/autotests/export/docbook/insetinfo.lyx b/autotests/export/docbook/insetinfo.lyx
index 1ae6c30760..a1b04a54f9 100644
--- a/autotests/export/docbook/insetinfo.lyx
+++ b/autotests/export/docbook/insetinfo.lyx
@@ -91,6 +91,17 @@ Test:
  InsetInfo
 \end_layout
 
+\begin_layout Date
+
+\lang japanese-cjk
+\begin_inset Info
+type  "moddate"
+arg   "long"
+\end_inset
+
+
+\end_layout
+
 \begin_layout Standard
 
 \lang spanish
diff --git a/autotests/export/docbook/insetinfo.xml b/autotests/export/docbook/insetinfo.xml
index 48ba1d802d..dd0dd6630c 100644
--- a/autotests/export/docbook/insetinfo.xml
+++ b/autotests/export/docbook/insetinfo.xml
@@ -2,6 +2,9 @@
 
 http://docbook.org/ns/docbook; xmlns:xlink="http://www.w3.org/1999/xlink; xmlns:m="http://www.w3.org/1998/Math/MathML; xmlns:xi="http://www.w3.org/2001/XInclude; version="5.2">
+
 Test: InsetInfo
+2023-10-08
+
 Véase la User's Guide o Additional Features para más detalles.
 
\ No newline at end of file
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 333aeb8862..5ac03fa474 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -3635,11 +3635,11 @@ std::tuple, vector> computeDocBookFontSwit
 
 std::tuple, std::vector, std::vector>
 Paragraph::simpleDocBookOnePar(Buffer const & buf,
-  OutputParams const & runparams,
-  Font const & outerfont,
-  pos_type initial,
-  bool is_last_par,
-  bool ignore_fonts) const
+   OutputParams const & runparams,
+   Font const & outerfont,
+   pos_type initial,
+   bool is_last_par,
+   bool ignore_fonts) const
 {
 	// Return values: segregation of the content of this paragraph.
 	std::vector prependedParagraphs; // Anything that must be output before the main tag of this paragraph.
@@ -3669,6 +3669,7 @@ std::tuple, std::vector, std::vector");
 		xs << qstring_to_ucs4(parseDate(buffer(), params_).toString(Qt::ISODate));
-		xml::closeTag(xs, "date", "inline");
+		if (!isWithinDate)
+			xml::closeTag(xs, "date", "inline");
 		break;
 	}
 
@@ -1752,9 +1763,17 @@ void InsetInfo::docbook(XMLStream & xs, OutputParams const & rp) const
 		}
 
 		// DocBook has no specific element for time, so use a date.
-		xml::openTag(xs, "date", "(role=\"" + role + "\"", "inline");
+		// See the discussion above (DATE_INFO, MODDATE_INFO, and FIXDATE_INFO) for a discussion about the choices that
+		// have been made.
+		const bool isWithinDate = buffer().getParFromID(rp.lastid).top().paragraph().layout().docbooktag() == "date";
+
+		if (!isWithinDate)
+			xml::openTag(xs, "date", "role=\"" + role + "\"", "inline");
+		else
+			xs << XMLStream::ESCAPE_NONE << from_ascii(std::string("");
 		xs << qstring_to_ucs4(parseTime(buffer(), params_).toString(Qt::ISODate));
-		xml::closeTag(xs, "date", "inline");
+		if (!isWithinDate)
+			xml::closeTag(xs, "date", "inline");
 		break;
 	}
 
-- 
2.41.0.windows.1

From e0815bfe4f51a573bfb2e90c0fbb70d68c497e32 Mon Sep 17 00:00:00 2001
From: Thibaut Cuvelier

Re: [LyX/master] ctest: invert es/Intro_docbook5

[Thibaut Cuvelier]

Just a quick amendment to a previous patch (#1 in the series): there was a
quite big typo there... It should solve the largest issue with the newly
failing test, but not all. I'm having a look at this test to improve the
situation a bit more.

Thibaut Cuvelier


On Sun, 8 Oct 2023 at 04:23, Scott Kostyshak  wrote:

> On Sun, Oct 08, 2023 at 01:55:23AM +0200, Thibaut Cuvelier wrote:
> > On Wed, 27 Sept 2023 at 19:46, Scott Kostyshak  wrote:
> >
> > > On Wed, Sep 27, 2023 at 06:24:31PM +0200, Scott Kostyshak wrote:
> > > > commit bf241165dd9b30b26e45b5fcbab0e2bd0d143b4c
> > > > Author: Scott Kostyshak 
> > > > Date:   Wed Sep 27 13:42:40 2023 -0400
> > > >
> > > > ctest: invert es/Intro_docbook5
> > > >
> > > > This fails after recent changes to the document.
> > > > ---
> > >
> > > Hi Thibaut,
> > >
> > > The es/Intro_docbook5 test is failing after changes to the document. I
> > > know some of these issues are very hard to add support for, so my plan
> > > is to just invert them when they happen and CC you so that you can
> > > decide whether it's worth spending time on or not.
> > >
> >
> > I'm attaching a patch that fixes the output from InsetInfo to match the
> > LaTeX output. This patch might be slightly controversial, since LyX 2.4
> is
> > nearing the release; I made sure to touch the DocBook parts of the code
> > only to lower the risk of breakage.
>
> > Also, I'm adding two much smaller patches: one that improves code
> > readability, one that fixes a bug about formatting and change tracking.
>
> Seems fine to me. Riki, is it OK with you if I commit Thibaut's patches to
> master?
>
> > I have manually checked that doc/es/Intro generates valid DocBook 5
> (i.e. I
> > believe the test could be uninverted). Let me know if you find more
> issues!
> >
> > Could someone please check this in the Git repository? Thanks!
>
> The following test now fails:
>
>
> export/examples/Language_Support/Mixing_Japanese_with_other_Languages_%28with_CJKutf8%29_docbook5
>
> Scott
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
>


0002-DocBook-fix-formatting-of-TODOs.patch
Description: Binary data


0001-DocBook-add-support-for-InsetInfo.patch
Description: Binary data


0003-DocBook-fix-closing-formatting-after-deleted-text.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] ctest: invert es/Intro_docbook5

[Thibaut Cuvelier]

On Wed, 27 Sept 2023 at 19:46, Scott Kostyshak  wrote:

> On Wed, Sep 27, 2023 at 06:24:31PM +0200, Scott Kostyshak wrote:
> > commit bf241165dd9b30b26e45b5fcbab0e2bd0d143b4c
> > Author: Scott Kostyshak 
> > Date:   Wed Sep 27 13:42:40 2023 -0400
> >
> > ctest: invert es/Intro_docbook5
> >
> > This fails after recent changes to the document.
> > ---
>
> Hi Thibaut,
>
> The es/Intro_docbook5 test is failing after changes to the document. I
> know some of these issues are very hard to add support for, so my plan
> is to just invert them when they happen and CC you so that you can
> decide whether it's worth spending time on or not.
>

I'm attaching a patch that fixes the output from InsetInfo to match the
LaTeX output. This patch might be slightly controversial, since LyX 2.4 is
nearing the release; I made sure to touch the DocBook parts of the code
only to lower the risk of breakage.

Also, I'm adding two much smaller patches: one that improves code
readability, one that fixes a bug about formatting and change tracking.

I have manually checked that doc/es/Intro generates valid DocBook 5 (i.e. I
believe the test could be uninverted). Let me know if you find more issues!

Could someone please check this in the Git repository? Thanks!
From 0cef99615a371fb5b794091553dd29ec91a2de6f Mon Sep 17 00:00:00 2001
From: Thibaut Cuvelier 
Date: Sun, 8 Oct 2023 01:20:14 +0200
Subject: [PATCH 1/3] DocBook: add support for InsetInfo.

A similar patch would be required for LyXHTML, but it will come later. The main impact is that some text isn't output in XHTML (like DocBook before this patch).

The code isn't as clean as it could be. I avoided touching anything not related to DocBook, as the release of 2.4 is nearing, while leaving comments for parts to improve for the next release cycle. Given that the code compiles, there are no risks for TeX or XHTML outputs; for DocBook, less content is skipped, which is a net improvement for users.
---
 autotests/export/docbook/insetinfo.lyx | 121 ++
 autotests/export/docbook/insetinfo.xml |   7 +
 src/insets/InsetInfo.cpp   | 545 +
 src/insets/InsetInfo.h |   2 +
 4 files changed, 675 insertions(+)
 create mode 100644 autotests/export/docbook/insetinfo.lyx
 create mode 100644 autotests/export/docbook/insetinfo.xml

diff --git a/autotests/export/docbook/insetinfo.lyx b/autotests/export/docbook/insetinfo.lyx
new file mode 100644
index 00..1ae6c30760
--- /dev/null
+++ b/autotests/export/docbook/insetinfo.lyx
@@ -0,0 +1,121 @@
+#LyX 2.4 created this file. For more info see https://www.lyx.org/
+\lyxformat 620
+\begin_document
+\begin_header
+\save_transient_properties true
+\origin unavailable
+\textclass article
+\use_default_options true
+\maintain_unincluded_children no
+\language american
+\language_package default
+\inputencoding utf8
+\fontencoding auto
+\font_roman "default" "default"
+\font_sans "default" "default"
+\font_typewriter "default" "default"
+\font_math "auto" "auto"
+\font_default_family default
+\use_non_tex_fonts false
+\font_sc false
+\font_roman_osf false
+\font_sans_osf false
+\font_typewriter_osf false
+\font_sf_scale 100 100
+\font_tt_scale 100 100
+\use_microtype false
+\use_dash_ligatures true
+\graphics default
+\default_output_format default
+\output_sync 0
+\bibtex_command default
+\index_command default
+\float_placement class
+\float_alignment class
+\paperfontsize default
+\use_hyperref false
+\papersize default
+\use_geometry false
+\use_package amsmath 1
+\use_package amssymb 1
+\use_package cancel 1
+\use_package esint 1
+\use_package mathdots 1
+\use_package mathtools 1
+\use_package mhchem 1
+\use_package stackrel 1
+\use_package stmaryrd 1
+\use_package undertilde 1
+\cite_engine basic
+\cite_engine_type default
+\use_bibtopic false
+\use_indices false
+\paperorientation portrait
+\suppress_date false
+\justification true
+\use_refstyle 1
+\use_formatted_ref 0
+\use_minted 0
+\use_lineno 0
+\index Index
+\shortcut idx
+\color #008000
+\end_index
+\secnumdepth 3
+\tocdepth 3
+\paragraph_separation indent
+\paragraph_indentation default
+\is_math_indent 0
+\math_numbering_side default
+\quotes_style english
+\dynamic_quotes 0
+\papercolumns 1
+\papersides 1
+\paperpagestyle default
+\tablestyle default
+\tracking_changes false
+\output_changes false
+\change_bars false
+\postpone_fragile_content true
+\html_math_output 0
+\html_css_as_file 0
+\html_be_strict false
+\docbook_table_output 0
+\docbook_mathml_prefix 1
+\end_header
+
+\begin_body
+
+\begin_layout Title
+Test:
+ InsetInfo
+\end_layout
+
+\begin_layout Standard
+
+\lang spanish
+Véase la 
+\emph on
+
+\begin_inset Info
+type  "l7n"
+arg   "User's Guide|U"
+\end_inset
+
+
+\emph default
+ o 
+\emph on
+
+\begin_inset Info
+type  "l7n"
+a

Re: ctest ca/Intro_docbook5 now failing

[Thibaut Cuvelier]

On Mon, 18 Sept 2023 at 02:43, Thibaut Cuvelier  wrote:

> On Thu, 14 Sept 2023 at 02:35, Scott Kostyshak  wrote:
>
>> On Wed, Sep 06, 2023 at 11:52:49PM -0400, Scott Kostyshak wrote:
>> > Recently (I think due to the ca/Intro changes) the following test
>> started to fail:
>> >
>> >   export/doc/ca/Intro_docbook5
>> >
>> >  Thibaut, can you take a look? I'm guessing the recent changes to that
>> file just triggered a known issue with DocBook export. Can you confirm so
>> that we can invert that test?
>> >
>>
>> I just inverted it for now (at eb920502). Take a look whenever you have
>> time.
>>
>
> I had a look at that failure. It's a specific feature of that document,
> with an emphasis ending at the end of a footnote (with no character
> afterwards). Is this expected that someone can enter that? I would naïvely
> think that LyX would remove that formatting (just like you cannot have two
> spaces or an empty paragraph). LyXHTML ends the emphasis at the end of the
> footnote, unlike DocBook.
>
> I have the idea for a fix; I'm waiting on your input on whether this is a
> DocBook bug or unexpected LyX behaviour.
>

I made up my mind and decided to replicate the same behaviour as LyXHTML
output: actually, there was some text, indicating a true bug in the
implementation. The attached patch fixes it locally, making it so that the
test can be uninverted. (As previously, I cannot push the commit onto the
Git repository.)


DocBook__fix_a_bug_when_having_a_space_with_font_at_the_end_of_a_paragraph_.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: ctest ca/Intro_docbook5 now failing

[Thibaut Cuvelier]

On Thu, 14 Sept 2023 at 02:35, Scott Kostyshak  wrote:

> On Wed, Sep 06, 2023 at 11:52:49PM -0400, Scott Kostyshak wrote:
> > Recently (I think due to the ca/Intro changes) the following test
> started to fail:
> >
> >   export/doc/ca/Intro_docbook5
> >
> >  Thibaut, can you take a look? I'm guessing the recent changes to that
> file just triggered a known issue with DocBook export. Can you confirm so
> that we can invert that test?
> >
>
> I just inverted it for now (at eb920502). Take a look whenever you have
> time.
>

I had a look at that failure. It's a specific feature of that document,
with an emphasis ending at the end of a footnote (with no character
afterwards). Is this expected that someone can enter that? I would naïvely
think that LyX would remove that formatting (just like you cannot have two
spaces or an empty paragraph). LyXHTML ends the emphasis at the end of the
footnote, unlike DocBook.

I have the idea for a fix; I'm waiting on your input on whether this is a
DocBook bug or unexpected LyX behaviour.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Bug report: SIGSEGV when copying cross-reference from "description" layout on LyX 2.4.0 beta 5

[Thibaut Cuvelier]

On Fri, 15 Sept 2023 at 11:36, Jürgen Spitzmüller  wrote:

> Am Freitag, dem 15.09.2023 um 10:45 +0200 schrieb Léo de Souza:
> > 1. Create new document: File > New
> > 2. Insert label: Insert > Label...
> > 3. On a new line, switch layout to "Labeling" or "Description"
> > 4. Insert cross-reference: Insert > Cross-Reference...
> > 5. Try copying this cross-reference
> >
> > Expected result (LyX 2.3.6): The cross-reference is copied to the
> > clipboard.
> >
> > Actual result (LyX 2.4.0 beta 5): LyX crashes with the message
> > "SIGSEGV signal caught!"
>
>
> Nullpointer issue due to local_font being non-defined in
> InsetRef::xhtml().
>
> The attached patch fixes this particular case, but there are many
> similar uses in insets's xhtml methods which would need to be audited.
>
> Thibaut, Riki?
>

Your patch looks fine to me.

It looks cumbersome, especially if we need to do that several times; maybe
we could have a method at the inset level, say getLocalFontOrDefault(const
OutputParams&), to return either OutputParams::local_font if it exists or
buffer().params() otherwise? It would make correct code (much) easier to
write.

(Wasn't this bug caught at some point by a static analyser? It seems to be
a too common error in C++ for it to slip through.)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [DocBook] Re: [LyX/master] Use master buffer setting when exporting

[Thibaut Cuvelier]

On Sat, 19 Aug 2023 at 01:28, Richard Kimberly Heck 
wrote:

> On 8/18/23 18:09, Richard Kimberly Heck wrote:
> > commit 784a7210baf6b0c610c04d507e08855bb233565e
> > Author: Richard Kimberly Heck 
> > Date:   Fri Aug 18 19:17:05 2023 -0400
> >
> >  Use master buffer setting when exporting
>
> Thibaut: This change may also be needed in the DocBook and XHTML export
> routines. Basically, we were querying the buffer itself for the setting
> of the use_refstyle flag rather than the master buffer. I ran into a
> case where this was a problem: One child document did not have that flag
> set, so it was issuing \prettyref rather than \fnref, e.g., which led to
> inconsistencies. I assume we do need this in the other output routines
> and can do that, but wanted to check with you first.
>

The patch looks fine to me, I don't think it should cause any issues.
However, I'm not sure that child documents are properly supported in
DocBook (if it is, it's not super-well tested).

> ---
> >   src/insets/InsetRef.cpp |8 
> >   1 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/insets/InsetRef.cpp b/src/insets/InsetRef.cpp
> > index 0938b47..277f8e5 100644
> > --- a/src/insets/InsetRef.cpp
> > +++ b/src/insets/InsetRef.cpp
> > @@ -260,12 +260,12 @@ void InsetRef::latex(otexstream & os, OutputParams
> const & rp) const
> >   {
> >   string const & cmd = getCmdName();
> >   docstring const & data = getEscapedLabel(rp);
> > - bool const hyper_on = buffer().params().pdfoptions().use_hyperref;
> > + bool const hyper_on =
> buffer().masterParams().pdfoptions().use_hyperref;
> >
> >   if (rp.inulemcmd > 0)
> >   os << "\\mbox{";
> >
> > - if (buffer().params().use_refstyle && cmd == "eqref") {
> > + if (buffer().masterParams().use_refstyle && cmd == "eqref") {
> >   // we advertise this as printing "(n)", so we'll do that,
> at least
> >   // for refstyle, since refstlye's own \eqref prints, by
> default,
> >   // "equation n". if one wants \eqref, one can get it by
> using a
> > @@ -281,7 +281,7 @@ void InsetRef::latex(otexstream & os, OutputParams
> const & rp) const
> >   docstring prefix;
> >   bool const use_caps = getParam("caps") == "true";
> >   bool const use_plural   = getParam("plural") == "true";
> > - bool const use_refstyle = buffer().params().use_refstyle;
> > + bool const use_refstyle =
> buffer().masterParams().use_refstyle;
> >   docstring const fcmd =
> >   getFormattedCmd(data, label, prefix, use_refstyle,
> use_caps);
> >   os << fcmd;
> > @@ -576,7 +576,7 @@ void InsetRef::validate(LaTeXFeatures & features)
> const
> >   docstring const data =
> getEscapedLabel(features.runparams());
> >   docstring label;
> >   docstring prefix;
> > - bool const use_refstyle = buffer().params().use_refstyle;
> > + bool const use_refstyle =
> buffer().masterParams().use_refstyle;
> >   bool const use_caps   = getParam("caps") == "true";
> >   docstring const fcmd =
> >   getFormattedCmd(data, label, prefix, use_refstyle,
> use_caps);
>
>
> --
> 
> Richard Kimberly (Riki) Heck
> Professor of Philosophy
> Brown University
>
> Pronouns: they/them/their
>
> Website: http://rkheck.frege.org/
> Blog:http://rikiheck.blogspot.com/
> Amazon:  http://amazon.com/author/richardgheckjr
> Google Scholar:  https://scholar.google.com/citations?user=QUKBG6EJ
> ORCID:   http://orcid.org/-0002-2961-2663
> Research Gate:   https://www.researchgate.net/profile/Richard_Heck
>
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Beta 3 On FTP Now

[Thibaut Cuvelier]

On Tue, 4 Jul 2023 at 00:02, Pavel Sanda  wrote:

> On Mon, Jul 03, 2023 at 10:53:52PM +0200, Pavel Sanda wrote:
> > please can you have a look on few 2.4 related bugs:
> > https://www.lyx.org/trac/ticket/12786
> > https://www.lyx.org/trac/ticket/12803
> > https://www.lyx.org/trac/ticket/10364
>
> And there was also bug report on users list:
> "in the last windows version there are no more icons for LyX documents."
>

That's not something I can reproduce (but it's far from a clean machine,
LyX-wise!). Maybe that user first installed LyX 2.4, then removed 2.3, with
file associations being removed at the same time as 2.3? That's a problem
I've had with other programs.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

[Thibaut Cuvelier]

On Sat, 22 Jul 2023 at 00:00, Jean-Marc Lasgouttes 
wrote:

> Le 18/07/2023 à 15:11, Jean-Marc Lasgouttes a écrit :
> > Hello,
> >
> > In the attached patch, I am able to support the mod/bmod/pmod/pod macros
> > by just defining them in lib/symbols with an argument.
> >
> > The result is a more pleasing editing process (IMO) and a simplification
> > of the documentation.
>
> It is in now.
>

Your change with arguments doesn't cause any real trouble for MathML
output, it works as expected. However, it highlighted a problem with
InsetMathClass:
it would output something like [mathbin [char + mathalpha]] instead of +,
due to the use of \mathbin when you define \bmod. I'm fixing that with the
attached patch.

Could you (or anyone else) please commit the attached patch? I currently
don't have access to the Git repo via SSH :/. Thanks!
From 4c868a476eca6cad8b7a9db29e560e27f4ceb579 Mon Sep 17 00:00:00 2001
From: Thibaut Cuvelier 
Date: Thu, 27 Jul 2023 02:43:56 +0200
Subject: [PATCH] MathML: implement InsetMathClass.

Before this patch, each character within InsetMathClass was output separately, without understanding their meaning, using the default text output (with [] around each character). This commit changes the behaviour to skip the InsetMathClass during the MathML output. This effectively renders the inset useless for MathML (instead of controlling spacing), as expected, because the MathML processor is supposed to handle the spacing itself.

Another implementation would have been to use the lspace and rspace attributes in MathML, but they require to give the exact spacing before and after the operator instead of relying on rules like TeX.

For instance, `$a\mathbin{+}b$` resulted in this MathML output before the patch:

```


 a
 [mathbin [char + mathalpha]]
 b


```

For comparison, this was the output with LyX 2.3.7

```
http://www.w3.org/1998/Math/MathML;>
 
  a
   [mathbin [char + mathalpha]]
   b
  
 
 ```

 After this patch, it looks like:

 ```
 
 
  
   a
   +
   b
  
 
 
 ```
---
 src/mathed/InsetMathClass.cpp | 11 +++
 src/mathed/InsetMathClass.h   |  2 ++
 src/mathed/MathClass.h|  2 +-
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/mathed/InsetMathClass.cpp b/src/mathed/InsetMathClass.cpp
index 0c22d478c7..2bfea82ce0 100644
--- a/src/mathed/InsetMathClass.cpp
+++ b/src/mathed/InsetMathClass.cpp
@@ -11,6 +11,7 @@
 #include 
 
 #include "InsetMathClass.h"
+#include "MathStream.h"
 
 #include "support/docstream.h"
 
@@ -56,6 +57,16 @@ void InsetMathClass::write(TeXMathStream & os) const
 }
 
 
+void InsetMathClass::mathmlize(MathMLStream & ms) const
+{
+	// Skip the \mathXXX macro, the MathML processor is supposed to handle
+	// spacing down the line.
+	for (size_t i = 0; i < nargs(); ++i) {
+		ms << cell(i);
+	}
+}
+
+
 docstring InsetMathClass::name() const
 {
 	return class_to_string(math_class_);
diff --git a/src/mathed/InsetMathClass.h b/src/mathed/InsetMathClass.h
index 89189f2b0d..f4308beb9b 100644
--- a/src/mathed/InsetMathClass.h
+++ b/src/mathed/InsetMathClass.h
@@ -43,6 +43,8 @@ public:
 	///
 	void write(TeXMathStream & os) const override;
 	///
+	void mathmlize(MathMLStream & ms) const override;
+	///
 	void infoize(odocstream & os) const override;
 	///
 	InsetCode lyxCode() const override { return MATH_CLASS_CODE; }
diff --git a/src/mathed/MathClass.h b/src/mathed/MathClass.h
index 169bfdb51a..af4f884cca 100644
--- a/src/mathed/MathClass.h
+++ b/src/mathed/MathClass.h
@@ -40,7 +40,7 @@ class MetricsBase;
  * + Vcent: a vbox to be centered, produced by \vcenter.
  *
  * Over, Under, Acc, Rad and Vcent are not considered in the enum
- * below. The relvant elements will be considered as Ord.
+ * below. The relevant elements will be considered as Ord.
  */
 enum MathClass {
 	MC_ORD,
-- 
2.41.0.windows.1

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

[Thibaut Cuvelier]

On Tue, 18 Jul 2023 at 16:55, Jean-Marc Lasgouttes 
wrote:

> Le 18/07/2023 à 16:47, Thibaut Cuvelier a écrit :
> > On Tue, 18 Jul 2023 at 16:04, Jean-Marc Lasgouttes  > <mailto:lasgout...@lyx.org>> wrote:
> >
> >     Le 18/07/2023 à 15:54, Thibaut Cuvelier a écrit :
> >  > Also, we already have macros with parameters:
> >  > https://github.com/cburschka/lyx/blob/master/lib/symbols#L1223
> > <https://github.com/cburschka/lyx/blob/master/lib/symbols#L1223>
> >  > <https://github.com/cburschka/lyx/blob/master/lib/symbols#L1223
> > <https://github.com/cburschka/lyx/blob/master/lib/symbols#L1223>>
> >
> > Indeed. I'm the one who pushed that, but it did not impress me at the
> > time ;) And my question stands somehow, since I did not ask at the
> time.
> >
> > I'll push that then. I like the idea of using code as close as
> possible
> > to the LaTeX we want to emulate.
> >
> >
> > Could you please just add a TODO near the DocBook/XHTML code, so that I
> > can think about implementing the parameter mechanism at some point?
>
>
> You mean in lib/symbols? Or in some real code?
>

Any of them would be fine :)!
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

[Thibaut Cuvelier]

On Tue, 18 Jul 2023 at 16:04, Jean-Marc Lasgouttes 
wrote:

> Le 18/07/2023 à 15:54, Thibaut Cuvelier a écrit :
> > Also, we already have macros with parameters:
> > https://github.com/cburschka/lyx/blob/master/lib/symbols#L1223
> > <https://github.com/cburschka/lyx/blob/master/lib/symbols#L1223>
>
> Indeed. I'm the one who pushed that, but it did not impress me at the
> time ;) And my question stands somehow, since I did not ask at the time.
>
> I'll push that then. I like the idea of using code as close as possible
> to the LaTeX we want to emulate.
>

Could you please just add a TODO near the DocBook/XHTML code, so that I can
think about implementing the parameter mechanism at some point?
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

[Thibaut Cuvelier]

On Tue, 18 Jul 2023 at 15:45, Jean-Marc Lasgouttes 
wrote:

> Le 18/07/2023 à 15:36, Thibaut Cuvelier a écrit :
> > For the symbols in your patch, yes, export is currently broken, but it's
> > fixable.
> > I think it would still be fixable in the future with macros, as I did in
> > https://github.com/cburschka/lyx/blob/master/lib/symbols#L1128
> > <https://github.com/cburschka/lyx/blob/master/lib/symbols#L1128>.
>
> Yes, but macros with parameters?
>

I did not notice that in your patch (I'm avoiding low-level LaTeX, I find
it scary...). It's not currently supported, but we can implement a
mechanism like this. #1 and others are not used a lot (and we can implement
escaping).

Also, we already have macros with parameters:
https://github.com/cburschka/lyx/blob/master/lib/symbols#L1223
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Is there a reason for not using macros with arguments in lib/symbols?

[Thibaut Cuvelier]

On Tue, 18 Jul 2023 at 15:11, Jean-Marc Lasgouttes 
wrote:

> Hello,
>
> In the attached patch, I am able to support the mod/bmod/pmod/pod macros
> by just defining them in lib/symbols with an argument.
>
> The result is a more pleasing editing process (IMO) and a simplification
> of the documentation.
>
> Since this use of \def is not documented, I have to ask: is there a
> reason for not doing it?
>
> One downside may be that exporting to html/docbook does not really work,
> but it has always been the case, AFAIK.
>

For the symbols in your patch, yes, export is currently broken, but it's
fixable.
I think it would still be fixable in the future with macros, as I did in
https://github.com/cburschka/lyx/blob/master/lib/symbols#L1128.

My question is: should I create a full-fledged math inset instead? It is
> doable too, nd at least I'd get the spacing right depending on the
> context (script...).
>
> JMarc--
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows Dark Mode and "fusion" style

[Thibaut Cuvelier]

On Fri, 7 Jul 2023 at 10:13, Yu Jin  wrote:

> Am Fr., 7. Juli 2023 um 04:37 Uhr schrieb Thibaut Cuvelier:
>
>> I'm having an issue with your patch: QStyle::name has only been added in
>> Qt 6.1 (https://doc.qt.io/qt-6/qstyle.html#name). I believe
>> QObject::objectName should do the trick too.
>>
>> As I understand your problem, in LyX.cpp, LyX::exec first creates a
>> GuiApplication (line 358) before initialising LyX (line 366). If I do the
>> initialisation in GuiApplication::exec instead, I don't get any crash;
>> actually, your patch works :)!
>> I have added a similar line in PrefInput::applyRC so that the style
>> change applies immediately when clicking Apply in the Preferences window.
>>
>
> I think it is actually better to do that in PrefUserInterface::applyRC for
> affiliation.
>

To be honest, I took a place that might match and where the code worked. I
tried to understand the differences between these functions, but I couldn't
get it. A bit of documentation would have helped


> I'm attaching the corresponding patch.
>>
>
> I didn't understand this part:
> @@ -718,13 +718,13 @@ GuiView::GuiView(int id)
>   connect(zoom_value_, SIGNAL(pressed()), this,
> SLOT(showZoomContextMenu()));
>   // zoom_value_->setPalette(palette);
>   zoom_value_->setForegroundRole(statusBar()->foregroundRole());
>   zoom_value_->setFixedHeight(fm.height());
>  #if (QT_VERSION >= QT_VERSION_CHECK(5, 11, 0))
> - zoom_value_->setMinimumWidth(fm.horizontalAdvance("444\%"));
> + zoom_value_->setMinimumWidth(fm.horizontalAdvance("444%"));
>  #else
> - zoom_value_->setMinimumWidth(fm.width("444\%"));
> + zoom_value_->setMinimumWidth(fm.width("444%"));
>  #endif
>   zoom_value_->setAlignment(Qt::AlignCenter);
>   zoom_value_->setText(toqstr(bformat(_("[[ZOOM]]%1$d%"), zoom)));
>   statusBar()->addPermanentWidget(zoom_value_);
>   zoom_value_->setEnabled(currentBufferView());
>

It's just fixing a few compiler warnings, it doesn't have to be in the same
patch.


> Side question: why is createApplication declared in Application.h but
>> defined in GuiApplication.cpp?
>>
>>
>> On Fri, 7 Jul 2023 at 02:23, Thibaut Cuvelier wrote:
>>
>>> Can't you use setStyle later on, once LyXRC is read?
>>>
>>
> You could, like in your patch, but this creates another problem (see below)
>
>
>> I suspect it should be enough to apply the style to the whole
>>> application, based on the source code (
>>> https://github.com/qt/qtbase/blob/dev/src/widgets/kernel/qapplication.cpp#L971),
>>> as I understand that GuiApplication is the root widget for the whole LyX.
>>>
>>> Also, I believe that LyXRC shouldn't take precedence over CLI arguments
>>> (-style windows, for instance); does Qt implement this itself or do we have
>>> to check in QCoreApplication::arguments if a style is given?
>>>
>>
> I believe the way would be to set the style *before* the QApplication is
> created, then if any style is given in CLI arguments, QApplication uses
> that over the one previously set.
>
> I don't know, to me it seems we *need* to know style setting from lyxrc
> before we create the gui app
> frontend::GuiApplication * guiApp = new frontend::GuiApplication(argc,
> argv);
> which is not given.
> otherwise we would need to check cli arguments manually for "-style" and I
> don't want to do that, if Qt decides to change those in the future we would
> have to put more work into it.
> What can be done is calling readRcFile("preferences", true) before
> CreateApplication, like I have done here in the attached patch, but I don't
> know if that is ok or not, it seems to work, but I can't assess it 100%,
> any ideas/objections?
>

Qt hasn't changed its -style parameter at least since Qt 4 (2005), that's
quite stable (there is also an environment variable, QT_STYLE_OVERRIDE). I
couldn't find any way to tell if the style was set from the command line or
not (or to get the default style for the current platform), so we would
always need to check manually whether there has been some CLI-set style,
whatever path we end up taking. (There is some precedent with locale
handling, where Qt is trying hard to impose its locale, it seems.)
(More details: the -style parameter is dealt with in
QGuiApplicationPrivate, not accessible from LyX and not available anywhere
in the API, as far as I can tell.)

As Qt can dynamically change the style at runtime, why would you need to
know it when instantiating GuiApplication? Anyway, in my patch, the style
is set before calling QApplication::exec, before any user interaction can
take place

Re: Windows Dark Mode and "fusion" style

[Thibaut Cuvelier]

I'm having an issue with your patch: QStyle::name has only been added in Qt
6.1 (https://doc.qt.io/qt-6/qstyle.html#name). I believe
QObject::objectName should do the trick too.

As I understand your problem, in LyX.cpp, LyX::exec first creates a
GuiApplication (line 358) before initialising LyX (line 366). If I do the
initialisation in GuiApplication::exec instead, I don't get any crash;
actually, your patch works :)!
I have added a similar line in PrefInput::applyRC so that the style change
applies immediately when clicking Apply in the Preferences window.
I'm attaching the corresponding patch.

Side question: why is createApplication declared in Application.h but
defined in GuiApplication.cpp?

Thibaut Cuvelier


On Fri, 7 Jul 2023 at 02:23, Thibaut Cuvelier  wrote:

> On Thu, 6 Jul 2023 at 10:34, Yu Jin  wrote:
>
>> Am Do., 6. Juli 2023 um 03:47 Uhr schrieb Thibaut Cuvelier:
>>
>>> On Wed, 5 Jul 2023 at 22:02, Enrico Forestieri wrote:
>>>
>>>> On Wed, Jul 05, 2023 at 08:42:21PM +0200, Pavel Sanda wrote:
>>>> >
>>>> >I think your patch should go for windows port only as it would
>>>> probably
>>>> >interfere with ppl choosing windows style under linux (yes, apparently
>>>> >there are users choosing this as I read users list).
>>>>
>>>> I don't think this is a good idea because LyX would look different from
>>>> any other application.
>>>>
>>>
>>> +1, the Fusion style isn't native at all (the colours are completely
>>> off, for instance). Maybe some users will like it, though (like the author
>>> of https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5).
>>>
>>> However, it seems that the classic Windows theme has a dark mode
>>> starting with Qt 6.5 (out since April):
>>> https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5. The Windows
>>> style, both in Qt 5 and Qt 6, is horrible, though... Here is what it looks
>>> like (2.4 beta 3 with Qt 6.5.1 as built by Eugene; run with:
>>> .\LyX.exe -platform windows:darkmode=2 -style windows
>>> ):
>>>
>>> What's strange is that the situation isn't much better for Qt Quick,
>>> with no native Windows dark theme. There are other open-source projects
>>> that provide a good Windows theme that also works in dark, such as
>>> https://github.com/witalihirsch/QTWin11 for Python only or
>>> https://github.com/marunemitsu/QTFluent (very modern style, unlike the
>>> default Vista one). I have seen good results with
>>> https://github.com/ColinDuquesnoy/QDarkStyleSheet (but not with its
>>> light theme!), which is more or less maintained and should work with Qt 6
>>> (not PyQt 6 out of the box, though). Wireshark went that route, but the
>>> code didn't get merged (
>>> https://gitlab.com/wireshark/wireshark/-/merge_requests/6382).
>>>
>>> Overall, it seems that Qt's dark theme for Windows is inexistent; their
>>> preferred solution is to avoid implementing a proper theme, so that people
>>> have to rely on unmaintained projects or use their own solution. They rely
>>> consider it done (
>>> https://bugreports.qt.io/browse/QTBUG-72028#comment-712180)!
>>>
>>> How complex would it be to have a new LyX setting to choose the Qt
>>> theme? I believe it should not be too hard, as you can change the style on
>>> QApplication. Or is there something I'm missing?
>>>
>>
>> I tried my luck here (patch attached) but it is not working though. While
>> I think I got the UI and LyXRC right, the problem is that at the time of
>> creation of QApplication the LyXRC is initialized but not read, so the
>> saved style preference is not available.
>>
>> This stacktrace is from application creation:
>>   LyX.exe!lyx::createApplication(int & argc, char * * argv) Zeile 224 C++
>>   LyX.exe!lyx::LyX::exec(int & argc, char * * argv) Zeile 358 C++
>>   LyX.exe!main(int argc, char * * argv) Zeile 55 C++
>>
>> This one from LyXRC reading:
>>   LyX.exe!lyx::LyXRC::read(lyx::Lexer & lexrc, bool check_format) Zeile
>> 608 C++
>>   LyX.exe!lyx::LyXRC::read(const lyx::support::FileName & filename, bool
>> check_format) Zeile 242 C++
>>   LyX.exe!lyx::LyX::readRcFile(const std::string & name, bool
>> check_format) Zeile 1148 C++
>>   LyX.exe!lyx::LyX::init() Zeile 998 C++
>>   LyX.exe!lyx::LyX::init(int & argc, char * * argv) Zeile 483 C++
>>   LyX.exe!lyx::LyX::exec(int & argc, char * * argv) Zeile 366 C++
>>   LyX.exe!main(int argc, char * * argv) 

Re: Windows Dark Mode and "fusion" style

[Thibaut Cuvelier]

On Thu, 6 Jul 2023 at 10:34, Yu Jin  wrote:

> Am Do., 6. Juli 2023 um 03:47 Uhr schrieb Thibaut Cuvelier:
>
>> On Wed, 5 Jul 2023 at 22:02, Enrico Forestieri wrote:
>>
>>> On Wed, Jul 05, 2023 at 08:42:21PM +0200, Pavel Sanda wrote:
>>> >
>>> >I think your patch should go for windows port only as it would probably
>>> >interfere with ppl choosing windows style under linux (yes, apparently
>>> >there are users choosing this as I read users list).
>>>
>>> I don't think this is a good idea because LyX would look different from
>>> any other application.
>>>
>>
>> +1, the Fusion style isn't native at all (the colours are completely off,
>> for instance). Maybe some users will like it, though (like the author of
>> https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5).
>>
>> However, it seems that the classic Windows theme has a dark mode starting
>> with Qt 6.5 (out since April):
>> https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5. The Windows
>> style, both in Qt 5 and Qt 6, is horrible, though... Here is what it looks
>> like (2.4 beta 3 with Qt 6.5.1 as built by Eugene; run with:
>> .\LyX.exe -platform windows:darkmode=2 -style windows
>> ):
>>
>> What's strange is that the situation isn't much better for Qt Quick, with
>> no native Windows dark theme. There are other open-source projects that
>> provide a good Windows theme that also works in dark, such as
>> https://github.com/witalihirsch/QTWin11 for Python only or
>> https://github.com/marunemitsu/QTFluent (very modern style, unlike the
>> default Vista one). I have seen good results with
>> https://github.com/ColinDuquesnoy/QDarkStyleSheet (but not with its
>> light theme!), which is more or less maintained and should work with Qt 6
>> (not PyQt 6 out of the box, though). Wireshark went that route, but the
>> code didn't get merged (
>> https://gitlab.com/wireshark/wireshark/-/merge_requests/6382).
>>
>> Overall, it seems that Qt's dark theme for Windows is inexistent; their
>> preferred solution is to avoid implementing a proper theme, so that people
>> have to rely on unmaintained projects or use their own solution. They rely
>> consider it done (
>> https://bugreports.qt.io/browse/QTBUG-72028#comment-712180)!
>>
>> How complex would it be to have a new LyX setting to choose the Qt theme?
>> I believe it should not be too hard, as you can change the style on
>> QApplication. Or is there something I'm missing?
>>
>
> I tried my luck here (patch attached) but it is not working though. While
> I think I got the UI and LyXRC right, the problem is that at the time of
> creation of QApplication the LyXRC is initialized but not read, so the
> saved style preference is not available.
>
> This stacktrace is from application creation:
>   LyX.exe!lyx::createApplication(int & argc, char * * argv) Zeile 224 C++
>   LyX.exe!lyx::LyX::exec(int & argc, char * * argv) Zeile 358 C++
>   LyX.exe!main(int argc, char * * argv) Zeile 55 C++
>
> This one from LyXRC reading:
>   LyX.exe!lyx::LyXRC::read(lyx::Lexer & lexrc, bool check_format) Zeile
> 608 C++
>   LyX.exe!lyx::LyXRC::read(const lyx::support::FileName & filename, bool
> check_format) Zeile 242 C++
>   LyX.exe!lyx::LyX::readRcFile(const std::string & name, bool
> check_format) Zeile 1148 C++
>   LyX.exe!lyx::LyX::init() Zeile 998 C++
>   LyX.exe!lyx::LyX::init(int & argc, char * * argv) Zeile 483 C++
>   LyX.exe!lyx::LyX::exec(int & argc, char * * argv) Zeile 366 C++
>   LyX.exe!main(int argc, char * * argv) Zeile 55 C++
>
> second function from bottom: line 358 vs 366.
>
> Any ideas what I could do here?
>

Can't you use setStyle later on, once LyXRC is read? I suspect it should be
enough to apply the style to the whole application, based on the source
code (
https://github.com/qt/qtbase/blob/dev/src/widgets/kernel/qapplication.cpp#L971),
as I understand that GuiApplication is the root widget for the whole LyX.

Also, I believe that LyXRC shouldn't take precedence over CLI arguments
(-style windows, for instance); does Qt implement this itself or do we have
to check in QCoreApplication::arguments if a style is given?
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Include Python3 in the Windows installer

[Thibaut Cuvelier]

On Sun, 12 Mar 2023 at 03:25, Richard Kimberly Heck 
wrote:

> On 3/11/23 20:18, Thibaut Cuvelier wrote:
>
> On Sun, 12 Mar 2023 at 01:44, Richard Kimberly Heck 
> wrote:
>
>> On 3/11/23 03:22, Yu Jin wrote:
>>
> So what would you say? Is pywin32 needed or do I skip it?
>>
>> Did you see my message about what this is supposed to do? Suppress
>> certain windows (terminals, I guess) from appearing when we're doing
>> certain things? If so, perhaps it would be worth seeing just how annoying
>> those windows are. If the answer is "not very", then maybe it isn't worth
>> the trouble.
>>
> For a typical Windows user, as I could see, having such windows appearing
> is associated with viruses. I'm not too fond of adding a message to the
> user saying that such windows are normal, they'd tend to think that LyX is
> poorly coded.
>
> Are you able to test with and without the PyWin packages?
>
I could with a recent installer for 2.4 (these modules don't appear in the
2.3 package); I think I could just delete a bunch of files. Eugene, could
you provide me with that? Otherwise, I'll test with my local build (hoping
that my results are reproducible with the installer).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Include Python3 in the Windows installer

[Thibaut Cuvelier]

On Sun, 12 Mar 2023 at 01:44, Richard Kimberly Heck 
wrote:

> On 3/11/23 03:22, Yu Jin wrote:
>
> 2. The python package gets significantly larger (50MB vs 18MB unzipped)
> and also the LyX installer itself when finished (65MB vs. 55MB).
>
> Not a big deal either.
>
LyX will still be far from Electron apps, that shouldn't be too much of a
problem, except for people not having an excellent Internet connection.

LyX would still just be 65 MB to download, while the smallest MikTeX
download is 130 MB for Windows (https://miktex.org/download#win). I don't
know how large TeX Live is: the installer is 25 MB to download, just as
much as a TinyTeX (https://github.com/rstudio/tinytex-releases), while a
standard TeX Live installation is 1.2 GB. LyX would be much smaller than
that.

The install size isn't as important, nowadays.

> So what would you say? Is pywin32 needed or do I skip it?
>
> Did you see my message about what this is supposed to do? Suppress certain
> windows (terminals, I guess) from appearing when we're doing certain
> things? If so, perhaps it would be worth seeing just how annoying those
> windows are. If the answer is "not very", then maybe it isn't worth the
> trouble.
>
For a typical Windows user, as I could see, having such windows appearing
is associated with viruses. I'm not too fond of adding a message to the
user saying that such windows are normal, they'd tend to think that LyX is
poorly coded.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Using lyxhtml_validity.py

[Thibaut Cuvelier]

On Fri, 13 Jan 2023 at 17:29, Scott Kostyshak  wrote:

> On Wed, Jan 11, 2023 at 06:55:11AM +0100, Kornel Benko wrote:
> > Am Wed, 11 Jan 2023 01:12:40 +0100
> > schrieb Thibaut Cuvelier :
> >
> > > > Still
> > > > Error: Bad value "content-type" for attribute "http-equiv"
> on element "meta".
> > > >
> > > > Should we ignore this error?
> > > >
> > > I don't think we should ignore it. It really seems to be
> platform-dependent (either due
> > > to LyX or the HTML validator). I really can't reproduce locally, even
> when running the
> > > test through CTest (log attached for Intro.lyx). However, when
> uploading my file to
> > > https://validator.nu/#file, I get the error message.
> >
> > I suppose the call to validate is still commented out in your
> export.cmake?
> > I have now enabled the call at 88087a3c, now that the test passes here
> too. Thanks for
> > your work.
>
> Thanks to both of you on making progress on these tests. Still a lot of
> tests fail for me. Is it OK to comment out the check_xhtml_validate()
> line until the tests are passing for all of us? Otherwise it's hard for
> me to figure out which failures are due to regressions.
>

It's totally OK: I won't have time to work on all these issues in time for
LyX 2.4. Some of them are rather deep (like  being generated at the
wrong place).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Embedded Objects xhtml tests failing due to xmllint

[Thibaut Cuvelier]

On Wed, 11 Jan 2023 at 00:15, Thibaut Cuvelier  wrote:

> On Tue, 10 Jan 2023 at 04:11, Scott Kostyshak  wrote:
>
>> I'll paste the errors at the bottom of this message. Thibaut, is this
>> related to recent work?
>>
>
> It's highly likely, I'm having a look!
>

That problem should be fixed at
fb70f89983
.

However, multicolumn still has deficiencies between LaTeX and XHTML. Within
the same document, the table 2.30 ("Several table cell alignments.",
tab:Several-table-cell), here is the XHTML output for the header:


units

relations

24bottles



The interesting part is the missing colspan for the last column (
magicparlabel-7034). It looks like isMultiCol does very few checks compared
to the LaTeX code to decide when to output \multicol. For LaTeX, here is
the code to decide whether a cell spans several columns:

ismulticol = (isMultiColumn(cell)
 || (c == 0 && colleft != leftLine(cell))
 || ((colright || nextcolleft) && !rightLine(cell) && !nextcellleft)
 || (!colright && !nextcolleft && (rightLine(cell) || nextcellleft))
 || (coldouble != celldouble))
&& !decimal;

// we center in multicol when no decimal point
if (decimal) {
   docstring const align_d = column_info[c].decimal_point;
   DocIterator const dit = separatorPos(cellInset(cell), align_d);
   bool const nosep = !dit;
   ismulticol |= nosep;
   celldouble &= nosep;
}


The XHTML only does isMultiColumn(cell). However, I don't understand this
code. Some parts are due to support for bidirectional text, but that's it.
Shouldn't Tabular::isMultiColumn be updated to do more work, just like
Tabular::TeXCellPreamble?

(Also, the generation of paragraph IDs is broken, as several rows have the
same ID for the same column. That seems to be due to different paragraphs
having the same internal ID, Paragraph::Private::id_. This problem is more
general that just XHTML, though.)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Embedded Objects xhtml tests failing due to xmllint

[Thibaut Cuvelier]

On Tue, 10 Jan 2023 at 04:11, Scott Kostyshak  wrote:

> I'll paste the errors at the bottom of this message. Thibaut, is this
> related to recent work?
>

It's highly likely, I'm having a look!
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Using lyxhtml_validity.py

[Thibaut Cuvelier]

On Sun, 8 Jan 2023 at 17:11, Kornel Benko  wrote:

> Am Sun, 8 Jan 2023 10:57:40 -0500
> schrieb Scott Kostyshak :
>
> > > Same here. To disable the validity-check simply comment the line
> > > development/autotests/export.cmake:335
> > > --> #check_xhtml_validate(${result_file_name})
> >
> > Would it be reasonable to commit everything, but keep the validity-check
> > commented out? That way it would at least be a bit easier for Thibaut to
> > just uncomment the extra check when they want to run it?
> >
> > I still prefer for it to be commented out by default, until the tests
> > pass for us.
> >
> > Scott
>
> Yes, that was also one reason to refactor export.cmake.
>
> I will commit.
>

Sorry for the series of emails, I didn't see the latest developments when I
started replying...

Regarding simplehtml_validity.py, I think you went a bit fast when
simplifying my code, with many parts now useless. I suggest the attached
patch.

I'm currently running the new test suite (with the check_xhtml_validate(${
result_file_name}) line uncommented).


0001-Simplify-simplehtml_validity.py.patch
Description: Binary data


0002-Export-tests-use-a-better-function-name.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Using lyxhtml_validity.py

[Thibaut Cuvelier]

On Sun, 8 Jan 2023 at 16:32, Scott Kostyshak  wrote:

> On Sun, Jan 08, 2023 at 04:22:09PM +0100, Kornel Benko wrote:
> > Am Sun, 8 Jan 2023 10:11:37 -0500
> > schrieb Scott Kostyshak :
> >
> > > On Sun, Jan 08, 2023 at 03:50:07PM +0100, Kornel Benko wrote:
> > > > Am Sun, 8 Jan 2023 09:37:03 -0500
> > > > schrieb Scott Kostyshak :
> > > >
> > > > > On Sun, Jan 08, 2023 at 09:30:43AM +0100, Kornel Benko wrote:
> > > > > > Am Sun, 8 Jan 2023 00:59:34 +0100
> > > > > > schrieb Thibaut Cuvelier :
> > > > > >
> > > > > > > On Sat, 7 Jan 2023 at 17:10, Kornel Benko 
> wrote:
> > > > > > >
> > > > > > > > Am Sat, 7 Jan 2023 16:26:03 +0100
> > > > > > > > schrieb Thibaut Cuvelier :
> > > > > > > >
> > > > > > > > > > After your recent changes, the number of errors
> decreased :)
> > > > > > > > > >
> > > > > > > > > > I got now (for Tufte_Book.xhtml)
> > > > > > > > > > Error: Bad value "content-type" for attribute
> "http-equiv" on
> > > > > > > > element "meta".
> > > > > > > > > > From line 5, column 1 to line 5, column 68 in
> resource
> > > > > > > > > >
> > > > > > > >
> file:/usr9/BUILD/Mint21/BuildLyxGitQt5.15.3local-gcc12.1.0/autotests/out-home/AbC_wGZLha/examples/es/Books/Tufte_Book.xhtml
> > > > > > > >
> > > > > > > > > > Document checking completed.
> > > > > > > > > > > Found 3 validation errors!
> > > > > > > > > >
> > > > > > > > > This one should be fixed at a5c6215e. I still get two
> warnings with the
> > > > > > > > latest output,
> > > > > > > > > but they cannot be fixed unless we decide we do not
> generate XML-valid
> > > > > > > > HTML at all
> > > > > > > > > (which might be very disruptive for our users).
> > > > > > > > >
> > > > > > > >
> > > > > > > > Not here. The error is the same as before.
> > > > > > > > Error: Bad value "content-type" for attribute
> "http-equiv" on
> > > > > > > > element "meta".
> > > > > > > > Also the test export/mathmacros/testcases_basic_xhtml
> produces  plenty of
> > > > > > > > Error: Text not allowed in element "mstyle" in this
> context
> > > > > > > >
> > > > > > >
> > > > > > > That's strange, because all 178 documents (including
> Tufte_book, but not
> > > > > > > mathmacros/testcases_basic) do not produce a single validation
> error on my
> > > > > > > machine: generating the XHTML for Tufte_Book and validating it
> manually (
> > > > > > > https://validator.nu/, it's advertised as the same software)
> doesn't yield
> > > > > > > any error. However, testcases_basic is not included in the
> list of tests I
> > > > > > > run. I'm attaching the log to check for differences.
> > > > > > >
> > > > > > > For export/mathmacros/testcases_basic_xhtml, it's a bug in the
> MathML
> > > > > > > implementation, the mstyle tag should be an mtext (according
> to what the
> > > > > > > spec and MathType say: mstyle was just for text, but is not
> really useful
> > > > > > > anymore; mtext can contain raw text). It should be fixed at
> edcaad24; I'm
> > > > > > > working on a related validation error (triggered in the same
> document with
> > > > > > > this patch).
> > > > > >
> > > > > > There is no attachment in your mail.
> > > > > >
> > > > > > Running the full ctest on the xhtml
> > > > > >  $ ctest -R '_xhtml$' -j24
> > > > > > gives here
> > > > > >  0% tests passed, 421 tests failed out of 421
> > > > > > .
> > > > > > Moreover, there are now 16 assertions while exporting.
> > > > > > autotests/export/docbook/

Re: Using lyxhtml_validity.py

[Thibaut Cuvelier]

On Sun, 8 Jan 2023 at 09:31, Kornel Benko  wrote:

> Am Sun, 8 Jan 2023 00:59:34 +0100
> schrieb Thibaut Cuvelier :
>
> > On Sat, 7 Jan 2023 at 17:10, Kornel Benko  wrote:
> >
> > > Am Sat, 7 Jan 2023 16:26:03 +0100
> > > schrieb Thibaut Cuvelier :
> > >
> > > > > After your recent changes, the number of errors decreased :)
> > > > >
> > > > > I got now (for Tufte_Book.xhtml)
> > > > > Error: Bad value "content-type" for attribute "http-equiv"
> on
> > > element "meta".
> > > > > From line 5, column 1 to line 5, column 68 in resource
> > > > >
> > >
> file:/usr9/BUILD/Mint21/BuildLyxGitQt5.15.3local-gcc12.1.0/autotests/out-home/AbC_wGZLha/examples/es/Books/Tufte_Book.xhtml
> > > > > Document checking completed.
> > > > > > Found 3 validation errors!
> > > > >
> > > > This one should be fixed at a5c6215e. I still get two warnings with
> the
> > > latest output,
> > > > but they cannot be fixed unless we decide we do not generate
> XML-valid
> > > HTML at all
> > > > (which might be very disruptive for our users).
> > > >
> > >
> > > Not here. The error is the same as before.
> > > Error: Bad value "content-type" for attribute "http-equiv" on
> > > element "meta".
> > > Also the test export/mathmacros/testcases_basic_xhtml produces  plenty
> of
> > > Error: Text not allowed in element "mstyle" in this context
> > >
> >
> > That's strange, because all 178 documents (including Tufte_book, but not
> > mathmacros/testcases_basic) do not produce a single validation error on
> my
> > machine: generating the XHTML for Tufte_Book and validating it manually (
> > https://validator.nu/, it's advertised as the same software) doesn't
> yield
> > any error. However, testcases_basic is not included in the list of tests
> I
> > run. I'm attaching the log to check for differences.
> >
> > For export/mathmacros/testcases_basic_xhtml, it's a bug in the MathML
> > implementation, the mstyle tag should be an mtext (according to what the
> > spec and MathType say: mstyle was just for text, but is not really useful
> > anymore; mtext can contain raw text). It should be fixed at edcaad24; I'm
> > working on a related validation error (triggered in the same document
> with
> > this patch).
>
> There is no attachment in your mail.
>
> Running the full ctest on the xhtml
>  $ ctest -R '_xhtml$' -j24
> gives here
>  0% tests passed, 421 tests failed out of 421
> .
> Moreover, there are now 16 assertions while exporting.
> autotests/export/docbook/Linguistics.lyx
> doc/UserGuide.lyx
> doc/ar/UserGuide.lyx
> doc/ja/UserGuide.lyx
> doc/ru/UserGuide.lyx
> examples/Modules/Linguistics.lyx
> examples/de/Modules/Linguistics.lyx
> examples/es/Modules/Linguistics.lyx
> examples/fr/Modules/Linguistics.lyx
> examples/ja/Modules/Linguistics.lyx
> doc/Math.lyx
> doc/es/Math.lyx
> doc/de/Math.lyx
> doc/fr/Math.lyx
> doc/ru/Math.lyx
> doc/ja/Math.lyx
>
> The assertion in Linguistics.lyx is triggered only if lyx is compiled with
> for debugging.
>  "support/lassert.cpp (52): ASSERTION ucs4[i] < 0x80 VIOLATED IN
>  /usr2/src/lyx/lyx-git/src/support/docstring.cpp:65
>
> Should I provide you with my ctest-changes? I feel unconfortable to commit
> something
> producing errors while running ctest. OTOH, errors should be corrected.
>

The assertion could be fixed by my latest commit,
1b09bc965d
. That code should never have made it to a commit in the first place, but
it's fixed.

If you could send me your CTest patch, I could try to replicate the
failures locally.

(By the way, here is the missing attachment.)
Exporting 178 LyX files to LyXHTML format in the directory 
C:\Users\Thibaut\AppData\Local\Temp\tmpqh7ad5qd
* Generating MissingEndLayoutBetweenTables.lyx...
> Done generating 
> D:\LyX\lyx-unstable\autotests\export\MissingEndLayoutBetweenTables.lyx to 
> C:\Users\Thibaut\AppData\Local\Temp\tmpqh7ad5qd\MissingEndLayoutBetweenTables.lyx
* Generating mixing_inTitle_layouts.lyx...
> Done generating 
> D:\LyX\lyx-unstable\autotests\export\mixing_inTitle_layouts.lyx to 
> C:\Users\Thibaut\AppData\Local\Temp\tmpqh7ad5qd\mixing_inTitle_layouts.lyx
* Generating WrongDfnTagHandling.lyx...
> Done generating D:\LyX\lyx-unstable\autotests\export\WrongDfnTagHandling.lyx 
> to C:\Users\Thibaut\AppData\Local\Temp\tmpqh7ad5qd\WrongDfnTagHandling.lyx
* Generating A0_Poster_Simple.

Re: [LyX/master] InsetIndex: make a condition more bullet-proof, a nullptr could be dereferenced.

[Thibaut Cuvelier]

On Sun, 8 Jan 2023 at 22:46, Jean-Marc Lasgouttes 
wrote:

> Le 08/01/2023 à 22:39, Richard Kimberly Heck a écrit :
> > On 1/8/23 15:21, Thibaut Cuvelier wrote:
> >> commit 2d56c01dcfaf04744ab6d854af3965919cc07b82
> >> Author: Thibaut Cuvelier 
> >> Date:   Sun Jan 8 22:19:39 2023 +0100
> >>
> >>  InsetIndex: make a condition more bullet-proof, a nullptr could
> >> be dereferenced.
> >>  Error noticed by Coverity:
> >>  *** CID 382777:  Memory - illegal accesses  (RETURN_LOCAL)
> >>  /home/lasgoutt/src/lyx/coverity/lyx/src/insets/InsetIndex.cpp:
> >> 1866 in
> >>
> _ZNK3lyx15InsetPrintIndex5xhtmlB5cxx11ERNS_9XMLStreamERKNS_12OutputParamsE()
> >>  1860
> >>  1861// Collect the index entries in a form we can use
> >> them.
> >>  1862vector entries;
> >>  1863const docstring & indexType =
> >> params().getParamOr("type", from_ascii("idx"));
> >>  1864for (const TocItem& item : *toc) {
> >>  1865const auto* inset = static_cast >> InsetIndex*>(&(item.dit().inset()));
> >>  >>> CID 382777:  Memory - illegal accesses  (RETURN_LOCAL)
> >>  >>> Using "indexType", which points to an out-of-scope
> >> temporary variable of type "lyx::docstring const".
> >
> > Isn't the warning rather that getParamOr could return a reference to
> > 'from_ascii("idx")', which coverity is saying is now out of scope? Is
> > that OK? Maybe it wants us to declare that separately?
>
>
> That's my reading too.
>

Thanks for your readings :)! I changed the code to have a separate
declaration of the default value.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Using lyxhtml_validity.py

[Thibaut Cuvelier]

On Sat, 7 Jan 2023 at 17:10, Kornel Benko  wrote:

> Am Sat, 7 Jan 2023 16:26:03 +0100
> schrieb Thibaut Cuvelier :
>
> > > After your recent changes, the number of errors decreased :)
> > >
> > > I got now (for Tufte_Book.xhtml)
> > > Error: Bad value "content-type" for attribute "http-equiv" on
> element "meta".
> > > From line 5, column 1 to line 5, column 68 in resource
> > >
> file:/usr9/BUILD/Mint21/BuildLyxGitQt5.15.3local-gcc12.1.0/autotests/out-home/AbC_wGZLha/examples/es/Books/Tufte_Book.xhtml
> > > Document checking completed.
> > > > Found 3 validation errors!
> > >
> > This one should be fixed at a5c6215e. I still get two warnings with the
> latest output,
> > but they cannot be fixed unless we decide we do not generate XML-valid
> HTML at all
> > (which might be very disruptive for our users).
> >
>
> Not here. The error is the same as before.
> Error: Bad value "content-type" for attribute "http-equiv" on
> element "meta".
> Also the test export/mathmacros/testcases_basic_xhtml produces  plenty of
> Error: Text not allowed in element "mstyle" in this context
>

That's strange, because all 178 documents (including Tufte_book, but not
mathmacros/testcases_basic) do not produce a single validation error on my
machine: generating the XHTML for Tufte_Book and validating it manually (
https://validator.nu/, it's advertised as the same software) doesn't yield
any error. However, testcases_basic is not included in the list of tests I
run. I'm attaching the log to check for differences.

For export/mathmacros/testcases_basic_xhtml, it's a bug in the MathML
implementation, the mstyle tag should be an mtext (according to what the
spec and MathType say: mstyle was just for text, but is not really useful
anymore; mtext can contain raw text). It should be fixed at edcaad24; I'm
working on a related validation error (triggered in the same document with
this patch).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Using lyxhtml_validity.py

[Thibaut Cuvelier]

On Sat, 7 Jan 2023 at 10:41, Kornel Benko  wrote:

> Am Sat, 7 Jan 2023 03:59:54 +0100
> schrieb Thibaut Cuvelier :
>
> > On Sat, 31 Dec 2022 at 10:37, Kornel Benko  wrote:
> >
> > > Hi Thibaut,
> > > I started to integrate (a modified) version of lyxhtml_validity.py.
> > > But I am getting errors like in the attached.
> > >
> >
> > Hi Kornel,
> >
> > It may very well be the latest patches I got for XHTML that trigger
> > different code paths for the validator (I haven't run it yet since the
> > switch to XHTML 5): some errors and warnings are related to the
> conversion
> > to XHTML5, others just didn't trigger before.
> >
> > Error: Bad value "en_US" for attribute "lang" on element "html": The
> > language subtag "en_us" is not a valid language subtag.
> > This problem should be fixed by switching lib/languages' LangCode to
> BCP47,
> > as suggested as a TODO in the comments. I implemented a quick fix in
> > 26e6b1c2. As these are the only two places in LyX where the conversion is
> > needed, I believe it is sufficient for now.
> >
> > Error: Bad value "Content-type" for attribute "http-equiv" on element
> > "meta".
> > The value must be in lower case, i.e. "content-type" (
> > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta). This is
> > fixed at cabb12ba.
> >
> > Error: A document must not include both a "meta" element with an
> > "http-equiv" attribute whose value is "content-type", and a "meta"
> element
> > with a "charset" attribute.
> > I removed one occurrence (the charset, because it is the newest and has
> the
> > worst support among ancient browsers, pre-2010 roughly, and I had to pick
> > one).
> >
> > Error: CSS: "font-weight": "medium" is not a "font-weight" value.
> > That one is more tricky, it's a problem when defining a style. That's
> fixed
> > as of 4c1f9d11.
> >
> > Warning:  The "type" attribute for the "style" element is not needed and
> > should be omitted.
> > Not an error per se, but removing the deprecated argument shouldn't be a
> > problem even for ancient browsers (only CSS was ever implemented, after
> > all). https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style
> Fixed
> > at fb4a2657.
> >
> > Warning: Section lacks heading. Consider using "h2"-"h6" elements to add
> > identifying headings to all sections.
> > Not a serious error, but semantically the XHTML code could be much better
> > (that could help with accessibility, for instance). Here is an excerpt
> for
> > the Tufte example you are using:
> > 
> >   The Features of the
> > Tufte-book Class
> > This  really should be a . I'm implementing a change in
> > the layouts themselves for this (051c5f27). The other possibility would
> be
> > to change Layout::htmltag() to return hX instead of div for sectioning
> > elements, based on toclevel; the problem is that we would need to convert
> > toclevel to an integer between 1 and 6. I remember seeing horrible values
> > (including -1000, but also -1 for Beamer parts and other layouts), making
> > me wary: is it possible to write simple code that works automagically for
> > every interesting case?
> >
> > In any case, the script works as expected :)!
>
> After your recent changes, the number of errors decreased :)
>
> I got now (for Tufte_Book.xhtml)
> Error: Bad value "content-type" for attribute "http-equiv" on
> element "meta".
> From line 5, column 1 to line 5, column 68 in resource
>
> file:/usr9/BUILD/Mint21/BuildLyxGitQt5.15.3local-gcc12.1.0/autotests/out-home/AbC_wGZLha/examples/es/Books/Tufte_Book.xhtml
> Document checking completed.
> > Found 3 validation errors!
>

This one should be fixed at a5c6215e. I still get two warnings with the
latest output, but they cannot be fixed unless we decide we do not generate
XML-valid HTML at all (which might be very disruptive for our users).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Using lyxhtml_validity.py

[Thibaut Cuvelier]

On Sat, 31 Dec 2022 at 10:37, Kornel Benko  wrote:

> Hi Thibaut,
> I started to integrate (a modified) version of lyxhtml_validity.py.
> But I am getting errors like in the attached.
>

Hi Kornel,

It may very well be the latest patches I got for XHTML that trigger
different code paths for the validator (I haven't run it yet since the
switch to XHTML 5): some errors and warnings are related to the conversion
to XHTML5, others just didn't trigger before.

Error: Bad value "en_US" for attribute "lang" on element "html": The
language subtag "en_us" is not a valid language subtag.
This problem should be fixed by switching lib/languages' LangCode to BCP47,
as suggested as a TODO in the comments. I implemented a quick fix in
26e6b1c2. As these are the only two places in LyX where the conversion is
needed, I believe it is sufficient for now.

Error: Bad value "Content-type" for attribute "http-equiv" on element
"meta".
The value must be in lower case, i.e. "content-type" (
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta). This is
fixed at cabb12ba.

Error: A document must not include both a "meta" element with an
"http-equiv" attribute whose value is "content-type", and a "meta" element
with a "charset" attribute.
I removed one occurrence (the charset, because it is the newest and has the
worst support among ancient browsers, pre-2010 roughly, and I had to pick
one).

Error: CSS: "font-weight": "medium" is not a "font-weight" value.
That one is more tricky, it's a problem when defining a style. That's fixed
as of 4c1f9d11.

Warning:  The "type" attribute for the "style" element is not needed and
should be omitted.
Not an error per se, but removing the deprecated argument shouldn't be a
problem even for ancient browsers (only CSS was ever implemented, after
all). https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style Fixed
at fb4a2657.

Warning: Section lacks heading. Consider using "h2"-"h6" elements to add
identifying headings to all sections.
Not a serious error, but semantically the XHTML code could be much better
(that could help with accessibility, for instance). Here is an excerpt for
the Tufte example you are using:

  The Features of the
Tufte-book Class
This  really should be a . I'm implementing a change in
the layouts themselves for this (051c5f27). The other possibility would be
to change Layout::htmltag() to return hX instead of div for sectioning
elements, based on toclevel; the problem is that we would need to convert
toclevel to an integer between 1 and 6. I remember seeing horrible values
(including -1000, but also -1 for Beamer parts and other layouts), making
me wary: is it possible to write simple code that works automagically for
every interesting case?

In any case, the script works as expected :)!
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: DocBook change: use a stack of fonts

[Thibaut Cuvelier]

On Sun, 1 Jan 2023 at 13:02, Kornel Benko  wrote:

> Am Tue, 27 Dec 2022 02:13:15 +0100
> schrieb Thibaut Cuvelier :
>
> > Dear list,
> >
> > To solve https://www.lyx.org/trac/ticket/12585, I wrote the attached
> patch.
> > Basically, LyX now considers the order of font tags when closing them,
> > otherwise you get strange results like in the ticket. The bug is quite
> > serious, actually, even though I don't believe many users will hit it.
> >
> > I'd like help on two points:
> > - code review
> > - running the test suite (ctest -R "_docbook")
> >
> > Currently, I cannot run the DocBook test suite due to Perl errors. I'm
> > quite ignorant about Perl, so I'm not sure what I should do about the
> > issue. I understood that the XML::Parser module can't be found, but perl
> -e
> > "use XML::Parser" and perl -e "use XML::Parser::Expat" run without
> > troubles. Here is the log from CTest:
> >
> > 266: -- Expected result file
> >
> "D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/AbC_9MGmGf/export/docbook/LFUNs.xml"
> > exists
> > 266: -- Calling C:/Strawberry/perl/bin/perl.exe
> > "D:/LyX/lyx-unstable/development/autotests/xmlParser.pl"
> > "export/docbook/LFUNs.xml"
> > 266: -- Can't load
> > 'C:/Strawberry/perl/vendor/lib/auto/XML/Parser/Expat/Expat.xs.dll' for
> > module XML::Parser::Expat: load_file:The specified module could not be
> > found at C:/Strawberry/perl/lib/XSLoader.pm line 93.
> > 266:  at C:/Strawberry/perl/vendor/lib/XML/Parser/Expat.pm line 29.
> > 266: Compilation failed in require at
> > C:/Strawberry/perl/vendor/lib/XML/Parser.pm line 18.
> > 266: BEGIN failed--compilation aborted at
> > C:/Strawberry/perl/vendor/lib/XML/Parser.pm line 22.
> > 266: Compilation failed in require at
> > D:/LyX/lyx-unstable/development/autotests/xmlParser.pl line 4.
> > 266: BEGIN failed--compilation aborted at
> > D:/LyX/lyx-unstable/development/autotests/xmlParser.pl line 4.
> > 266:
> > 266: -- Calling:
> >
> C:/Strawberry/perl/bin/perl.exeD:/LyX/lyx-unstable/development/autotests/filterXml4Sax.pl
> >
> D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/export/docbook/LFUNs.xml
> > 266: -- Errors from xmllint: Could not run xmllint
> > 266:
> > 266: -- Msg Summary:
> > 266: -- OK: Exporting
> >
> "D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/AbC_9MGmGf/export/docbook/LFUNs.lyx"
> > to format docbook5
> > 266: -- Error: Checking
> >
> "D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/AbC_9MGmGf/export/docbook/LFUNs.xml"
> > with xmlParser.pl
> > 266: -- Error: Checking
> >
> "D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/AbC_9MGmGf/export/docbook/LFUNs.xml"
> > with C:/Strawberry/c/bin/xmllint.exe
> > 266: -- Exporting export/docbook/LFUNs.lyx to docbook5
> >
> > Here is my small debugging session:
> >
> > C:\Users\Thibaut\Documents>perl -e "use XML::Parser"
> >
> > C:\Users\Thibaut\Documents>perl -e "use XML::Parser::Expat"
> >
> > C:\Users\Thibaut\Documents>where perl
> > C:\Strawberry\perl\bin\perl.exe
> >
> > (By the way, the "lyx-windows-deps-msvc2017" archive should be updated
> with
> > the contents of
> > http://xmlsoft.org/sources/win32/64bit/libxml2-2.9.3-win32-x86_64.7z to
> > include xmllint.)
> >
> > If anyone can lend me a hand either by testing the patch locally or by
> > troubleshooting the test suite, I'd be really grateful!
> >
> > All the best,
> > Thibaut Cuvelier
>
> What could you do, is to call xmlParser.pl directly to check if it working
>
> $ perl D:/LyX/lyx-unstable/development/autotests/xmlParser.pl
> some_test_file.xml
> This should give the same error. In this case check if
> C:/Strawberry/perl/vendor/lib/auto/XML/Parser/Expat/Expat.xs.dll exists.
> (Maybe it is in
> the D: partition?)
>

I gave this command a try, but it didn't yield any error. Actually, I got a
representation of the XML tree:

C:\Users\Thibaut\Documents>perl
D:/LyX/lyx-unstable/development/autotests/xmlParser.pl
"D:\LyX\lyx-unstable\autotests\export\docbook\abstract_list.xml"
\\ (lang de_DE version 5.2)
article || #10;
article \\ ()
article info || #10;
article info \\ ()
article info title || LyX-Anpassung:

Would it be possible that it is due to some PATH issue, correctly set when
I run Strawberry Perl (with its own shell configuration) and not when I
just add perl.exe to the PATH for the test suite? I see that perl.exe is in
C:\Strawberry\perl\bin, while Expat's DLL is in C:\Strawberry\c\bin.

In any case, I don't believe the Perl code is to blame.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Thibaut Cuvelier]

On Sat, 31 Dec 2022 at 09:35, Udicoudco  wrote:

>
>
> In the last patch i sent only one module that support List of Theorems.
> In that module the theorems are numbered by type and within sections,
> Should I add new ones to support different numbering format?
> I don't want to ֲclog the modules menu too much.
>

How many such options would you add? Isn't it possible to implement the new
options using arguments? Otherwise, I don't think it's too much of a
problem to have many entries in the Modules menu, because it was
restructured with 2.4. But having too many variants of Theorems might be a
problem for beginners (I already had troubles with the AMS and non-AMS,
extended or not, numbered by such and such, for the record).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Thibaut Cuvelier]

On Sat, 31 Dec 2022 at 03:36, Scott Kostyshak  wrote:

> On Sat, Dec 31, 2022 at 02:00:34AM +0100, Thibaut Cuvelier wrote:
> > I've pushed your patch online: 42c2a25fb8. I had to rebase it manually, I
> > hope I didn't make too many mistakes. I'm also attaching the patch to
> this
> > email so that you can check it more easily if you want.
> >
> > (If someone can add Udi to the blanket permissions, here is the link on
> the
> > mailing list: https://marc.info/?l=lyx-devel=165779733507955=2)
> >
> > Thibaut Cuvelier
>
> Some ctests are failing on current master. I'm not sure if it's because
> of your recent commit or not.
>
> But, for example, if I open up lib/doc/Additional.lyx, I get a message
> about a module that is not found: theorems-ams-extended
>
> Also some tex2lyx tests are failing. Can you check those as well?
>

Given the failures, I'm reverting the commit, especially as Udi is working
on a new version. For the missing modules, I suppose that Udi should
restore the corresponding .module files, even if they just include
something else, or could we do something about it in lyx2lyx? (I.e. does
this change warrant a format update?)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Thibaut Cuvelier]

Hi,

I'm jumping back in this discussion. There have been recent changes in the
DocBook implementation of theorems. Instead of setting DocBookTag and
DocBookAttr like this:

DocBookTagpara
DocBookAttr   role='theorem'

we now use a wrapper to delimit theorems:

DocBookWrapperTag figure
DocBookWrapperAttrrole='theorem'
DocBookTagpara
DocBookGenerateTitle  true

For your other theorems, just update the line role= with the right kind of
element (just like on master). I can take care of this step when merging
your patch, as there seems to be some consensus around it.

I noticed you asked whether anything was required for lists of theorems and
the list: no, the DocBook processor is supposed to take care of that.

As you gave permission to use your patch under the GPL in an earlier
message (why isn't it listed on https://www.lyx.org/BlanketPermission?),
I'm proceeding with integrating your patch :).

All the best,
Thibaut Cuvelier


On Mon, 7 Nov 2022 at 23:29, Paul A. Rubin  wrote:

> On 10/13/22 02:45, Udicoudco wrote:
>
>
>
> On Fri, Sep 23, 2022 at 12:25 AM Paul A. Rubin 
> wrote:
>
>> On 9/19/22 22:26, Udicoudco wrote:
>>
>> I've noticed that the definition environment is not numbered in the
>> output files. After checking the module again, I hope there are no
>> issues any more. The fixed module is attached.
>>
>> Regards,
>> Udi
>>
>>
>> I noticed a new pathology with this version. Steps to reproduce are as
>> follows:
>>
>>1. Compile the test_thmtools_module.lyx document (which works fine).
>>2. Delete the entire contents of section 2, other than the section
>>heading, and recompile. I've attached the PDF I get. Note the garbled
>>contents where the theorem lists go.
>>3. Make any minor edit to the document (to force a fresh compile) and
>>recompile. The output is as expected.
>>
>> HTH,
>>
>> Paul
>> --
>>
>
> Hi Paul,
>
> Sorry for the late reply, it is the holiday season in my country.
>
> I've managed to solve this issue with a simple trick. The updated module
> can be found in here <https://github.com/Udi-Fogiel/LyX-thmtools>.
> If you will try it again, I would be glad to hear from you.
>
> Best Regards,
> Udi
>
>> lyx-devel mailing list
>> lyx-devel@lists.lyx.org
>> http://lists.lyx.org/mailman/listinfo/lyx-devel
>>
>
> Udi,
>
> Speaking of late replies, it's my turn to apologize. You posted this just
> as I was heading out to a conference. Since getting back, I've been
> (slowly) catching up on accumulated work.
>
> I just tested the updated module, and can confirm that the problem I
> noticed is gone. Good job!
>
> Paul
>
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Master broken due to febd1855eb

[Thibaut Cuvelier]

On Wed, 28 Dec 2022 at 04:03, Scott Kostyshak  wrote:

> On Wed, Dec 28, 2022 at 02:34:50AM +0100, Thibaut Cuvelier wrote:
> > On Tue, 27 Dec 2022 at 23:41, Daniel  wrote:
> >
> > > With febd1855eb ("XML: overhaul the tag-comparison operators."), I get
> > >
> > > /src/tex2lyx/dummy_impl.cpp:102:16: error: out-of-line
> > >definition of 'operator==' does not match any declaration in
> > >'lyx::xml::StartTag'
> > > bool StartTag::operator==(FontTag const & rhs) const { return rhs ==
> > > *this; }
> > > ^~~~
> > > /src/tex2lyx/dummy_impl.cpp:103:15: error: out-of-line
> > >definition of 'operator==' does not match any declaration in
> > >'lyx::xml::FontTag'
> > > bool FontTag::operator==(StartTag const & tag) const { FontTag const *
> c...
> > >^~~~
> > >
> >
> > I've just pushed 8b5bfa971b to fix this problem. (As this code was
> > seemingly only necessary on Windows: tex2lyx now compiles just fine with
> > VC19.) Sorry about that.
>
> I have 8b5bfa971b pulled in but I get:
>
> [ 97%] Building CXX object
> src/tests/CMakeFiles/check_layout.dir/dummy_functions.cpp.o
> cd /home/scott/lyxbuilds/master-master/CMakeBuild/src/tests &&
> /usr/lib/ccache/clang++ -DBOOST_USER_CONFIG="" -DQT_CORE_LIB
> -DQT_GUI_LIB -I/home/scott/lyxbuilds/master-master/CMakeBuild
> -I/home/scott/lyxbuilds/master-master/repo/src -I/usr/include/enchant-2
> -I/usr/include/hunspell
> -I/home/scott/lyxbuilds/master-master/repo/3rdparty/boost
> -I/home/scott/lyxbuilds/master-master/repo/3rdparty/nod
> -I/home/scott/lyxbuilds/master-master/CMakeBuild/src
> -I/home/scott/lyxbuilds/master-master/repo/src/support/tests
> -I/home/scott/lyxbuilds/master-master/repo/src/tests -isystem
> /usr/include/x86_64-linux-gnu/qt5 -isystem
> /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem
> /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem
> /usr/include/x86_64-linux-gnu/qt5/QtGui -Wall -Wextra -Wno-deprecated-copy
> --std=c++20 -Wno-deprecated-register -fno-strict-aliasing  -O0 -g3
> -D_DEBUG   -Werror -fPIC -std=c++20 -MD -MT
> src/tests/CMakeFiles/check_layout.dir/dummy_functions.cpp.o -MF
> CMakeFiles/check_layout.dir/dummy_functions.cpp.o.d -o
> CMakeFiles/check_layout.dir/dummy_functions.cpp.o -c
> /home/scott/lyxbuilds/master-master/repo/src/tests/dummy_functions.cpp
> /home/scott/lyxbuilds/master-master/repo/src/tests/dummy_functions.cpp:56:16:
> error: out-of-line definition of 'operator==' does not match any
> declaration in 'lyx::xml::StartTag'
> bool StartTag::operator==(FontTag const & rhs) const { return rhs ==
> *this; }
>^~~~
> /home/scott/lyxbuilds/master-master/repo/src/tests/dummy_functions.cpp:57:17:
> error: out-of-line definition of 'operator==' does not match any
> declaration in 'lyx::xml::FontTag'
>   bool FontTag::operator==(StartTag const & tag) const { FontTag const *
> const ftag = tag.asFontTag();   if (!ftag) return false; return (font_type_
> == ftag->font_type_); }
> ^~~~
> 2 errors generated.
>

7a67302c01
 should fix it.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Master broken due to febd1855eb

[Thibaut Cuvelier]

On Tue, 27 Dec 2022 at 23:41, Daniel  wrote:

> With febd1855eb ("XML: overhaul the tag-comparison operators."), I get
>
> /src/tex2lyx/dummy_impl.cpp:102:16: error: out-of-line
>definition of 'operator==' does not match any declaration in
>'lyx::xml::StartTag'
> bool StartTag::operator==(FontTag const & rhs) const { return rhs ==
> *this; }
> ^~~~
> /src/tex2lyx/dummy_impl.cpp:103:15: error: out-of-line
>definition of 'operator==' does not match any declaration in
>'lyx::xml::FontTag'
> bool FontTag::operator==(StartTag const & tag) const { FontTag const * c...
>^~~~
>

I've just pushed 8b5bfa971b to fix this problem. (As this code was
seemingly only necessary on Windows: tex2lyx now compiles just fine with
VC19.) Sorry about that.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: DocBook change: use a stack of fonts

[Thibaut Cuvelier]

On Tue, 27 Dec 2022 at 05:42, Richard Kimberly Heck 
wrote:

> On 12/26/22 21:46, Thibaut Cuvelier wrote:
>
> On Tue, 27 Dec 2022 at 03:20, Richard Kimberly Heck 
> wrote:
>
>> On 12/26/22 20:13, Thibaut Cuvelier wrote:
>> > Dear list,
>> >
>> > To solve https://www.lyx.org/trac/ticket/12585, I wrote the attached
>> > patch. Basically, LyX now considers the order of font tags when
>> > closing them, otherwise you get strange results like in the ticket.
>> > The bug is quite serious, actually, even though I don't believe many
>> > users will hit it.
>>
>> I struggled with that when writing the original XHTML code. It's hard to
>> get right. I know it sometimes would fail. Is this same code also used
>> with XHTML now? Or would it need to be adapted for that case?
>>
>
> I've tested this case and it looks like the XHTML code did the right thing
> there. It's a part I rewrote for DocBook, introducing a few bugs.Here is
> the output from XHTML for the same file:
>
> norm emph
> emph-bold bold norm
>
> I don't understand why it is producing the right output while DocBook did
> not. Maybe the pending tags or the special code for font tags from
> XMLStream kick in. If that's the case, it's a bit strange that XMLStream
> deals with this kind of issue (it feels like XMLStream is doing work at
> multiple levels of abstraction).
>
> I wish I'd commented this code a bit more. I thought I did that pretty
> well.
>
> Anyway, after digging into it, the magic happens in
> XMLStream::operator<<(EndTag), though the font part specifically is handled
> in Paragraph::simpleLyXHTMLOnePar.
>
Thanks for having a second look. I reworked my patch to use the existing
features of XMLStream: the bug is due to a faulty comparison between tags.
The new patch is much smaller and yields the same benefits while being
easier to debug. There are no newer features of C++ used here. I've
explained more details in the commit message.


0001-XML-overhaul-the-tag-comparison-operators.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Fwd: [Review requested] New DocBook layout parameter

[Thibaut Cuvelier]

On Tue, 27 Dec 2022 at 05:17, Richard Kimberly Heck 
wrote:

> On 12/26/22 21:27, Thibaut Cuvelier wrote:
>
> On Tue, 27 Dec 2022 at 03:11, Richard Kimberly Heck 
> wrote:
>
>> On 12/26/22 20:01, Thibaut Cuvelier wrote:
>>
>> Riki, let me know :)!
>>
>> In another email, I said:
>>
>> I am planning to do the tarball tomorrow, so I guess the question is
>> whether these changes can be **completed** by then. Since they don't
>> affect really core code, I'm not too worried about them being mature yet.
>>
>> So if you think this is really done, go ahead. If you're not sure, then
>> let's wait.
>>
> I don't know what I could add or remove. The tests pass and I manually
> checked that the new behaviour is the expected one.
>
>> I'm attaching a new version of the patch with the updated layout2layout
>> script (including a change for layout version 98 that was skipped, if I
>> understand correctly). There is also a second patch that updates the
>> layouts.
>>
>> That's a bit confusing. You just need to handle up to format 98. It's the
>> OLD format number that's being tested in those conditions. So you want if
>> 87 <= format <= 98.
>>
> I misunderstood the script, then! I fixed that locally.
>
>> That said, are we sure there's nothing to do here? Suppose someone has a
>> custom layout for some remark-like construction. Do we just want to leave
>> that as is?
>>
> Since it's an extension of features that have never been released (apart
> from alphas and betas), I don't think there are many such layouts; I
> suppose that these users will have a look at the final set of features when
> 2.4 is out. Even if there were, I really don't know what I could do: even
> if the custom layout is a new theorem-like environment, maybe the user is
> completely OK with what they currently have (maybe they have a wrapper tag
> that does what they want, or they don't care about wrapper tags at all).
> The only conversion that would be mostly safe is detecting the pattern I
> was using in the layout files, which is maybe too specific.
>
> OK, then. Go ahead and commit.
>
Done, thanks!
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: DocBook change: use a stack of fonts

[Thibaut Cuvelier]

On Tue, 27 Dec 2022 at 03:20, Richard Kimberly Heck 
wrote:

> On 12/26/22 20:13, Thibaut Cuvelier wrote:
> > Dear list,
> >
> > To solve https://www.lyx.org/trac/ticket/12585, I wrote the attached
> > patch. Basically, LyX now considers the order of font tags when
> > closing them, otherwise you get strange results like in the ticket.
> > The bug is quite serious, actually, even though I don't believe many
> > users will hit it.
>
> I struggled with that when writing the original XHTML code. It's hard to
> get right. I know it sometimes would fail. Is this same code also used
> with XHTML now? Or would it need to be adapted for that case?
>

I've tested this case and it looks like the XHTML code did the right thing
there. It's a part I rewrote for DocBook, introducing a few bugs.Here is
the output from XHTML for the same file:

norm emph
emph-bold bold norm


I don't understand why it is producing the right output while DocBook did
not. Maybe the pending tags or the special code for font tags from
XMLStream kick in. If that's the case, it's a bit strange that XMLStream
deals with this kind of issue (it feels like XMLStream is doing work at
multiple levels of abstraction).


> I'm no good with tests, but I can review the code. Generally speaking,
> it makes sense to me.
>
> Is [[nodiscard]] something we support now? I've never seen that before.
>

It's actually a C++17 feature, I thought it was an earlier one. I'm
removing it.

The goal is to make users of the function use the returned value: the
compiler throws an error when you're not explicitly using the return value.
For instance, if std::vector::empty is marked as [[nodiscard]], you cannot
mistake the function for clear, because empty has a return value that the
user would have to use.


> > +DocBookFontOperation endTransaction() {
> > +return {.fontsToClose = fontsToClose_, .fontsToOpen =
> > fontsToOpen_};
> > +}
> > +
> What is ".fontsToClose"? What's the dot doing? Is the "=" right? This
> code just confuses me.
>

It looks like the name of this C99 feature is "designated initializers":
when building a struct instance, you can give the name of the fields you
are filling. This is especially useful here to ensure that you are not
mixing the open and close sets (they have the same type).

I can remove it if it's a problem with some compilers. The code would look
like this:

return {fontsToClose_, fontsToOpen_};


0003-DocBook-implement-a-stack-of-fonts.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Fwd: [Review requested] New DocBook layout parameter

[Thibaut Cuvelier]

On Tue, 27 Dec 2022 at 03:11, Richard Kimberly Heck 
wrote:

> On 12/26/22 20:01, Thibaut Cuvelier wrote:
>
> Riki, let me know :)!
>
> In another email, I said:
>
> I am planning to do the tarball tomorrow, so I guess the question is
> whether these changes can be **completed** by then. Since they don't
> affect really core code, I'm not too worried about them being mature yet.
>
> So if you think this is really done, go ahead. If you're not sure, then
> let's wait.
>
I don't know what I could add or remove. The tests pass and I manually
checked that the new behaviour is the expected one.

> I'm attaching a new version of the patch with the updated layout2layout
> script (including a change for layout version 98 that was skipped, if I
> understand correctly). There is also a second patch that updates the
> layouts.
>
> That's a bit confusing. You just need to handle up to format 98. It's the
> OLD format number that's being tested in those conditions. So you want if
> 87 <= format <= 98.
>
I misunderstood the script, then! I fixed that locally.

> That said, are we sure there's nothing to do here? Suppose someone has a
> custom layout for some remark-like construction. Do we just want to leave
> that as is?
>
Since it's an extension of features that have never been released (apart
from alphas and betas), I don't think there are many such layouts; I
suppose that these users will have a look at the final set of features when
2.4 is out. Even if there were, I really don't know what I could do: even
if the custom layout is a new theorem-like environment, maybe the user is
completely OK with what they currently have (maybe they have a wrapper tag
that does what they want, or they don't care about wrapper tags at all).
The only conversion that would be mostly safe is detecting the pattern I
was using in the layout files, which is maybe too specific.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

DocBook change: use a stack of fonts

[Thibaut Cuvelier]

Dear list,

To solve https://www.lyx.org/trac/ticket/12585, I wrote the attached patch.
Basically, LyX now considers the order of font tags when closing them,
otherwise you get strange results like in the ticket. The bug is quite
serious, actually, even though I don't believe many users will hit it.

I'd like help on two points:
- code review
- running the test suite (ctest -R "_docbook")

Currently, I cannot run the DocBook test suite due to Perl errors. I'm
quite ignorant about Perl, so I'm not sure what I should do about the
issue. I understood that the XML::Parser module can't be found, but perl -e
"use XML::Parser" and perl -e "use XML::Parser::Expat" run without
troubles. Here is the log from CTest:

266: -- Expected result file
"D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/AbC_9MGmGf/export/docbook/LFUNs.xml"
exists
266: -- Calling C:/Strawberry/perl/bin/perl.exe
"D:/LyX/lyx-unstable/development/autotests/xmlParser.pl"
"export/docbook/LFUNs.xml"
266: -- Can't load
'C:/Strawberry/perl/vendor/lib/auto/XML/Parser/Expat/Expat.xs.dll' for
module XML::Parser::Expat: load_file:The specified module could not be
found at C:/Strawberry/perl/lib/XSLoader.pm line 93.
266:  at C:/Strawberry/perl/vendor/lib/XML/Parser/Expat.pm line 29.
266: Compilation failed in require at
C:/Strawberry/perl/vendor/lib/XML/Parser.pm line 18.
266: BEGIN failed--compilation aborted at
C:/Strawberry/perl/vendor/lib/XML/Parser.pm line 22.
266: Compilation failed in require at
D:/LyX/lyx-unstable/development/autotests/xmlParser.pl line 4.
266: BEGIN failed--compilation aborted at
D:/LyX/lyx-unstable/development/autotests/xmlParser.pl line 4.
266:
266: -- Calling:
C:/Strawberry/perl/bin/perl.exeD:/LyX/lyx-unstable/development/autotests/filterXml4Sax.pl
 
D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/export/docbook/LFUNs.xml
266: -- Errors from xmllint: Could not run xmllint
266:
266: -- Msg Summary:
266: -- OK: Exporting
"D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/AbC_9MGmGf/export/docbook/LFUNs.lyx"
to format docbook5
266: -- Error: Checking
"D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/AbC_9MGmGf/export/docbook/LFUNs.xml"
with xmlParser.pl
266: -- Error: Checking
"D:/LyX/lyx-unstable/cmake-build-debug/autotests/out-home/AbC_9MGmGf/export/docbook/LFUNs.xml"
with C:/Strawberry/c/bin/xmllint.exe
266: -- Exporting export/docbook/LFUNs.lyx to docbook5

Here is my small debugging session:

C:\Users\Thibaut\Documents>perl -e "use XML::Parser"

C:\Users\Thibaut\Documents>perl -e "use XML::Parser::Expat"

C:\Users\Thibaut\Documents>where perl
C:\Strawberry\perl\bin\perl.exe

(By the way, the "lyx-windows-deps-msvc2017" archive should be updated with
the contents of
http://xmlsoft.org/sources/win32/64bit/libxml2-2.9.3-win32-x86_64.7z to
include xmllint.)

If anyone can lend me a hand either by testing the patch locally or by
troubleshooting the test suite, I'd be really grateful!

All the best,
Thibaut Cuvelier


0003-DocBook-implement-a-stack-of-fonts.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: XHTML ctests failing

[Thibaut Cuvelier]

On Mon, 26 Dec 2022 at 20:56, Kornel Benko  wrote:

> Am Mon, 26 Dec 2022 19:21:48 +0100
> schrieb Thibaut Cuvelier :
>
> > On Mon, 26 Dec 2022 at 09:51, Kornel Benko  wrote:
> >
> > > Am Mon, 26 Dec 2022 01:52:50 -0500
> > > schrieb Scott Kostyshak :
> > >
> > > > A lot of the XHTML ctests just started failing.
> > > >
> > > > Are they passing for others?
> > > >
> > > > Scott
> > >
> > > Same here.
> > > 69% tests passed, 129 tests failed out of 422
> > >
> >
> > I've just pushed 21d1d917ba to fix a lot of failures (at least locally).
> > I'm still running the complete test suite to ensure that there is no
> other
> > failure :).
>
> Thanks a lot.
>
> 100% tests passed, 0 tests failed out of 422
>

I've done a new pass over MathML and XHTML code to remove a few more HTML
entities that were left ( where XXX is not a number, amp, lt, gt). I
don't think any others remain, but they might cause similar issues if a
test case starts exercising those code paths (in case it helps for future
failures).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: XHTML ctests failing

[Thibaut Cuvelier]

On Mon, 26 Dec 2022 at 09:51, Kornel Benko  wrote:

> Am Mon, 26 Dec 2022 01:52:50 -0500
> schrieb Scott Kostyshak :
>
> > A lot of the XHTML ctests just started failing.
> >
> > Are they passing for others?
> >
> > Scott
>
> Same here.
> 69% tests passed, 129 tests failed out of 422
>

I've just pushed 21d1d917ba to fix a lot of failures (at least locally).
I'm still running the complete test suite to ensure that there is no other
failure :).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] LyXHTML: switch the doctype to (X)HTML5 and only output

[Thibaut Cuvelier]

On Sun, 25 Dec 2022 at 22:05, Pavel Sanda  wrote:

> ...
> CXX  insets/InsetSpecialChar.o
> insets/InsetSpecialChar.cpp: In function 'std::string
> lyx::{anonymous}::specialCharKindToXMLEntity(lyx::InsetSpecialChar::Kind)':
> insets/InsetSpecialChar.cpp:569:1: warning: control reaches end of
> non-void function [-Wreturn-type]
>   569 | }
>   | ^
> ...
>

Sorry. That's fixed at 2592a36dae (while keeping the same behaviour).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Merge branch 'features/indexmacros'

[Thibaut Cuvelier]

On Sat, 24 Dec 2022 at 03:49, Scott Kostyshak  wrote:

> On Fri, Dec 23, 2022 at 01:00:59AM +0100, Thibaut Cuvelier wrote:
> > On Mon, 21 Nov 2022 at 08:56, Kornel Benko  wrote:
> >
> > > Am Sun, 20 Nov 2022 15:23:58 -0500
> > > schrieb Scott Kostyshak :
> > >
> > > > On Sun, Nov 20, 2022 at 08:24:41PM +0100, Thibaut Cuvelier wrote:
> > > > > On Sun, 20 Nov 2022 at 16:47, Scott Kostyshak 
> > > wrote:
> > > > >
> > > > > > On Sun, Nov 20, 2022 at 04:33:36PM +0100, Thibaut Cuvelier wrote:
> > > > > > > > When I open the exported de Math.xhtml in Chromium, I get:
> > > > > > > >
> > > > > > > >   "error on line 7159 at column 22: Entity 'imaginary' not
> > > defined"
> > > > > > > >
> > > > > > >
> > > > > > > That's unrelated to this branch, it was a problem in the MathML
> > > > > > > configuration.
> > > > > >
> > > > > > Ah, I was wondering why xmllint didn't catch it but I guess it
> > > doesn't
> > > > > > catch MathML issues. Probably there is a way to catch them in the
> > > > > > ctests, but I don't know if we want to make our ctests more
> strict.
> > > If
> > > > > > we make them more strict, I will bug you more about test
> failures :)
> > > > > >
> > > > >
> > > > > xmllint is probably not the best tool for (X)HTML, it just
> validates
> > > XML
> > > > > syntax (HTML is not necessarily XML, but what LyX generates is;
> there
> > > are
> > > > > many constraints that xmllint doesn't know about).
> > > > >
> > > > > There are many tools to validate HTML as command-line utilities,
> but
> > > most
> > > > > of them are in JavaScript; maybe http://www.html-tidy.org/ could
> be
> > > > > included as a test dependency? It should be more or less easy to
> > > integrate,
> > > > > as it's just C buildable with CMake and no dependency.
> > > >
> > > > I would be happy to help incorporate that if Kornel does not object
> (he
> > > > knows the most about the ctest framework).
> > >
> > > Not objecting.
> > >
> > > > Let's first figure out whether we want the checks in the ctests
> though.
> > > > I think a good rule of thumb is: if a test starts to fail (i.e.,
> suppose
> > > > the test with this stricter check used to pass, but some commit that
> > > > affects XML output causes the test to fail), will you give priority
> to
> > > > either quickly fixing things so that the test passes, or reverting
> the
> > > > commits that caused the tests to fail? If yes, then they are a good
> > > > candidate to be included in the ctests.
> > > >
> > > > If not, probably it is better for you to use the tool locally on your
> > > > side. I can help figure out a script for this as well. For example,
> it
> > > > could just loop through all the .lyx files in the repository, export
> > > > with xhtml, and check which files pass the stricter test. It would be
> > > > easy to set up an ignore list, etc. Or we could put the script in
> > > > https://gitlab.com/scottkosty/lyx-tester which has various scripts
> for
> > > > testing.
> > > >
> > > > Let me know what sounds best.
> > > >
> > > > Scott
> > >
> > > +1
> > >
> >
> > Here is a patch that adds a script that validates every export LyX test
> > case.
>
> Nice, I like it!
>
> > It's not fast to run, approximately 10 minutes (roughly 200 calls to
> > LyX to get the HTML files, then 200 calls to the JVM for validation --
> each
> > time starting from scratch). The slowest part seems to be LyX, though, so
> > that batching the calls to the validator will not drastically cut the run
> > times (maybe 30%).
> >
> > The results are excellent: all files are valid with the current master
> :D!
> > Running the script every so often would keep it that way.
>
> That's great!
>

I've committed it as e44cef2a3c4b3206d828a3c417ad24edd1c1f2a6.


> I suggest you run the tests locally every now and then, and then after
> 2.4.0 release we figure out how to get them into the main ctest
> framework as long as others agree. It's fine that they're slow. As long
> as we can easily choose to not run them (e.g., with the ctest regexes),
> in my opinion it's no problem. Would this plan work for you
>

That's totally fine by me! I've explicitly added it as a TODO in the repo,
like other folders:
33cc71636ffeaae0eae890b08ca6d5eaed7293f3


> > To make its output easier to understand, do you know if there is a way to
> > remove these messages from LyX when it runs in CLI?
> >
> > Warning: Document class not available
> > 
> > The selected document class
> > Springer Monographs (svmono)
> > requires external files that are not available.
> > The document class can still be used, but the
> > document cannot be compiled until the following
> > prerequisites are installed:
> > svmono.cls
> > See section 3.1.2.2 (Class Availability) of the
> > User's Guide for more information.
>
> I don't know.
>
> Scott
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Export to lyxhtml broken

[Thibaut Cuvelier]

On Sun, 20 Sept 2020 at 16:58, Kornel Benko  wrote:

> Am Sun, 20 Sep 2020 11:53:39 +0200
> schrieb Kornel Benko :
>
> > Am Sun, 20 Sep 2020 11:46:36 +0200
> > schrieb Kornel Benko :
> >
> > > Am Sun, 20 Sep 2020 01:38:11 +0200
> > > schrieb Kornel Benko :
> > >
> > > > > > > $ xmllint Welcome.xhtml
> > > > > > > Welcome.xhtml:47: parser error : Entity 'rArr' not defined
> > > > > > > ase use it! Start with the menu  > > > > > style='font-family:sans-serif;'>Help
> > > > > > > ...
> > > > > >
> > > > > > Yes, looks like 'xmllint --sax' does not do what we want ( at
> least for
> > > > > > xhtml)
> > > > > >
> > > > >
> > > > > Maybe  --debugent will? It's supposed to deal with XML entities,
> such as
> > > > > 
> > > >
> > > > Will try tomorrow. Time to go to bed.
> > > >
> > > >   Kornel
> > >
> > > The best I could find was
> > > $ xmllint  --loaddtd --noout
> > > and examine the error output
> > >
> > > Kornel
> >
> > Mark mismatched opening/ending tags in es/UserGuide.xhtml.
> >   $ cd build-dir
> >   $ xmllint --loaddtd --noout autotests/out-home/doc/es/UserGuide.xhtml
> >
> >   Kornel
>
> Attached a minimal example


I've revived the doctype update, I've uploaded two patches to
https://www.lyx.org/trac/ticket/10943 (see my latest comment for
explanations).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Merge branch 'features/indexmacros'

[Thibaut Cuvelier]

On Mon, 21 Nov 2022 at 08:56, Kornel Benko  wrote:

> Am Sun, 20 Nov 2022 15:23:58 -0500
> schrieb Scott Kostyshak :
>
> > On Sun, Nov 20, 2022 at 08:24:41PM +0100, Thibaut Cuvelier wrote:
> > > On Sun, 20 Nov 2022 at 16:47, Scott Kostyshak 
> wrote:
> > >
> > > > On Sun, Nov 20, 2022 at 04:33:36PM +0100, Thibaut Cuvelier wrote:
> > > > > > When I open the exported de Math.xhtml in Chromium, I get:
> > > > > >
> > > > > >   "error on line 7159 at column 22: Entity 'imaginary' not
> defined"
> > > > > >
> > > > >
> > > > > That's unrelated to this branch, it was a problem in the MathML
> > > > > configuration.
> > > >
> > > > Ah, I was wondering why xmllint didn't catch it but I guess it
> doesn't
> > > > catch MathML issues. Probably there is a way to catch them in the
> > > > ctests, but I don't know if we want to make our ctests more strict.
> If
> > > > we make them more strict, I will bug you more about test failures :)
> > > >
> > >
> > > xmllint is probably not the best tool for (X)HTML, it just validates
> XML
> > > syntax (HTML is not necessarily XML, but what LyX generates is; there
> are
> > > many constraints that xmllint doesn't know about).
> > >
> > > There are many tools to validate HTML as command-line utilities, but
> most
> > > of them are in JavaScript; maybe http://www.html-tidy.org/ could be
> > > included as a test dependency? It should be more or less easy to
> integrate,
> > > as it's just C buildable with CMake and no dependency.
> >
> > I would be happy to help incorporate that if Kornel does not object (he
> > knows the most about the ctest framework).
>
> Not objecting.
>
> > Let's first figure out whether we want the checks in the ctests though.
> > I think a good rule of thumb is: if a test starts to fail (i.e., suppose
> > the test with this stricter check used to pass, but some commit that
> > affects XML output causes the test to fail), will you give priority to
> > either quickly fixing things so that the test passes, or reverting the
> > commits that caused the tests to fail? If yes, then they are a good
> > candidate to be included in the ctests.
> >
> > If not, probably it is better for you to use the tool locally on your
> > side. I can help figure out a script for this as well. For example, it
> > could just loop through all the .lyx files in the repository, export
> > with xhtml, and check which files pass the stricter test. It would be
> > easy to set up an ignore list, etc. Or we could put the script in
> > https://gitlab.com/scottkosty/lyx-tester which has various scripts for
> > testing.
> >
> > Let me know what sounds best.
> >
> > Scott
>
> +1
>

Here is a patch that adds a script that validates every export LyX test
case. It's not fast to run, approximately 10 minutes (roughly 200 calls to
LyX to get the HTML files, then 200 calls to the JVM for validation -- each
time starting from scratch). The slowest part seems to be LyX, though, so
that batching the calls to the validator will not drastically cut the run
times (maybe 30%).

The results are excellent: all files are valid with the current master :D!
Running the script every so often would keep it that way.

To make its output easier to understand, do you know if there is a way to
remove these messages from LyX when it runs in CLI?

Warning: Document class not available

The selected document class
Springer Monographs (svmono)
requires external files that are not available.
The document class can still be used, but the
document cannot be compiled until the following
prerequisites are installed:
svmono.cls
See section 3.1.2.2 (Class Availability) of the
User's Guide for more information.


0002-LyXHTML-add-a-script-to-validate-all-the-generated-f.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Fwd: [Review requested] New DocBook layout parameter

[Thibaut Cuvelier]

Dear list,

To solve https://www.lyx.org/trac/ticket/12612, I needed a new layout
parameter for DocBook to generate some content based on paragraph labels.
It draws heavily from LyXHTML code: makeEnvironment in output_xhtml.cpp,
case on environments, label generation (currently, lines 499 to 511).

As I'm still not very confident with layout changes, and especially as LyX
master is maturing, I'm requesting some feedback/review before pushing. I
believe everything is there (code changes, layout version update, changes
in the layout to use the new feature, documentation), with the exception of
updating the version number of all layouts (to avoid cluttering the patch).

By the way, I noticed that the documentation on the new DocBook parameters
for the layouts is truly lacking. I'll try to do something about it.

Thanks in advance!

Thibaut Cuvelier
From f6d49430e08c732dc3f5bb76a80f572f957fce48 Mon Sep 17 00:00:00 2001
From: Thibaut Cuvelier 
Date: Thu, 22 Dec 2022 04:38:36 +0100
Subject: [PATCH] DocBook: add support for DocBookGenerateTitle.

The new parameter allows more flexibility when encoding some elements that have a poor mapping in DocBook, like theorems. The major use is to wrap the environment in a generic container, figure, which requires a title (but none is available).
---
 autotests/export/docbook/theorems-mathml.lyx | 148 +++
 autotests/export/docbook/theorems-mathml.xml |  85 +++
 lib/doc/Customization.lyx|  68 -
 lib/layouts/elsart.layout|  62 ++--
 lib/layouts/theorems-ams-bytype.inc  |  53 +--
 lib/layouts/theorems-ams-chap-bytype.inc |  53 +--
 lib/layouts/theorems-ams.inc |  51 +--
 lib/layouts/theorems-bytype.inc  |  53 +--
 lib/layouts/theorems-starred.inc |  56 +--
 lib/layouts/theorems-without-preamble.inc|  83 ---
 lib/layouts/theorems.inc |  51 +--
 src/Layout.cpp   |   6 +
 src/Layout.h |   8 +-
 src/TextClass.cpp|   2 +-
 src/output_docbook.cpp   |  15 +-
 15 files changed, 662 insertions(+), 132 deletions(-)
 create mode 100644 autotests/export/docbook/theorems-mathml.lyx
 create mode 100644 autotests/export/docbook/theorems-mathml.xml

diff --git a/autotests/export/docbook/theorems-mathml.lyx b/autotests/export/docbook/theorems-mathml.lyx
new file mode 100644
index 00..89281f8332
--- /dev/null
+++ b/autotests/export/docbook/theorems-mathml.lyx
@@ -0,0 +1,148 @@
+#LyX 2.4 created this file. For more info see https://www.lyx.org/
+\lyxformat 613
+\begin_document
+\begin_header
+\save_transient_properties true
+\origin unavailable
+\textclass article
+\use_default_options true
+\begin_modules
+theorems-std
+\end_modules
+\maintain_unincluded_children no
+\language american
+\language_package default
+\inputencoding utf8
+\fontencoding auto
+\font_roman "default" "default"
+\font_sans "default" "default"
+\font_typewriter "default" "default"
+\font_math "auto" "auto"
+\font_default_family default
+\use_non_tex_fonts false
+\font_sc false
+\font_roman_osf false
+\font_sans_osf false
+\font_typewriter_osf false
+\font_sf_scale 100 100
+\font_tt_scale 100 100
+\use_microtype false
+\use_dash_ligatures true
+\graphics default
+\default_output_format default
+\output_sync 0
+\bibtex_command default
+\index_command default
+\float_placement class
+\float_alignment class
+\paperfontsize default
+\spacing single
+\use_hyperref false
+\papersize default
+\use_geometry false
+\use_package amsmath 1
+\use_package amssymb 1
+\use_package cancel 1
+\use_package esint 1
+\use_package mathdots 1
+\use_package mathtools 1
+\use_package mhchem 1
+\use_package stackrel 1
+\use_package stmaryrd 1
+\use_package undertilde 1
+\cite_engine basic
+\cite_engine_type default
+\biblio_style plain
+\use_bibtopic false
+\use_indices false
+\paperorientation portrait
+\suppress_date false
+\justification true
+\use_refstyle 1
+\use_minted 0
+\use_lineno 0
+\index Index
+\shortcut idx
+\color #008000
+\end_index
+\secnumdepth 3
+\tocdepth 3
+\paragraph_separation indent
+\paragraph_indentation default
+\is_math_indent 0
+\math_numbering_side default
+\quotes_style english
+\dynamic_quotes 0
+\papercolumns 1
+\papersides 1
+\paperpagestyle default
+\tablestyle default
+\tracking_changes false
+\output_changes false
+\change_bars false
+\postpone_fragile_content true
+\html_math_output 0
+\html_css_as_file 0
+\html_be_strict false
+\docbook_table_output 0
+\docbook_mathml_prefix 1
+\end_header
+
+\begin_body
+
+\begin_layout Title
+Ensure that maths are properly converted in theorems
+\end_layout
+
+\begin_layout Standard
+Equation outside environments:
+ 
+\begin_inset Formula $\pi\,r^{2}$
+\end_inset
+
+.
+\begin_inset Formula

Re: State of the killqt4 branch

[Thibaut Cuvelier]

On Mon, 21 Nov 2022 at 09:34, Kornel Benko  wrote:

> Am Sun, 20 Nov 2022 21:12:56 +0100
> schrieb Jean-Marc Lasgouttes :
>
> > Dear all,
> >
> > I think I have done everything I can do on the branch (actually I just
> > noticed a few remnants in config/, I will handle that).
> >
> > What remains to be done? Who can help?
> >
> > Kornel: there are still trace of Qt4 in
> > CmakeList.txt
>
> Done
>
> > INSTALL.cmake
>
> Done too, the remaining depends on MAC. Stephan?
>
> > development/cmake/modules/FindQt4.cmake
>
> Removed
>
> > development/cmake/ConfigureChecks.cmake
>
> Done
>
> > and some others. Use 'git grep -il QT4' to find the relevant files.
>
> development/cmake/modules/LyXPaths.cmake
> This is the Windows-part. Maybe Thibaut could have a look?
>

In 23aab19b and 40edcfe2, I've removed the parts of that file that dealt
with Qt 4. It still builds for me (without CMake's cache).

I think the file can still be simplified. I don't think that locale_dir is
used anywhere (it still builds without these lines, but I'm not sure what
it is supposed to change, hence I'm not pushing this for now).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Warning in master in C++11 mode

[Thibaut Cuvelier]

On Sat, 26 Nov 2022 at 20:33, Scott Kostyshak 
wrote:

> On Wed, Nov 09, 2022 at 10:41:17AM +0100, Jean-Marc Lasgouttes wrote:
> > Hi,
> >
> > I get this warning when compiling in C++11 mode :
> >
> > ../../master/src/insets/InsetIndex.cpp: In member function ‘virtual void
> > lyx::InsetIndex::docbook(lyx::XMLStream&, const lyx::OutputParams&)
> const’:
> > ../../master/src/insets/InsetIndex.cpp:376:6: warning: init-statement in
> > selection statements only available with ‘-std=c++17’ or ‘-std=gnu++17’
> >   376 |  if (const vector potential_terms =
> > getSubentriesAsText(runparams); !potential_terms.empty()) {
> >   |  ^
> >
> >
> > Thibaut, can I leave that to you ?
>
> Ping to Thibaut.
>

Hi Scott,

Sorry for the delay, I just found your email. It seems that Pavel changed
the code at d9847302 to fix the issue.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: OOP question: deduplicating code across two subclasses

[Thibaut Cuvelier]

On Sat, 10 Dec 2022 at 23:12, Scott Kostyshak  wrote:

> On Sat, Dec 10, 2022 at 10:36:51PM +0100, Thibaut Cuvelier wrote:
> > On Sat, 10 Dec 2022 at 17:19, Scott Kostyshak  wrote:
> >
> > > PreambleModule::editExternal() and LocalLayout::editExternal() share
> > > most of their code. The functions are pretty small, so there's not too
> > > much duplication as a whole. However, I'm still curious. How would I
> > > best deduplicate the code?
> > >
> > > In this case I wonder if a friend function might be the best course of
> > > action, but I'm not confident so I wanted to check in for advice before
> > > pursuing that.
> > >
> > > Does a friend function indeed seem reasonable for this? Does this
> > > violate a guideline of one of the various lineages of OOP philosophy?
> > > Perhaps some guidelines say that every function that accesses
> > > private/public members should be a member function of a superclass?
> > > i.e., in this case I should add a member function to a shared
> superclass
> > > of PreambleModule and LocalLayout?
> > >
> > > I've searched for general guidelines, and indeed found a lot of results
> > > (such as [1] and [2]), but I am unsure how they apply to this specific
> > > case.
> > >
> >
> > My two cents, here, taking a purist point of view (i.e. not pragmatic at
> > all). These two functions are quite long and they mix a lot of things:
> why
> > are you dealing with files in purely UI code? How much would it be doable
> > to split them into multiple, smaller functions (in an anonymous namespace
> > in the .cpp file)? It would also make the code much easier to read,
> because
> > I have no clue about what these functions are doing (maybe it would make
> > sense to encapsulate some of the common code in a class?).
> > Having a friend function wouldn't solve the readability issues, only
> > duplication, but I'm not sure that duplication is the worst here.
> >
> > That's not an OOP answer, but is really OOP the answer to each and every
> > problem? In a sense, my answer is a lot about the SRP
> > <https://en.wikipedia.org/wiki/Single-responsibility_principle>, though.
>
> Thanks, Thibaut. That is indeed interesting and helpful. I am happy to
> take a look at factoring out the code in the functions to make the code
> easier to read.
>
> But unless I'm mistaken, don't the smaller functions still need access
> to the data members? Or you mean to pass the data members as arguments?
> Perhaps your point is that once I make meaningful smaller functions, it
> will make more sense to add them as useful member functions rather than
> friend functions?
>

Yes, that's what I had in mind: free functions, outside of classes, with
parameters (rather than member functions). I believe you can achieve
better-looking code without having too many parameters.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: OOP question: deduplicating code across two subclasses

[Thibaut Cuvelier]

On Sat, 10 Dec 2022 at 17:19, Scott Kostyshak  wrote:

> PreambleModule::editExternal() and LocalLayout::editExternal() share
> most of their code. The functions are pretty small, so there's not too
> much duplication as a whole. However, I'm still curious. How would I
> best deduplicate the code?
>
> In this case I wonder if a friend function might be the best course of
> action, but I'm not confident so I wanted to check in for advice before
> pursuing that.
>
> Does a friend function indeed seem reasonable for this? Does this
> violate a guideline of one of the various lineages of OOP philosophy?
> Perhaps some guidelines say that every function that accesses
> private/public members should be a member function of a superclass?
> i.e., in this case I should add a member function to a shared superclass
> of PreambleModule and LocalLayout?
>
> I've searched for general guidelines, and indeed found a lot of results
> (such as [1] and [2]), but I am unsure how they apply to this specific
> case.
>

My two cents, here, taking a purist point of view (i.e. not pragmatic at
all). These two functions are quite long and they mix a lot of things: why
are you dealing with files in purely UI code? How much would it be doable
to split them into multiple, smaller functions (in an anonymous namespace
in the .cpp file)? It would also make the code much easier to read, because
I have no clue about what these functions are doing (maybe it would make
sense to encapsulate some of the common code in a class?).
Having a friend function wouldn't solve the readability issues, only
duplication, but I'm not sure that duplication is the worst here.

That's not an OOP answer, but is really OOP the answer to each and every
problem? In a sense, my answer is a lot about the SRP
, though.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: docbook ctest failing on master

[Thibaut Cuvelier]

On Fri, 9 Dec 2022 at 19:48, Thibaut Cuvelier  wrote:

> On Fri, 9 Dec 2022 at 04:23, Scott Kostyshak  wrote:
>
>> The following ctest is failing for me after the recent commits:
>>
>>   export/export/docbook/LilyPond_Book_docbook5
>>
>> The first error in the output has to do with '&' apparently:
>>
>>   Processing `./60/lily-95ee389a.ly'
>>   Parsing...
>>   ././60/lily-95ee389a.ly:7:12: error: undefined character or shorthand:
>> &
>>   \relative c
>>   {  g a b c}
>>
>
> I bet it's due to d4095dc0. I'm having a look.
>

It's strange that you're getting an error there. The file validates with
libxml locally. I do not see any XML problems.

Still, the apostrophes shouldn't be converted in a LilyPond inset. I've
fixed that in 0e2513a0e8. It should fix the failing test.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: docbook ctest failing on master

[Thibaut Cuvelier]

On Fri, 9 Dec 2022 at 04:23, Scott Kostyshak  wrote:

> The following ctest is failing for me after the recent commits:
>
>   export/export/docbook/LilyPond_Book_docbook5
>
> The first error in the output has to do with '&' apparently:
>
>   Processing `./60/lily-95ee389a.ly'
>   Parsing...
>   ././60/lily-95ee389a.ly:7:12: error: undefined character or shorthand: &
>   \relative c
>   {  g a b c}
>

I bet it's due to d4095dc0. I'm having a look.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: lyx2lyx: many unused variables (any bugs?)

[Thibaut Cuvelier]

On Thu, 8 Dec 2022 at 22:06, José Matos  wrote:

> On the same vein for 2.5 I intend to start, in an iterative process, to
> add type hinting to our python code: http://mypy-lang.org/
>
> One example:
>
> def fib(n):
>   if n==0 or n==1:
> return 1
>   else:
> return fin(n-1)+fib(n-2)
>
> becomes
>
> def fib(n: int) -> int:
>   if n==0 or n==1:
> return 1
>   else:
> return fin(n-1)+fib(n-2)
>
> The code works the same in both cases but we can use static type
> checking to ensure that functions are called as intended.
>
> This checking is not done at running time. Instead it can be run in a
> test stage, like pylint that Scott suggests.
>

The only problem I see with type hints is that it restricts the versions of
Python that can run the code. I believe that anything below 3.5
 won't be able to even parse the Python
code (which excludes 2.7). I understood that Python 2.7 should no longer be
supported with LyX 2.5, I don't remember anything about 3.x.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: lyx2lyx: many unused variables (any bugs?)

[Thibaut Cuvelier]

On Thu, 8 Dec 2022 at 21:19, Richard Kimberly Heck 
wrote:

> On 12/8/22 13:45, Scott Kostyshak wrote:
> > Perhaps it doesn't make sense to clean up lyx_2_4.py (except for looking
> > for bugs), but what would you think about adding an agreed-upon set of
> > pylint warnings to our test suite for lyx_2_5.py?
>
> I don't think it could hurt.
>

+1, and even to run these kinds of checks during tests.


> > lyx_2_4.py:836:16: W0612: Unused variable 'k' (unused-variable)
>
> This is a weird one. Jürgen should have a look. Probably it's harmless.
> Basically, it's the loop variable, and it's not actually being used in
> the loop, just to control the number of iterations. So it might just be
> a style thing more than a substance thing.
>

The Python standard for variables that are introduced just because the
syntax requires it (like iterating X times) is to name that variable _ (or
to prefix it with an underscore if there are more than one). For
instance, pylint
recognises this .
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX HTML export on command line runs pdflatex (via lyxpreview2bitmap.py)

[Thibaut Cuvelier]

On Wed, 23 Nov 2022 at 04:08, Richard Kimberly Heck 
wrote:

> On 11/20/22 10:22, Scott Kostyshak wrote:
> > When testing a (seemingly) different issue that Thibaut reported about
> > de Math.lyx, when I do:
> >
> >lyx -e xhtml Math.lyx
> >
> > I notice that pdflatex is run, I think via lyxpreview2bitmap.py.
> >
> > Is this supposed to happen?
>
> It will depend upon what kinds of processes are needed for maths, etc.
> In that document, some of them probably have to be exported as images,
> because the LaTeX is complicated. So yes, that's expected.
>

To be more precise, LyX tries to convert as many formulae as possible into
MathML. If it cannot (mostly due to ERT -- or their math equivalent, when
you can see the \command in red), it reverts to an image
(lyxpreviewXXX.png). I believe that only ERTs trigger this behaviour.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Any preference on using braces to restrict scope?

[Thibaut Cuvelier]

On Mon, 21 Nov 2022 at 10:14, Jean-Marc Lasgouttes 
wrote:

> Le 18/11/2022 à 18:43, Thibaut Cuvelier a écrit :
> > You can avoid this level of indentation by defining the variable within
> > the if:
> >
> > if (const vector potential_terms =
> > getSubentriesAsText(runparams); !potential_terms.empty()) {
> >
> > I don't really like this syntax, because it makes extremely long lines,
> > but it has strong advantages.
>
> I think this is C++17-only syntax.
>

According to https://stackoverflow.com/a/12655339/1066843, it's C++98. At
least, people were discussing it in 2012.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Merge branch 'features/indexmacros'

[Thibaut Cuvelier]

On Sun, 20 Nov 2022 at 16:47, Scott Kostyshak  wrote:

> On Sun, Nov 20, 2022 at 04:33:36PM +0100, Thibaut Cuvelier wrote:
> > > When I open the exported de Math.xhtml in Chromium, I get:
> > >
> > >   "error on line 7159 at column 22: Entity 'imaginary' not defined"
> > >
> >
> > That's unrelated to this branch, it was a problem in the MathML
> > configuration.
>
> Ah, I was wondering why xmllint didn't catch it but I guess it doesn't
> catch MathML issues. Probably there is a way to catch them in the
> ctests, but I don't know if we want to make our ctests more strict. If
> we make them more strict, I will bug you more about test failures :)
>

xmllint is probably not the best tool for (X)HTML, it just validates XML
syntax (HTML is not necessarily XML, but what LyX generates is; there are
many constraints that xmllint doesn't know about).

There are many tools to validate HTML as command-line utilities, but most
of them are in JavaScript; maybe http://www.html-tidy.org/ could be
included as a test dependency? It should be more or less easy to integrate,
as it's just C buildable with CMake and no dependency.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Amend 48d9d01a: remove debug output

[Thibaut Cuvelier]

On Sun, 20 Nov 2022 at 16:26, Scott Kostyshak  wrote:

> On Sun, Nov 20, 2022 at 03:25:09PM +0100, Thibaut Cuvelier wrote:
> > commit f3862130cf687854dbff2df348f34659ca602a02
> > Author: Thibaut Cuvelier 
> > Date:   Sun Nov 20 16:19:17 2022 +0100
> >
> > Amend 48d9d01a: remove debug output
> > ---
> >  src/insets/InsetIndex.cpp |6 --
> >  1 files changed, 0 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/insets/InsetIndex.cpp b/src/insets/InsetIndex.cpp
> > index bd38cf5..f40ba03 100644
> > --- a/src/insets/InsetIndex.cpp
> > +++ b/src/insets/InsetIndex.cpp
> > @@ -1723,12 +1723,6 @@ IndexNode* buildIndexTree(vector&
> entries)
> >   // as children.
> >   auto* index_root = new IndexNode{{}, {}};
> >   for (const IndexEntry& entry : entries) {
> > - std::cout << "Entry: " << std::endl;
> > - std::cout << entry.terms().empty() << std::endl;
> > - std::cout << entry.terms().size() << std::endl;
> > - for (const docstring& d : entry.terms()) {
> > - std::cout << "\"" << to_utf8(d) << "\"" <<
> std::endl;
> > - }
> >   insertIntoNode(entry, index_root);
> >   }
> >
>
> Ah thanks for catching that. I have been wanting to track down where the
> output was coming from.
>
> Just to check, you could keep the output and just guard it with
> LYX_INSET_INDEX_DEBUG if you preferred. I don't understand any of this
> stuff, so do whatever you prefer.
>

I'm more or less confident that this output will not be required in the
future for debugging the new code for indices. Anyway, it is still
available with printTree(), in a more readable presentation;
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Merge branch 'features/indexmacros'

[Thibaut Cuvelier]

On Sun, 20 Nov 2022 at 16:18, Scott Kostyshak  wrote:

> On Sun, Nov 20, 2022 at 03:29:37PM +0100, Thibaut Cuvelier wrote:
> > On Fri, 4 Nov 2022 at 01:59, Scott Kostyshak  wrote:
> >
> > > On Thu, Nov 03, 2022 at 10:04:31PM +0100, Thibaut Cuvelier wrote:
> > > > On Thu, 3 Nov 2022 at 21:27, Scott Kostyshak 
> wrote:
> > > >
> > > > > On Mon, Oct 31, 2022 at 11:38:46PM -0400, Scott Kostyshak wrote:
> > > > > > On Tue, Nov 01, 2022 at 12:01:47AM +0100, Thibaut Cuvelier wrote:
> > > > > > > On Mon, 31 Oct 2022 at 21:12, Jürgen Spitzmüller <
> > > jspi...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Am Montag, dem 31.10.2022 um 14:58 -0400 schrieb Scott
> Kostyshak:
> > > > > > > > > I get the following warning:
> > > > > > > > >
> > > > > > > > > /home/scott/lyxbuilds/master-
> > > > > > > > > master/repo/src/insets/InsetIndex.cpp:1691:6: error:
> function
> > > > > > > > > 'printTree' is not needed and will not be emitted
> [-Werror,-
> > > > > > > > > Wunneeded-internal-declaration]
> > > > > > > > > void printTree(const IndexNode* root_node, unsigned depth
> = 0)
> > > > > > > > >  ^
> > > > > > > > > 1 error generated.
> > > > > > > >
> > > > > > > > I can have a look, but I think this is a method added by
> Thibaut.
> > > > > > >
> > > > > > >
> > > > > > > I've pushed 3bf1b97ae547aea5d0243e41b2d8af463a6e40c5 to
> master; it
> > > > > should
> > > > > > > solve the issue. Scott, let me know if it works for you.
> > > > > >
> > > > > > Thanks! I see the following failures:
> > > > > >
> > > > > >   export/doc/Math_xhtml (Failed)
> > > > > >   export/doc/de/Additional_xhtml (Failed)
> > > > > >   export/doc/de/Math_xhtml (Failed)
> > > > > >   export/doc/de/UserGuide_xhtml (Failed)
> > > > > >   export/doc/es/Math_xhtml (Failed)
> > > > > >   export/doc/fr/Math_xhtml (Failed)
> > > > > >   export/doc/ja/Math_xhtml (Failed)
> > > > > >   export/doc/ru/Math_xhtml (Failed)
> > > > > >
> > > > > > Thibaut, can you look at those?
> > > > >
> > > > > Thibaut, can you take a look? From what I understand, these were
> > > passing
> > > > > before the merge. The doc/Math_xhtml one seems to have been fixed
> > > > > recently somehow, but the other ones still fail:
> > > > >
> > > > >   export/doc/de/Additional_xhtml (Failed)
> > > > >   export/doc/de/Math_xhtml (Failed)
> > > > >   export/doc/de/UserGuide_xhtml (Failed)
> > > > >   export/doc/es/Math_xhtml (Failed)
> > > > >   export/doc/fr/Math_xhtml (Failed)
> > > > >   export/doc/ja/Math_xhtml (Failed)
> > > > >   export/doc/ru/Math_xhtml (Failed)
> > > > >
> > > > > For example, for the de Additional_xhtml, I see in the log:
> > > > >
> > > > > -- Errors from xmllint: doc/de/Additional.xhtml:4451: parser error
> :
> > > > > EntityRef: expecting ';'
> > > > > A Paper  1
> > > > >
> > > > > Is it because '&' needs to be escaped?
> > > > >
> > > >
> > > > In this example, the & in A should be escaped ( or  ).
> If you
> > > > can fix that quickly, that'd be nice, otherwise, I'll have a look,
> > > > tentatively this week-end.
> > >
> > > Thanks for the quick reply, Thibaut. I would prefer if you took care of
> > > it since you are more familiar with this code.
> > >
> >
> > The case of de/Additional.lyx should be solved at 77f0fbdc9a. Other
> issues
> > in the tests are solved in 48d9d01a; the four remaining tests are solved
> at
> > 7a602438 locally
>
> Thanks! It all looks good here. I uninverted two tests at 42425428 since
> it seems that #10355 somehow got fixed.
>
> > (I don't get how to configure CTest to use my version of
> > Python, hence it fails in strange ways).
>
> Let's try to figure out how to fix this.
>
> Is it only a problem with the ctes

Re: [LyX/master] Merge branch 'features/indexmacros'

[Thibaut Cuvelier]

On Fri, 4 Nov 2022 at 01:59, Scott Kostyshak  wrote:

> On Thu, Nov 03, 2022 at 10:04:31PM +0100, Thibaut Cuvelier wrote:
> > On Thu, 3 Nov 2022 at 21:27, Scott Kostyshak  wrote:
> >
> > > On Mon, Oct 31, 2022 at 11:38:46PM -0400, Scott Kostyshak wrote:
> > > > On Tue, Nov 01, 2022 at 12:01:47AM +0100, Thibaut Cuvelier wrote:
> > > > > On Mon, 31 Oct 2022 at 21:12, Jürgen Spitzmüller <
> jspi...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Am Montag, dem 31.10.2022 um 14:58 -0400 schrieb Scott Kostyshak:
> > > > > > > I get the following warning:
> > > > > > >
> > > > > > > /home/scott/lyxbuilds/master-
> > > > > > > master/repo/src/insets/InsetIndex.cpp:1691:6: error: function
> > > > > > > 'printTree' is not needed and will not be emitted [-Werror,-
> > > > > > > Wunneeded-internal-declaration]
> > > > > > > void printTree(const IndexNode* root_node, unsigned depth = 0)
> > > > > > >  ^
> > > > > > > 1 error generated.
> > > > > >
> > > > > > I can have a look, but I think this is a method added by Thibaut.
> > > > >
> > > > >
> > > > > I've pushed 3bf1b97ae547aea5d0243e41b2d8af463a6e40c5 to master; it
> > > should
> > > > > solve the issue. Scott, let me know if it works for you.
> > > >
> > > > Thanks! I see the following failures:
> > > >
> > > >   export/doc/Math_xhtml (Failed)
> > > >   export/doc/de/Additional_xhtml (Failed)
> > > >   export/doc/de/Math_xhtml (Failed)
> > > >   export/doc/de/UserGuide_xhtml (Failed)
> > > >   export/doc/es/Math_xhtml (Failed)
> > > >   export/doc/fr/Math_xhtml (Failed)
> > > >   export/doc/ja/Math_xhtml (Failed)
> > > >   export/doc/ru/Math_xhtml (Failed)
> > > >
> > > > Thibaut, can you look at those?
> > >
> > > Thibaut, can you take a look? From what I understand, these were
> passing
> > > before the merge. The doc/Math_xhtml one seems to have been fixed
> > > recently somehow, but the other ones still fail:
> > >
> > >   export/doc/de/Additional_xhtml (Failed)
> > >   export/doc/de/Math_xhtml (Failed)
> > >   export/doc/de/UserGuide_xhtml (Failed)
> > >   export/doc/es/Math_xhtml (Failed)
> > >   export/doc/fr/Math_xhtml (Failed)
> > >   export/doc/ja/Math_xhtml (Failed)
> > >   export/doc/ru/Math_xhtml (Failed)
> > >
> > > For example, for the de Additional_xhtml, I see in the log:
> > >
> > > -- Errors from xmllint: doc/de/Additional.xhtml:4451: parser error :
> > > EntityRef: expecting ';'
> > > A Paper  1
> > >
> > > Is it because '&' needs to be escaped?
> > >
> >
> > In this example, the & in A should be escaped ( or  ). If you
> > can fix that quickly, that'd be nice, otherwise, I'll have a look,
> > tentatively this week-end.
>
> Thanks for the quick reply, Thibaut. I would prefer if you took care of
> it since you are more familiar with this code.
>

The case of de/Additional.lyx should be solved at 77f0fbdc9a. Other issues
in the tests are solved in 48d9d01a; the four remaining tests are solved at
7a602438 locally (I don't get how to configure CTest to use my version of
Python, hence it fails in strange ways).

When having a look when tests were failing, I had this error with
doc/de/Math.lyx dumped in stderr (which does not prevent output from being
generated, though):

Line ~0: Math parse error: found '\]' unexpectedly

Tokens:
\text[123,1]68105101115[32,10]105115116[32,10]100101114[32,10]750910910111011697114[125,2]\]
pos: 26
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Any preference on using braces to restrict scope?

[Thibaut Cuvelier]

On Fri, 18 Nov 2022 at 18:41, Scott Kostyshak  wrote:

> What do you think of the attached patch? It adds braces to restrict the
> scope of the variable 'potential_terms'. I like this style, since it
> makes it easier for me to read, but I wonder if others would find it
> annoying. For example, it adds an extra layer of indentation.
>

You can avoid this level of indentation by defining the variable within the
if:

if (const vector potential_terms =
getSubentriesAsText(runparams); !potential_terms.empty()) {

I don't really like this syntax, because it makes extremely long lines, but
it has strong advantages.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Qt4???] Re: [PATCH] Show branches from master document in branch inset dialog

[Thibaut Cuvelier]

On Mon, 14 Nov 2022 at 19:38, Scott Kostyshak  wrote:

> On Tue, Oct 18, 2022 at 10:51:34AM -0400, Scott Kostyshak wrote:
> > On Tue, Oct 18, 2022 at 03:12:40PM +0200, Pavel Sanda wrote:
> > > On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
> > > > Still, I am wondering why we insist on supporting Qt4 for 2.4.0
> (especially
> > > > considering that we will have to continue this game for 2+ years
> after
> > > > that).
> > >
> > > That was decided when we planned to release 2.4 at the end of 2019.
> > > It's clear we won't be able to push 2.4 even for next debian stable
> > > and I think we can relax Qt4 support and move on.
> >
> > We had a conversation in July of this year. The following archive does
> > not seem to show some messages in the thread:
> >
> >   https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg217704.html
> >
> > Thibaut had some opinions, so it would be nice to hear from him first
> > before we decide to go forward with requiring Qt5.
> >
> > I paste Thibaut's message from 14 July 2022 here:
> >
> >   As 2.4 is roughly around the corner, maybe it's best to keep Qt 4
> >   compatibility, minus bogus behaviours of Qt 4 that are fixed with Qt
> 5: in
> >   this sense, compatibility would just be "ensure that LyX builds" (it
> should
> >   work roughly well enough) and ignoring bug reports only for Qt 4. Once
> >   release, we can announce that Qt 5.9 or even 5.15, for instance, will
> be
> >   the lowest tested version for LyX 2.5.
> >
> >   I don't think it's good practice to change this kind of compatibility
> >   without prior warning for packagers. Otherwise, I'm 100% ok with
> dropping
> >   support for really old versions that have not been supported for a long
> >   while. I wouldn't be ok with saying that Qt 5.0 is the minimum, given
> the
> >   large amount of changes in Qt since 2012 (10 years ago).
> >
> > By the way, I agree that 5.0 would not be the minimum. I forget, but we
> > need something like 5.4. I think we might have this documented
> > somewhere. If not, I can figure this out.
>
> Thibaut?
>

Well, if barely anyone tests with Qt 4 (I'm only using Qt 5.15), it's
already unsupported in practice and making the necessary changes would be
(1) cumbersome and (2) a waste of resources (little gain in supporting
versions of software that only belongs to a museum -- it's not as old as 486
, though).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.4.0 plan for #12215 [LyX crashes with async processes (Qt6 only)] ?

[Thibaut Cuvelier]

On Mon, 14 Nov 2022, 11:45 Pavel Sanda,  wrote:

> On Fri, Nov 11, 2022 at 03:16:05PM -0500, Scott Kostyshak wrote:
> > If no one fixes it in time, shall we postpone 2.4.0
>
> No, I wouldn't do that.
>
> > or proceed with 2.4.0 and state that Qt6 is not officially supported
> because of #12215?
>
> I see three options:
> 1) we don't support QT6 and break during ./configure if detected
> 2) we allow Qt6 with --enable-stdlib-debug
> 3) we allow Qt6 but forcing single thread only.
>
> I don't have clear winner between these three.
>

I think that not supporting Qt 6 is the worst option, especially as it may
create problems with package managers if they want to switch to Qt 6 for
any reason. Requiring a parameter to be set at configure time to allow Qt 6
acknowledging the potential problems would be acceptable, in my opinion.

>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.4.0 plan for #12215 [LyX crashes with async processes (Qt6 only)] ?

[Thibaut Cuvelier]

On Fri, 11 Nov 2022 at 21:16, Scott Kostyshak  wrote:

> The following issue seems pretty bad:
>
>   https://www.lyx.org/trac/ticket/12215
>
> Is there someone who is brave enough with time to attempt a fix?
>
> If no one fixes it in time, shall we postpone 2.4.0 or proceed with
> 2.4.0 and state that Qt6 is not officially supported because of #12215?
> I suppose an alternative would be to disable asynch on autosave and
> export/view when compiling with Qt6?
>

Is it possible that this issue is a bug in Qt itself? For instance, it
looks a bit like https://bugreports.qt.io/browse/QTBUG-6799.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Delete merged branches from features repository?

[Thibaut Cuvelier]

On Thu, 10 Nov 2022 at 20:38, Scott Kostyshak  wrote:

> Should we delete branches from the features repo that have been merged
> to master? I don't know our policy on this, but it's hard to figure out
> which branches on the features repo are still relevant (i.e., not yet
> merged). In the worst case scenario, e.g., where we need to revert the
> merged branch on master, it is easy to push it again to features.
>

+1: it's really a mess, even though it only has like 25 branches.


> Similar question for features/biblatex. I haven't looked through the
> other branches yet.
>
> I don't know git well, but from what I understand we need to do
> something like the following:
>
> # remove the "-n" if this does indeed look correct
> git push -n features --delete features/indexmacros
>

It seems it's possible to "hide" a branch while still keeping it around:
https://stackoverflow.com/questions/25169440/remove-hide-git-branches-without-deleting-commit-histories
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: A fast mostly collision free hash ?

[Thibaut Cuvelier]

On Tue, 8 Nov 2022 at 20:45, Pavel Sanda  wrote:

> On Tue, Nov 08, 2022 at 04:43:15PM +0100, Jean-Marc Lasgouttes wrote:
> > * I could do fancy things, but I'd rather avoid to import a whole library
> > for this.
>

Probably, the less fancy option is to use std::hash, available since C++11.
I have no idea about the quality of the produced hashes, and it seems it
might really depend on the compiler too.

I can totally understand the need for very unique hashes in this case
(unlike hash tables). If you want something with unicity guarantees, the
only meaningful choice is cryptographic hashes: other functions do not have
the right properties (easy to compute, but no real guarantee with small
hashes). Something like BLAKE2/3 should be good, performance-wise, and it's
available in Qt since Qt 6 (
https://doc.qt.io/qt-6/qcryptographichash.html#Algorithm-enum); otherwise,
Keccak since 5.9; or SHA-3 before.

Otherwise, you might consider using several hashes (concatenating them): I
think it should provide enough entropy to have a very low probability of
collision, but the hash algorithms must be really different for this to be
worthwhile. (Just starting with std::hash and the string length, then see
if more is required?)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Merge branch 'features/indexmacros'

[Thibaut Cuvelier]

On Thu, 3 Nov 2022 at 21:27, Scott Kostyshak  wrote:

> On Mon, Oct 31, 2022 at 11:38:46PM -0400, Scott Kostyshak wrote:
> > On Tue, Nov 01, 2022 at 12:01:47AM +0100, Thibaut Cuvelier wrote:
> > > On Mon, 31 Oct 2022 at 21:12, Jürgen Spitzmüller 
> wrote:
> > >
> > > > Am Montag, dem 31.10.2022 um 14:58 -0400 schrieb Scott Kostyshak:
> > > > > I get the following warning:
> > > > >
> > > > > /home/scott/lyxbuilds/master-
> > > > > master/repo/src/insets/InsetIndex.cpp:1691:6: error: function
> > > > > 'printTree' is not needed and will not be emitted [-Werror,-
> > > > > Wunneeded-internal-declaration]
> > > > > void printTree(const IndexNode* root_node, unsigned depth = 0)
> > > > >  ^
> > > > > 1 error generated.
> > > >
> > > > I can have a look, but I think this is a method added by Thibaut.
> > >
> > >
> > > I've pushed 3bf1b97ae547aea5d0243e41b2d8af463a6e40c5 to master; it
> should
> > > solve the issue. Scott, let me know if it works for you.
> >
> > Thanks! I see the following failures:
> >
> >   export/doc/Math_xhtml (Failed)
> >   export/doc/de/Additional_xhtml (Failed)
> >   export/doc/de/Math_xhtml (Failed)
> >   export/doc/de/UserGuide_xhtml (Failed)
> >   export/doc/es/Math_xhtml (Failed)
> >   export/doc/fr/Math_xhtml (Failed)
> >   export/doc/ja/Math_xhtml (Failed)
> >   export/doc/ru/Math_xhtml (Failed)
> >
> > Thibaut, can you look at those?
>
> Thibaut, can you take a look? From what I understand, these were passing
> before the merge. The doc/Math_xhtml one seems to have been fixed
> recently somehow, but the other ones still fail:
>
>   export/doc/de/Additional_xhtml (Failed)
>   export/doc/de/Math_xhtml (Failed)
>   export/doc/de/UserGuide_xhtml (Failed)
>   export/doc/es/Math_xhtml (Failed)
>   export/doc/fr/Math_xhtml (Failed)
>   export/doc/ja/Math_xhtml (Failed)
>   export/doc/ru/Math_xhtml (Failed)
>
> For example, for the de Additional_xhtml, I see in the log:
>
> -- Errors from xmllint: doc/de/Additional.xhtml:4451: parser error :
> EntityRef: expecting ';'
> A Paper  1
>
> Is it because '&' needs to be escaped?
>

In this example, the & in A should be escaped ( or  ). If you
can fix that quickly, that'd be nice, otherwise, I'll have a look,
tentatively this week-end.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Policy for commits to master

[Thibaut Cuvelier]

On Mon, 31 Oct 2022 at 18:49, Scott Kostyshak  wrote:

> Dear all,
>
> My schedule will clear up a bit in mid-January and I will try to help
> push the 2.4.0 release out. I will not spend much time before January,
> but I hope to at least dedicate some time to coming up with a plan.
>
> One immediate issue is whether we can commit features. I think there is
> support for "opening" master up and allowing features to be committed. I
> think this makes sense because so much time has gone by, and also I will
> not have much time until January anyway so the final stages of the
> release are not near. However, I think it's important we're a bit more
> conservative than usual. I think everyone agrees that master is not a
> sandbox, but I think we should be even more careful. I propose the
> following general guidelines:
>
> - Please only commit to master features that you have tested very well,
>   and that do not have any *known* issues. Occasionally we make commits
>   to master that we know will need smoothing out or various follow-up
>   commits. I suggest we avoid doing that, and only commit to master when
>   we are (reasonably) confident in something.
>

Is this about making commits or pushing them? It usually makes sense to
split changes into commits, for instance for ease of review. (I totally
agree that master should remain more stable when nearing a release.)


> - Of course, features almost necessarily imply bugs, and that is
>   understandable. I just ask for careful testing before pushing. If you
>   have doubts, please ask and hopefully another developer/user has time
>   to try to break your new feature.
>
> - For non-trivial features, I tend to favor merging a branch to master
>   rather than rebasing on master. I'd be curious on other thoughts
>   though if there is disagreement.
>
> - Please only push to master if you will have time to fix something if a
>   bug is found.
>
> - If a regression is found because of your commit, I propose that if the
>   bug is not fixed quickly, you revert your feature.
>
> We should keep master in a state that at least developers can accept the
> risk to consider daily driving it. Similarly, by keeping master as
> "stable" as possible, we can make a pre-release whenever convenient. In
> fact, getting a pre-release out will be one of my main priorities before
> January. Several developers and users are using the latest pre-release,
> which is already quite old, and it would be nice to know which issues
> are still relevant.
>
> I need to think some more before I propose a timeline (that will be open
> to feedback), such as a specific date for feature freeze.
>

More generally, what about bug fixes that imply larger-scale changes, like
updating the format? Should they be treated like features and undergo
serious local testing before pushing them?
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Merge branch 'features/indexmacros'

[Thibaut Cuvelier]

On Mon, 31 Oct 2022 at 21:12, Jürgen Spitzmüller  wrote:

> Am Montag, dem 31.10.2022 um 14:58 -0400 schrieb Scott Kostyshak:
> > I get the following warning:
> >
> > /home/scott/lyxbuilds/master-
> > master/repo/src/insets/InsetIndex.cpp:1691:6: error: function
> > 'printTree' is not needed and will not be emitted [-Werror,-
> > Wunneeded-internal-declaration]
> > void printTree(const IndexNode* root_node, unsigned depth = 0)
> >  ^
> > 1 error generated.
>
> I can have a look, but I think this is a method added by Thibaut.


I've pushed 3bf1b97ae547aea5d0243e41b2d8af463a6e40c5 to master; it should
solve the issue. Scott, let me know if it works for you.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Merge branch 'features/indexmacros'

[Thibaut Cuvelier]

On Mon, 31 Oct 2022 at 19:58, Scott Kostyshak  wrote:

> On Mon, Oct 31, 2022 at 06:40:15PM +0100, Juergen Spitzmueller wrote:
> > commit 4e50da3e655b9f8d26f7d5e439d72b219d32279d
> > Merge: 0df63e3 f4d588c
> > Author: Juergen Spitzmueller 
> > Date:   Mon Oct 31 19:32:52 2022 +0100
> >
> > Merge branch 'features/indexmacros'
> >
>
> I get the following warning:
>
> /home/scott/lyxbuilds/master-master/repo/src/insets/InsetIndex.cpp:1691:6:
> error: function 'printTree' is not needed and will not be emitted
> [-Werror,-Wunneeded-internal-declaration]
> void printTree(const IndexNode* root_node, unsigned depth = 0)
>  ^
> 1 error generated.
>

If I remember correctly, this function is only used for debugging with its
uses guarded by #if 0. Probably the function declaration should have the
same guard (or a more appropriate variable).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Feature request (Grammarly support for LYX)

[Thibaut Cuvelier]

Hi Wail,

Unfortunately, I don't think it will be possible to have some kind of
integration with Grammarly: it only provides an API for the Web. It would
require some reverse-engineering to use it within a desktop application.
Apparently, you'd only have to understand how this works, exactly:

https://js.grammarly.com/grammarly-editor-sdk@2.0.1

And even so, I believe this use would be against Grammarly's terms of
services. Overall, I think it would be better to ask them to support
desktop applications (i.e. provide a true Web API).

For the same purpose, I have looked into Antidote, providing language
services for French and English, but their desktop API is a mess to use
(COM on Windows, D-BUS for Linux, and services for macOS — or JavaScript
for Web browsers):
https://www.antidote.info/en/antidote-11/documentation/developer-tools.

Thibaut Cuvelier


On Wed, 21 Sept 2022 at 21:02, wael muhammed 
wrote:

> Hello, LYX  is very powerful tools, I hope I can use Grammarly with it.
> for Grammarly SDK, you can see it here <https://developer.grammarly.com/>.
>  I am also web developer, you can give me some keys to make merge request.
> With a lot of thanks
> Wail Alasad
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Thibaut Cuvelier]

On Tue, 20 Sept 2022 at 16:54, Kornel Benko  wrote:

> Am Tue, 20 Sep 2022 16:57:02 +0300
> schrieb Udicoudco :
>
> > On Tue, Sep 20, 2022 at 4:36 PM Kornel Benko  wrote:
> > >
> > > Am Tue, 20 Sep 2022 05:26:49 +0300
> > > schrieb Udicoudco :
> >
> > > You may want to add the module to the list of math-modules.
> > > Add
> > > #\DeclareCategory{Maths}
> > > as the second line (before the #DescriptionBegin)
> >
> > Hi Kornel,
> >
> > Thank you for the suggestion, I'm guessing this is related to the
> > redesigned module selection dialog in LyX 2.4?
>
> Yes, that is the case.
>
> > Also, could you care to explain what is the purpose of the new tags i
> > saw in the master (DocBookWrapperTag, DocBookTag, DocBookAttr)?
>
> They are important for export to docbook (in contrast to exporting to pdf
> via some latex
> engine)
> But the better reference person (than me) is Thibaut Cuvelier (
> tcuvel...@lyx.org).
>
> > It
> > might be a good idea to add those too, but i did not want to add these
> > without knowing their functionality (I've noticed that all theorem
> > layouts has "DocBookTag   para" wouldn't it be copied with the
> > CopyStyle tag?)
>
> You should test docbook export before this can go to trunk IMO. But
> Thibaut can help you
> more.
>

I'm jumping in the conversation as my ears were buzzing :).

@Udi: as long as your new theorems are roughly similar to the previous ones
(without more nesting, for instance), you should be able to use exactly the
same configuration. I haven't been focusing on having the smallest
configuration that works yet. If you need help or want to delegate the
DocBook export, no problem, just let me know :). I think that we can
proceed with merging your patch without any DocBook-related changes first
(unless your module makes the DocBook export crash, I believe that's not
likely t all), then I can have a look later on. But everything DocBook
requires LyX 2.4, that might make it harder for you to test.

Nevertheless, it would be best to have an example document with all your
new constructs to be used in the test suite (a file like
autotests/export/docbook/theorems-thmtools.lyx), even if you don't touch
the DocBook part: it would be very useful in the longer term to ensure that
nothing breaks regarding the DocBook export of your new constructs, and
also simply to write the required configuration. You would be the best
person to build this document, as you know how everything is supposed to be
used, I would have to figure it out almost from scratch.
I have noticed your included test_thmtools_module.lyx, but I don't know how
complete it is :).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Making Paragraph::latex() thread safe?

[Thibaut Cuvelier]

On Mon, 29 Aug 2022 at 21:52, Scott Kostyshak  wrote:

> I used the hacks just to get an idea of whether such parallelization would
> actually lead to a speed-up. It does. For example, on an 8-core machine,
> the document files (user guide, etc.) export to .tex about 4x faster. This
> isn't that helpful from a user perspective, because the main bottle-neck is
> compiling to PDF, not the LaTeX generation. But it's still cool to see that
> it actually does have a real effect.


It may very well be helpful for users, I'm especially thinking about the
DocBook export: I find it quite slow compared to LaTeX code generation
(ballpark estimate: twice to thrice as slow). What's more important for
users is that LyX doesn't do anything further from the DocBook file (except
when generating ePub), which makes it more noticeable. Any improvement
there would be great! But it points to another area where refactoring could
be important before merging your change: having less redundancy between the
generators.

I believe a large part of the performance discrepancy should be solveable
by more careful optimisation of the code (the current focus has been on
correctness). I think that most of it came when I started generating some
parts twice to get the correct output (including generating LaTeX and
parsing roughly parts of it).


> If I protect it with a mutex, then things work much better. But that's
> exactly the code that I need to run in parallel for my knitr child
> documents to export in parallel. Could someone explain intuitively why this
> code is not thread-safe? Is there any hope of making it thread-safe without
> major surgery?
>

Another point of view: wouldn't this major surgery bring real improvements
to the code base? For now, I found that the way the generators are written
is ad-hoc and has evolved over the years, with the state stored in
OutputParams getting larger and larger (and I got lost more than a few
times in its updates).

What you could ship quite quickly, in my opinion, is parallelising the
operations on child documents. I think that part should almost be
thread-safe. It would solve your problem too, while we could get some
feedback from users (concurrency is always a tricky topic...).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: I need help with Qt6X11Extras

[Thibaut Cuvelier]

On Sat, 18 Jun 2022, 11:04 Kornel Benko,  wrote:

> Am Sat, 18 Jun 2022 18:22:34 +0300
> schrieb Andrew Gaidukevich <3du...@mail.ru>:
>
> >
> > Hello! My name is Andrew!
> > I need help!
> > I cant compile LMMS without this!
> > I got this error… help me to solve this
> > -- Could NOT find Qt6X11Extras (missing: Qt6X11Extras_DIR)
> > CMake Error at CMakeLists.txt:171 (FIND_PACKAGE):
> >   Found package configuration
> file:
> >
>
>
> >
> /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake
>
> >
>
>
> >   but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be
> NOT
> >   FOUND.  Reason given by
> package:
> >
>
>
> >   Failed to find Qt component
> "X11Extras".
> >
>
>
> >   Expected Config file
> at
> >
> "/usr/lib/x86_64-linux-gnu/cmake/Qt6X11Extras/Qt6X11ExtrasConfig.cmake"
>
> >   does NOT exist
> >
> >
> > --
> > Andrew Gaidukevich
>
> I don't know the package for Qt6, but for Qt5 the relevant package (on
> debian) is
> 'libqt5x11extras5-dev'.


Does this module still exist with Qt 6? I had heard that these extra
modules were being deprecated:
https://www.qt.io/blog/qt-extras-modules-in-qt-6
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: features/indexmacros

[Thibaut Cuvelier]

On Mon, 25 Apr 2022 at 07:43, Jürgen Spitzmüller  wrote:

> Am Montag, dem 25.04.2022 um 02:43 +0200 schrieb Thibaut Cuvelier:
> > I have pushed a slightly revised patch to your branch with the
> > DocBook implementation. I'm now having a look at the XHTML one, in
> > particular to share some code between the two.
>
> Great!
>

I've pushed my refactoring of the XHTML output. According to my tests, it
is functionally equivalent to the previous code, but with cleaner XHTML
output (new lines, use of dashes for internationalisation).
Also, I believe the code is much easier to understand and modify in the
long term (it also handles more than three levels of index, even if I doubt
it will ever be useful). Algorithmically, it has a very similar time
complexity but has arrays to store the index in a format closer to the
XHTML output. Except for very large indices, this should not have a
significant impact on users.

Next: port the DocBook code to reuse as much as possible of the new XHTML
implementation; add features to the XHTML export (multiple indices and
ranges should be more or less easy to implement).

Feedback welcome on the code :)!
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Back

[Thibaut Cuvelier]

On Tue, 3 May 2022 at 17:19, Richard Kimberly Heck  wrote:

> Hi, all,
>
> Sorry for disappearing there for a while. I had some difficult personal
> circumstances and an incredibly busy semester and just had to withdraw
> from everything else until things settled down. Which they now have.
>

Welcome back :)!


> Where are things with respect to LyX 2.4.0? I'm happy to resume my role
> as release manager for that project, if that's still required.
>

There's one (big) question for 2.4: should we include Jürgen's latest
changes for indices? I'm still working on the XHTML part, with a quite
large refactoring at the same time to make the code (much) easier to
understand.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: features/indexmacros

[Thibaut Cuvelier]

On Fri, 22 Apr 2022 at 13:14, Jürgen Spitzmüller  wrote:

> Am Freitag, dem 22.04.2022 um 09:01 +0200 schrieb Jürgen Spitzmüller:
> > > Also, I'm assuming that the user either uses the new insets or the
> > > old, pure LaTeX way of doing index, not a mix of both. Does this
> > > make
> > > sense?
> >
> > With LaTeX, both methods can be used in parallel, which might be
> > useful
> > especially for transition of existing documents.
>
> I realize that I probably misunderstood. Yes, as per inset, you can
> only use one approach. You can only mix different insets in one
> document.
>

OK, thanks for the confirmation, that was indeed what I was asking for!

I have pushed a slightly revised patch to your branch with the DocBook
implementation. I'm now having a look at the XHTML one, in particular to
share some code between the two.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: features/indexmacros

[Thibaut Cuvelier]

On Tue, 19 Apr 2022 at 13:29, Jürgen Spitzmüller  wrote:

> Am Dienstag, dem 19.04.2022 um 13:21 +0200 schrieb Jürgen Spitzmüller:
> > This adds native macros for subindexes (!level), |see and |seealso
>
> and sort keys (sort@key), for that matter.
>

Code-wise, the design looks really clean! The DocBook code would have been
extremely clean if only this version had to be supported.

I have made a first iteration for the DocBook changes. It's only conceptual
for now, it's not really tested, but I'd still like a second opinion on the
new methods I implement to get parts of an inset: would it make sense to
write, e.g., getSortkey based on getSortkeyAsText, something like *os <<
getSortkeyAsText*?
Also, I'm assuming that the user either uses the new insets or the old,
pure LaTeX way of doing index, not a mix of both. Does this make sense?

(I will have a look at XHTML afterwards, as I don't really know that code
and it must perform a lot of work for rendering…)


0001-DocBook-use-the-new-system-for-index.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: A docbook test is failing on current master

[Thibaut Cuvelier]

On Sat, 2 Apr 2022 at 20:24, Scott Kostyshak  wrote:

> The following test fails for me on current master:
>
>   export/export/xhtml/table_borders_docbook5
>

Thanks for the notice! It's been fixed as e7ed8213ac.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyXHTML doc doesn't pass validation

[Thibaut Cuvelier]

On Wed, 23 Mar 2022 at 22:54, José Abílio Matos  wrote:

> On Wednesday, 23 March 2022 20.12.23 WET Thibaut Cuvelier wrote:
>
> > XHTML 1 dates back from 2001... LyX generates XHTML 5, but the doctype
> is kept
>
> > from XHTML 1 for compatibility issues (some browsers completely change
> their
>
> > behaviour based on the doctype). The issue has been discussed on the
> mailing
>
> > list a while ago.
>
> At some point this decision can be revisited.
>
> It is question of deciding what are the browsers that we are interested to
> support. Because of the security associated issues the browsers are kept
> more up to date now than before so probably at some point this becomes a
> non issue.
>

I believe the browsers were quite recent, then:
http://lists.lyx.org/pipermail/lyx-devel/2020-September/003434.html
Now that the code matured quite a bit, maybe it could help to switch to XML
entities instead of HTML entities (i.e. to have  instead of
).
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Lots of duplicate code in docbook

[Thibaut Cuvelier]

On Wed, 30 Mar 2022 at 07:29, Daniel  wrote:

> On 2022-03-28 18:49, Thibaut Cuvelier wrote:
> > On Mon, 21 Mar 2022 at 13:11, Lorenzo Bertini
> > mailto:lorenzobertin...@gmail.com>> wrote:
> >
> > Il 21/03/22 11:49, Daniel ha scritto:
> >  > On 2022-03-21 10:55, Lorenzo Bertini wrote:
> >  >> There is some degree of duplication between Docbook and LyXHTML
> > code.
> >  >> I think its because the latter is much older and Thibaut had to
> > write
> >  >> its own to produce Docbook. This has been brought up also when
> >  >> addressing MathML production. I agree LyX needs more standard XML
> >  >> generating functions.
> >  >>
> >  >> Its part of a larger theme about XML production, and there was a
> > talk
> >  >> sometime ago about using a library for this.
> >  >
> >  > I might be misunderstanding your comment. But actually, I wanted
> to
> >  > point not to the way XML is generated but more to the actual
> > content,
> >  > for example, the specific attributes of an element which seem to
> be
> >  > duplicated. But maybe that problem is somehow dependent on the
> > general
> >  > generation of XML?
> >
> > Sorry, I meant that code duplication is probably due to the different
> > maintainers for the two formats and the fact that one is much older
> and
> > has been untouched for a long (LyXHTML). I remember Thibaut saying he
> > branched from LyXHTML knowingly, even if it would have meant
> rewriting
> > some stuff. Looking at your examples, this might be the case.
> >
> > I think a common interface to write XML elements like tables, tags,
> > etc,
> > would help reduce this, but it will be a lot of effort. I'll wait for
> > Thibaut and Richard to chime in on this.
> >
> >
> > There is already a generic interface for XML tags (but not
> > tree-oriented, like almost all XML tools). However, it does not make
> > sense to have a generic function for a table: CALS and HTML are two
> > quite different formats; moreover, HTML tables in DocBook do not always
> > exactly match what HTML allows (mostly, HTML allows CSS, but DocBook
> > forbids formatting).
>
> Okay. As I said, I have no knowledge about DocBook. I was working on
> adding support for line styles to LyXHTML and noticed that it felt
> strange to work with the code when very similar code appeared in the
> DocBook section.
>
> DocBook does not support CSS Styles?  Well, at least what I added does
> not need to be duplicated for DocBook then. But what is
>
> style
>
>  This attribute specifies style information for the current element.
>
> (https://tdg.docbook.org/tdg/5.0/html.td.html)?
>

You're right, td has a style attribute (it's quite exceptional in DocBook).

I've merged a lot of code between HTML and DocBook for lines in the last
three commits (c7896cf9, ec016162, 0ba1b68f). The codes for DocBook and
XHTML are harder to merge, I believe it's more open to discussion, hence
I'm attaching a patch to this email to gather feedback. I could go further,
but the main codes (::docbook and ::xhtml) differ more in their preamble,
I'd rather do that in a second step, after having some feedback for the
first one.


0002-XHTML-DocBook-merge-code-paths-to-generate-a-row-in-.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Lots of duplicate code in docbook

[Thibaut Cuvelier]

On Mon, 21 Mar 2022 at 13:11, Lorenzo Bertini 
wrote:

> Il 21/03/22 11:49, Daniel ha scritto:
> > On 2022-03-21 10:55, Lorenzo Bertini wrote:
> >> There is some degree of duplication between Docbook and LyXHTML code.
> >> I think its because the latter is much older and Thibaut had to write
> >> its own to produce Docbook. This has been brought up also when
> >> addressing MathML production. I agree LyX needs more standard XML
> >> generating functions.
> >>
> >> Its part of a larger theme about XML production, and there was a talk
> >> sometime ago about using a library for this.
> >
> > I might be misunderstanding your comment. But actually, I wanted to
> > point not to the way XML is generated but more to the actual content,
> > for example, the specific attributes of an element which seem to be
> > duplicated. But maybe that problem is somehow dependent on the general
> > generation of XML?
>
> Sorry, I meant that code duplication is probably due to the different
> maintainers for the two formats and the fact that one is much older and
> has been untouched for a long (LyXHTML). I remember Thibaut saying he
> branched from LyXHTML knowingly, even if it would have meant rewriting
> some stuff. Looking at your examples, this might be the case.
>
> I think a common interface to write XML elements like tables, tags, etc,
> would help reduce this, but it will be a lot of effort. I'll wait for
> Thibaut and Richard to chime in on this.
>

There is already a generic interface for XML tags (but not tree-oriented,
like almost all XML tools). However, it does not make sense to have a
generic function for a table: CALS and HTML are two quite different
formats; moreover, HTML tables in DocBook do not always exactly match what
HTML allows (mostly, HTML allows CSS, but DocBook forbids formatting).

I had planned to merge the code paths somehow, but never really got to it
for now: I was focusing on correctness rather than aesthetics (while
keeping good-quality code). Patches are welcome, of course, if you want to
make that happen sooner :)!
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyXHTML doc doesn't pass validation

[Thibaut Cuvelier]

On Wed, 23 Mar 2022 at 20:02, Lorenzo Bertini 
wrote:

> Il 23/03/22 19:03, Thibaut Cuvelier ha scritto:
> > On Wed, 23 Mar 2022 at 18:43, Lorenzo Bertini
> > mailto:lorenzobertin...@gmail.com>> wrote:
> >
> > Running a very simple LyXHTML doc (a section with a few paragraphs)
> > against this validator https://validator.w3.org/check
> > <https://validator.w3.org/check> reports some
> > errors, I don't really know if we care or not:
> >
> > 1. value of attribute "dir" cannot be "auto"; must be one of "ltr",
> > "rtl"
> > 2. element "section" undefined
> >
> > Is this a problem? I just wanted to check if I could use the 
> > tag but its not part of the specification.
> >
> >
> > What version of HTML are you checking against? There are some glimpses
> > of HTML5 in the current output. For instance, dir="auto" and section are
> > perfectly legal in HTML5
> > (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/dir
> > <https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/dir>
> and
> > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section
> > <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section>)
>
> I checked XHTML 1.0, as it should be what LyX outputs. I was about to
> check up some of the xhtml_output code to maybe add `figure`
> environments, but since its XHTML there's very little allowed.
>

XHTML 1 dates back from 2001... LyX generates XHTML 5, but the doctype is
kept from XHTML 1 for compatibility issues (some browsers completely change
their behaviour based on the doctype). The issue has been discussed on the
mailing list a while ago.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyXHTML doc doesn't pass validation

[Thibaut Cuvelier]

On Wed, 23 Mar 2022 at 18:43, Lorenzo Bertini 
wrote:

> Running a very simple LyXHTML doc (a section with a few paragraphs)
> against this validator https://validator.w3.org/check reports some
> errors, I don't really know if we care or not:
>
> 1. value of attribute "dir" cannot be "auto"; must be one of "ltr", "rtl"
> 2. element "section" undefined
>
> Is this a problem? I just wanted to check if I could use the 
> tag but its not part of the specification.
>

What version of HTML are you checking against? There are some glimpses of
HTML5 in the current output. For instance, dir="auto" and section are
perfectly legal in HTML5 (
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/dir and
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Master uncompilable on cygwin

[Thibaut Cuvelier]

On Sat, 5 Mar 2022 at 03:40, Enrico Forestieri  wrote:

> On Sat, Mar 05, 2022 at 03:00:08AM +0100, Thibaut Cuvelier wrote:
> >
> > What I don't get is why casting one value is easy, but a vector is not...
> > What about adding a manual cast around this line?
> >
> > std::vector mathCommands() const { return math_commands_; }
>
> The attached patch works for me.
>

It also compiles for me and the conversion of Unicode LaTeX files still
works. I was initially afraid of changing the type of the field, because I
had no idea why it was this way.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Master uncompilable on cygwin

[Thibaut Cuvelier]

On Sat, 5 Mar 2022 at 02:54, Enrico Forestieri  wrote:

> On Sat, Mar 05, 2022 at 02:47:16AM +0100, Thibaut Cuvelier wrote:
> >
> > On Sat, 5 Mar 2022 at 02:24, Enrico Forestieri  wrote:
> >
> > > This is the error:
> > >
> > > In file included from ../../../../src/frontends/qt/GuiBibtex.cpp:21:
> > > ../../../../src/Encoding.h: In member function
> > > ‘std::vector > > int>, std::allocator > > lyx::CharInfo::textCommands()
> const’:
> > > ../../../../src/Encoding.h:82:62: error: could not convert ‘((const
> > > lyx::CharInfo*)this)->lyx::CharInfo::text_commands_’ from
> > > ‘vector>’ to
> > > ‘vector,
> > > std::allocator >>’
> > >82 | std::vector textCommands() const { return
> > > text_commands_; }
> > >   |
> > > ^~
> > >   |  |
> > >   |
> > > vector>
> > > ../../../../src/Encoding.h: In member function
> > > ‘std::vector > > int>, std::allocator > > lyx::CharInfo::mathCommands()
> const’:
> > > ../../../../src/Encoding.h:86:62: error: could not convert ‘((const
> > > lyx::CharInfo*)this)->lyx::CharInfo::math_commands_’ from
> > > ‘vector>’ to
> > > ‘vector,
> > > std::allocator >>’
> > >86 | std::vector mathCommands() const { return
> > > math_commands_; }
> > >   |
> > > ^~
> > >   |  |
> > >   |
> > > vector>
> > >
> >
> > I wrote that change, but I had no problems compiling it with more or less
> > recent compilers (including Visual C++, which tends to have
> idiosyncrasies
> > compared to GCC and LLVM). What version of GCC do you use?
>
> Yes, biset points at 3f9e21b8. The GCC version is 11.2.0.
>
> > What's strange is that strfwd.h typeders trivdocstring as docstring
> (unless
> > STD_STRING_USES_COW is defined). I have no idea what this macro exactly
> > does and when it is set, though :/.
>
> I think it refers to copy-on-write. I think mingw uses COW but not cygwin.
>

What I don't get is why casting one value is easy, but a vector is not...
What about adding a manual cast around this line?

std::vector mathCommands() const { return math_commands_; }
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Master uncompilable on cygwin

[Thibaut Cuvelier]

On Sat, 5 Mar 2022 at 02:24, Enrico Forestieri  wrote:

> This is the error:
>
> In file included from ../../../../src/frontends/qt/GuiBibtex.cpp:21:
> ../../../../src/Encoding.h: In member function
> ‘std::vector int>, std::allocator > > lyx::CharInfo::textCommands() const’:
> ../../../../src/Encoding.h:82:62: error: could not convert ‘((const
> lyx::CharInfo*)this)->lyx::CharInfo::text_commands_’ from
> ‘vector>’ to
> ‘vector,
> std::allocator >>’
>82 | std::vector textCommands() const { return
> text_commands_; }
>   |
> ^~
>   |  |
>   |
> vector>
> ../../../../src/Encoding.h: In member function
> ‘std::vector int>, std::allocator > > lyx::CharInfo::mathCommands() const’:
> ../../../../src/Encoding.h:86:62: error: could not convert ‘((const
> lyx::CharInfo*)this)->lyx::CharInfo::math_commands_’ from
> ‘vector>’ to
> ‘vector,
> std::allocator >>’
>86 | std::vector mathCommands() const { return
> math_commands_; }
>   |
> ^~
>   |  |
>   |
> vector>
>

I wrote that change, but I had no problems compiling it with more or less
recent compilers (including Visual C++, which tends to have idiosyncrasies
compared to GCC and LLVM). What version of GCC do you use?

What's strange is that strfwd.h typeders trivdocstring as docstring (unless
STD_STRING_USES_COW is defined). I have no idea what this macro exactly
does and when it is set, though :/.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Clarify debug message

[Thibaut Cuvelier]

On Tue, 1 Mar 2022 at 13:52, Jürgen Spitzmüller  wrote:

> Am Di., 1. März 2022 um 13:51 Uhr schrieb Jürgen Spitzmüller <
> sp...@lyx.org>:
>
>> Am Di., 1. März 2022 um 04:19 Uhr schrieb Thibaut Cuvelier <
>> tcuvel...@lyx.org>:
>>
>>> On Tue, 1 Mar 2022 at 03:58, Thibaut Cuvelier  wrote:
>>>
>>>> On Mon, 28 Feb 2022 at 08:04, Jürgen Spitzmüller  wrote:
>>>>
>>>>> Am Sonntag, dem 27.02.2022 um 20:48 +0100 schrieb Thibaut Cuvelier:
>>>>> > I'm doing this in the attached patches (also for HTML, XML being the
>>>>> > common part between the two). I would like some feedback more
>>>>> > specifically for the typing of the enum: as I could find, it's never
>>>>> > sure that enums are coded with enough bits to add a code (there are
>>>>> > already enough codes to fill 32 bits). I thus forced the types to be
>>>>> > unsigned long long, to have 64 available bits
>>>>> > (https://en.cppreference.com/w/cpp/language/types).
>>>>> >
>>>>> > I also tried to change as many occurrences I could find, but there
>>>>> > were not many (or my searching skills are not on par).
>>>>>
>>>>> Thinking more about it, another option would be to rename LATEX to
>>>>> something more generic (e.g. OUTFILE), maybe keeping "latex" as an
>>>>> alias on the command line. After all, only one of these is used at a
>>>>> given time, and depending on the output chain, it might not even be
>>>>> clear which one. Also, we do not have a PLAINTEXT mode.
>>>>>
>>>>
>>>> What do you think about this new iteration?
>>>>
>>>
>>> I forgot to include the changes to debug.cpp in the previous patch, here
>>> is a new complete patch.
>>>
>>
>> Looks good. I would probably rephrase the help text as "Output source
>> file generation/processing"
>>
>
> ... and add an alias "latex" for backwards compatibility, like we have for
> "any" and "all".
>

I've pushed the updated patch, thanks :)!
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Clarify debug message

[Thibaut Cuvelier]

On Tue, 1 Mar 2022 at 03:58, Thibaut Cuvelier  wrote:

> On Mon, 28 Feb 2022 at 08:04, Jürgen Spitzmüller  wrote:
>
>> Am Sonntag, dem 27.02.2022 um 20:48 +0100 schrieb Thibaut Cuvelier:
>> > I'm doing this in the attached patches (also for HTML, XML being the
>> > common part between the two). I would like some feedback more
>> > specifically for the typing of the enum: as I could find, it's never
>> > sure that enums are coded with enough bits to add a code (there are
>> > already enough codes to fill 32 bits). I thus forced the types to be
>> > unsigned long long, to have 64 available bits
>> > (https://en.cppreference.com/w/cpp/language/types).
>> >
>> > I also tried to change as many occurrences I could find, but there
>> > were not many (or my searching skills are not on par).
>>
>> Thinking more about it, another option would be to rename LATEX to
>> something more generic (e.g. OUTFILE), maybe keeping "latex" as an
>> alias on the command line. After all, only one of these is used at a
>> given time, and depending on the output chain, it might not even be
>> clear which one. Also, we do not have a PLAINTEXT mode.
>>
>
> What do you think about this new iteration?
>

I forgot to include the changes to debug.cpp in the previous patch, here is
a new complete patch.


0001-Rename-LATEX-debug-level-to-OUTFILE-and-use-it-for-D.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel