Re: DocBook change: use a stack of fonts
On Tue, Dec 27, 2022 at 07:36:41PM +0100, Kornel Benko wrote: > Am Tue, 27 Dec 2022 10:23:59 -0500 > schrieb Scott Kostyshak : > > > On Tue, Dec 27, 2022 at 10:12:15AM +0100, Kornel Benko wrote: > > > Am Tue, 27 Dec 2022 00:03:40 -0500 > > > schrieb Scott Kostyshak : > > > > > > > On Tue, Dec 27, 2022 at 02:13:15AM +0100, 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'd like help on two points: > > > > > - code review > > > > > - running the test suite (ctest -R "_docbook") > > > > > > > > Here are the failures: > > > > > > > ... > > > > > > Interesting ... here all these tests pass. > > > > They pass for you with the patch applied or without the patch? I was > > testing with the > > patch. > > > > Scott > > Without the patch. Good to know, same here. WIth the patch, I get the extra failures. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Master broken due to febd1855eb
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.
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Master broken due to febd1855eb
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: Indentation and (un)commenting in local layout and preamble
On 2022-09-14 09:04, Daniel wrote: On 13/09/2022 18:27, Jean-Marc Lasgouttes wrote: Le 13/09/2022 à 16:12, Daniel a écrit : And I guess more importantly in license.rtf it says: "LyX. You can redistribute LyX and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." That means that QtCreator can take code from LyX and use it as GPLv3 ;) JMarc Or LyX can take code from LyX. ;) Well, looks like open source isn't as open as I thought. I see a couple of possible routes to resolve this: 1) I seem to remember that it was stated in the Qt Creator code somewhere that smaller parts of the code can be used without license. So, I could check with the Qt people what they mean by smaller parts. My guess is that re-use of smaller parts would be in their interest since it gives people a source of example code that allows people to work more easily with Qt. This would also be helpful for the future since something like "look at how Qt Creator does it" often comes up. 2) Check whether a previous Qt Creator release under another license has the same or similar code. 3) Re-invent the wheel, i.e. I could start from scratch and try to come up with my own method for the (un)commenting part. Any suggestions? Daniel Went for 3 at https://www.lyx.org/trac/ticket/12577. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Master broken due to febd1855eb
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...
^~~~
Daniel
--
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
Am Tue, 27 Dec 2022 10:23:59 -0500 schrieb Scott Kostyshak : > On Tue, Dec 27, 2022 at 10:12:15AM +0100, Kornel Benko wrote: > > Am Tue, 27 Dec 2022 00:03:40 -0500 > > schrieb Scott Kostyshak : > > > > > On Tue, Dec 27, 2022 at 02:13:15AM +0100, 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'd like help on two points: > > > > - code review > > > > - running the test suite (ctest -R "_docbook") > > > > > > Here are the failures: > > > > > ... > > > > Interesting ... here all these tests pass. > > They pass for you with the patch applied or without the patch? I was testing > with the > patch. > > Scott Without the patch. Kornel pgpFJh2x7n3lV.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Wrong Clines with RTL tabular
On Tue, Dec 27, 2022 at 7:02 PM Udicoudco wrote: > Thank you Jürgen, the output LaTeX code looks great now. > Note that the \L's still appears in the code preview pane. > > It only happens in the code preview pane of the current paragraph or body, not for the complete source. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Patch to insert entries for Noweb, Rnw and Sweave into Chapter 4 Modules of Additional.lyx and to make consequential changes to the Literate Programming section
From f61364bb0cdf78c4072ce921b8af93fca1ac1aa7 Mon Sep 17 00:00:00 2001
From: John R Hudson
Date: Tue, 27 Dec 2022 17:26:44 +
Subject: [PATCH] Insert entries for Noweb, Rnw and Sweave in Chapter 4 Modules
of Additional.lyx and make consequential updates to the Literate Programming
section in the same document
---
lib/doc/Additional.lyx | 408 -
1 file changed, 398 insertions(+), 10 deletions(-)
diff --git a/lib/doc/Additional.lyx b/lib/doc/Additional.lyx
index 07695291f4..1f289d9bc6 100644
--- a/lib/doc/Additional.lyx
+++ b/lib/doc/Additional.lyx
@@ -15063,6 +15063,8 @@ Alph{enumi}
\end_inset
+\change_unchanged
+
\end_layout
\end_inset
@@ -15105,6 +15107,8 @@ arabic{enumii}
\end_inset
+\change_unchanged
+
\end_layout
\end_inset
@@ -15155,6 +15159,8 @@ arabic{enumiii}}
\end_inset
+\change_unchanged
+
\end_layout
\end_inset
@@ -15197,6 +15203,8 @@ roman{enumiv})}
\end_inset
+\change_unchanged
+
\end_layout
\end_inset
@@ -15494,6 +15502,8 @@ arabic{enumi}.
\end_inset
+\change_unchanged
+
\end_layout
\end_inset
@@ -15665,6 +15675,8 @@ start=4
\end_inset
+\change_unchanged
+
\end_layout
\end_inset
@@ -15689,6 +15701,8 @@ status collapsed
\lang american
Lists ! Spacing
+\change_unchanged
+
\end_layout
\end_inset
@@ -15762,6 +15776,8 @@ nolistsep
\end_inset
+\change_unchanged
+
\end_layout
\end_inset
@@ -15807,6 +15823,8 @@ status collapsed
\lang american
\SpecialChar LaTeX
-packages ! enumitem
+\change_unchanged
+
\end_layout
\end_inset
@@ -15867,6 +15885,8 @@ parindent, labelsep=2cm
\end_inset
+\change_unchanged
+
\end_layout
\end_inset
@@ -15899,6 +15919,8 @@ status collapsed
\lang american
Lists ! Customization
+\change_unchanged
+
\end_layout
\end_inset
@@ -16012,6 +16034,8 @@ itshape, style=nextline
\end_inset
+\change_unchanged
+
\end_layout
\end_inset
@@ -16057,6 +16081,8 @@ status collapsed
\lang american
\SpecialChar LaTeX
-packages ! enumitem
+\change_unchanged
+
\end_layout
\end_inset
@@ -16124,6 +16150,289 @@ literal "false"
.
\end_layout
+\begin_layout Section
+
+\change_inserted 564990737 1672161542
+
+\lang american
+Literate Programming
+\end_layout
+
+\begin_layout Subsection
+
+\change_inserted 564990737 1672161542
+
+\lang american
+Noweb
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672161542
+
+\lang american
+This module allows the use of Noweb as a literate programming tool.
+ The files and the documentation for Noweb can be obtained from
+\begin_inset CommandInset href
+LatexCommand href
+name "CTAN"
+target "https://www.ctan.org/pkg/noweb";
+literal "false"
+
+\end_inset
+
+.
+ Literate programming is described in section
+\begin_inset space ~
+\end_inset
+
+
+\begin_inset CommandInset ref
+LatexCommand ref
+reference "sec:Literate-Programming"
+
+\end_inset
+
+ and there are three example files:
+\family sans
+File\SpecialChar menuseparator
+Open Example\SpecialChar menuseparator
+Modules\SpecialChar menuseparator
+Noweb
+\family default
+,
+\family sans
+File\SpecialChar menuseparator
+Open Example\SpecialChar menuseparator
+Modules\SpecialChar menuseparator
+Noweb Listerrors
+\family default
+ and
+\family sans
+File\SpecialChar menuseparator
+Open Example\SpecialChar menuseparator
+Modules\SpecialChar menuseparator
+Noweb2\SpecialChar LyX
+
+\family default
+.
+\end_layout
+
+\begin_layout Subsection
+
+\change_inserted 564990737 1672161542
+
+\lang american
+Rnw (knitr)
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672161542
+
+\lang american
+This module uses the
+\family typewriter
+knitr
+\family default
+ and
+\family sans
+includernw
+\family default
+ packages.
+ The
+\begin_inset Flex Code
+status collapsed
+
+\begin_layout Plain Layout
+
+\change_inserted 564990737 1672161542
+
+\lang american
+knitr
+\end_layout
+
+\end_inset
+
+ package in R for dynamic report generation has to be installed for this
+ module to work:
+\begin_inset Flex Code
+status collapsed
+
+\begin_layout Plain Layout
+
+\change_inserted 564990737 1672161542
+
+\lang american
+install.packages(“knitr”)
+\end_layout
+
+\end_inset
+
+.
+
+\end_layout
+
+\begin_layout Paragraph
+
+\change_inserted 564990737 1672161542
+
+\lang american
+Note
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672161542
+
+\lang american
+it depends on R >= 2.14.1.
+ For more info see
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+\change_inserted 564990737 1672161542
+
+http://yihui.name/knitr
+\end_layout
+
+\end_inset
+
+.
+
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672161542
+
+\lang american
+The package
+\family sans
+includernw
+\family default
+ also has to be installed.
+ It cannot be used if the modules
+\family sans
+LilyPond
+\begin_inset space ~
+\end_inset
+
+Book
+\family default
+ or
+\family sans
+Sweave
+\family
Re: Wrong Clines with RTL tabular
On Tue, Dec 27, 2022 at 7:02 PM Udicoudco wrote: > > I will open tickets for both. > > I now realize that permission is still needed to register to track, Who should I send the request to? Regards, Udi -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Wrong Clines with RTL tabular
On Sat, Dec 24, 2022 at 8:21 AM Jürgen Spitzmüller wrote: > Am Samstag, dem 24.12.2022 um 00:03 + schrieb Udicoudco: > > Fixed. This is now suppressed if babel and Xe/LuaTeX are used together. > > Thank you Jürgen, the output LaTeX code looks great now. Note that the \L's still appears in the code preview pane. > > Don't know much about this territory. > It was my mistake, forgot to set Right-to-left cursor movement to "visual" in my preferences. Or we could make LyX output this. > > Any comments regarding this question: > > Could math equations be made as an exception to forceRTL decoration, > > just as ERT? > > Maybe, yes. This needs careful testing, though. Again, I don't know > much about RTL business. > > I will open tickets for both. Regards, Udi -- 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
On 12/27/22 10:55, Thibaut Cuvelier wrote: 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. That looks great. Yes, I overlooked the case you mention in the notes. Riki -- 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
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: DocBook change: use a stack of fonts
On Tue, Dec 27, 2022 at 10:12:15AM +0100, Kornel Benko wrote: > Am Tue, 27 Dec 2022 00:03:40 -0500 > schrieb Scott Kostyshak : > > > On Tue, Dec 27, 2022 at 02:13:15AM +0100, 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'd like help on two points: > > > - code review > > > - running the test suite (ctest -R "_docbook") > > > > Here are the failures: > > > ... > > Interesting ... here all these tests pass. They pass for you with the patch applied or without the patch? I was testing with the patch. Scott signature.asc Description: PGP signature -- 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
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
Patch to insert entries for Customizable Lists and Paragraph Lists into Chapter 4 Modules of Additional.lyx
From 76ef99e2d795bddd9d7642642817978a2a1781c3 Mon Sep 17 00:00:00 2001
From: John R Hudson
Date: Tue, 27 Dec 2022 10:51:40 +
Subject: [PATCH] Insert entries for Customizable lists and Paragraph lists
into Chapter 4 Modules of Additional.lyx
---
lib/doc/Additional.lyx | 1320
1 file changed, 1320 insertions(+)
diff --git a/lib/doc/Additional.lyx b/lib/doc/Additional.lyx
index 74558a56d7..07695291f4 100644
--- a/lib/doc/Additional.lyx
+++ b/lib/doc/Additional.lyx
@@ -37,6 +37,7 @@ theorems-ams-extended
multicol
shapepar
graphicboxes
+enumitem
\end_modules
\maintain_unincluded_children no
\language english
@@ -14814,6 +14815,1315 @@ Rnw
have been loaded.
\end_layout
+\begin_layout Section
+
+\change_inserted 564990737 1672138150
+
+\lang american
+List enhancements
+\end_layout
+
+\begin_layout Subsection
+
+\change_inserted 564990737 1672138150
+
+\lang american
+Customizable Lists
+\begin_inset CommandInset label
+LatexCommand label
+name "subsec:Customizable-Lists"
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672138150
+
+\lang american
+This module uses the
+\family sans
+ enumitem
+\family default
+ package to enable the customization of various list environments.
+\end_layout
+
+\begin_layout Subsubsection
+
+\change_inserted 564990737 1672138150
+
+\lang american
+Custom Enumerate Lists
+\end_layout
+
+\begin_layout Standard
+\noindent
+
+\change_inserted 564990737 1672138150
+
+\lang american
+The default numbering of numbered lists can be changed by adding an optional
+ argument (menu
+\family sans
+\bar under
+I
+\bar default
+nsert\SpecialChar menuseparator
+
+\bar under
+S
+\bar default
+hort Title
+\family default
+) to the first item of each level in the list.
+ There you add the command
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672138150
+
+\family sans
+\lang american
+label=
+\backslash
+roman{enumi}
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672138150
+
+\lang american
+in \SpecialChar TeX
+ Code (shortcut
+\begin_inset Info
+type "shortcut"
+arg "ert-insert"
+\end_inset
+
+).
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672138150
+
+\family sans
+\lang american
+enumi
+\family default
+ is the first level counter of the enumeration.
+ To change the numbering for the list sublevels, replace the “
+\family sans
+i
+\family default
+” in the command by the small Roman numeral of the level (
+\family sans
+enumi
+\family default
+,
+\family sans
+enumii
+\family default
+,
+\family sans
+enumiii
+\family default
+,
+\family sans
+enumiv
+\family default
+).
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672138150
+
+\lang american
+The command
+\family sans
+
+\backslash
+roman
+\family default
+ outputs the counter as a small Roman numeral.
+ For capital Roman numerals replace
+\family sans
+
+\backslash
+roman
+\family default
+ with
+\family sans
+
+\backslash
+Roman
+\family default
+ in the command above.
+ For Arabic numerals use
+\family sans
+
+\backslash
+arabic
+\family default
+.
+ To
+\begin_inset Quotes eld
+\end_inset
+
+number
+\begin_inset Quotes erd
+\end_inset
+
+ items with capital or small Latin letters use
+\family sans
+
+\backslash
+Alph
+\family default
+ or
+\family sans
+
+\backslash
+alph
+\family default
+, respectively.
+\end_layout
+
+\begin_layout Standard
+\noindent
+
+\change_inserted 564990737 1672138150
+
+\lang american
+\begin_inset Note Greyedout
+status collapsed
+
+\begin_layout Plain Layout
+
+\change_inserted 564990737 1672138150
+
+\series bold
+\lang american
+Note:
+\series default
+ You can only number 26
+\begin_inset space ~
+\end_inset
+
+items with Latin letters, because this numbering is limited to single letters.
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 564990737 1672138150
+
+\lang american
+Here is a list with custom numbering:
+\end_layout
+
+\begin_layout Enumerate
+
+\change_inserted 564990737 1672138150
+
+\lang american
+\begin_inset Argument 1
+status collapsed
+
+\begin_layout Plain Layout
+
+\change_inserted 564990737 1672138150
+
+\lang american
+\begin_inset ERT
+status collapsed
+
+\begin_layout Plain Layout
+
+\change_inserted 564990737 1672138150
+
+label=
+\backslash
+#
+\backslash
+Alph{enumi}
+\backslash
+#
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\end_inset
+
+Level 1
+\begin_inset Separator latexpar
+\end_inset
+
+
+\end_layout
+
+\begin_deeper
+\begin_layout Enumerate
+
+\change_inserted 564990737 1672138150
+
+\lang american
+\begin_inset Argument 1
+status collapsed
+
+\begin_layout Plain Layout
+
+\change_inserted 564990737 1672138150
+
+\lang american
+\begin_inset ERT
+status collapsed
+
+\begin_layout Plain Layout
+
+\change_inserted 564990737 1672138150
+
+label=
+\backslash
+Alph{enumi}.
+\backslash
+arabic{enumii}
+\end_layout
+
+\end_inset
+
Re: [LyX/master] Revert doc update for Additional.lyx so maitenance work can continue.
Am Montag, dem 26.12.2022 um 16:40 -0500 schrieb Scott Kostyshak: > By the way, does Additional.lyx compile for you? I get language > errors now. I think a language switch is done inside an argument or > something like that. There are currently many "\lang american" and "\lang british" switches in the document. Simply replacing them all with "\lang english" in an editor will solve the issue and keep the important change tracking marks. I don't think there are really occurrences in the document where the variety of English matters. -- Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Allow an 'other' type for hyperlinks. Format change.
Am Montag, dem 26.12.2022 um 11:45 -0500 schrieb Richard Kimberly Heck: > What I was thinking here was that "Other" would more or less act like > 'literal', in the sense that it would just output whatever's there. Yes. Would it make more sense to rename this to "Custom"? After all, it's completely fine to enter mailto, web or any other valid or invalid URI there. Also relative URIs, btw, which has been not possible before, AFAICS. > The special handling of "http" with the Web one confused me; I missed > that it would also handle "ftp://". And https://, ftps://, ldap://, git:// and any scheme, as long as an "authority" part is indicated by double slash (it only checks for "://" in the string). > But now I wonder whether we should change "Web" to "HTTP" or > something like that, and let everything 'literal' be > handled by "Other". Then we could say something like: > > Web: Adds "http://"; if not given (but also allows other > 'authorities') or "other schemes, if an authority is specified". > EMail: Adds "mailto:"; if not given. > File: Adds "file://" if not given. > Other: Outputs as is. > > Then I'd write a lyx2lyx script that would convert non-http targets > to other. > > Alternatively, I'm starting to wonder how useful these 'types' really > are. Does it really save people a lot of effort not to have to write > "mailto" or "http"? Or is that just more confusing? I think it was thought to help people who are not familiar with the URI syntax at all (who don't know that email addresses need to be prefixed by mailto: and file addresses by file:). And probably do not even know what http means (except that it is somehow involved in internet addresses). In my opinion a more sensible UI would feature a combo box with a range of common schemes (http, https, ftp, ftps, mailto, file, tel, doi, git, ldap, ...), represented in the combo by more accessible descriptions, (e.g., "Web Hypertext (http)", "Web Hypertext, Secured (https)", ...), and "Custom". We could also not only check if the current scheme is already prefixed, but also if _a different_ one is (think of the http://tel: case you just addressed). We have QURL at disposal which could help us here with parsing the components and a basic validation, and we could add LineEdit validators for all URIs except Custom. But maybe that's post-2.4 stuff and we just release 2.4 with what we have now, which is already an improvement. Jürgen > > Riki > > -- Jürgen -- 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
Am Tue, 27 Dec 2022 00:03:40 -0500 schrieb Scott Kostyshak : > On Tue, Dec 27, 2022 at 02:13:15AM +0100, 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'd like help on two points: > > - code review > > - running the test suite (ctest -R "_docbook") > > Here are the failures: > ... Interesting ... here all these tests pass. > > Scott Kornel pgp9E4V7HOIwJ.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
