change in behavior of cursor movement in math array

[Udicoudco]

Hello all,

Open a new file, enter a math align environment via
Insert->Math->AMS align environment
add two additional rows to a total of 3
put the cursor to the left of the equation
now press on the left arrow key several times

In LyX2.4.0 the cursor travers only the middle row,
while in LyX2.3.x the cursor travers all cells, from top
to bottom.

Is this change intentional?
I've tried bisecting but did not find
a "good" commit that I could compile
easily, I think it happened at least
4 years ago.

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

LaTeX definitions of greyedout and lyxdeleted

[Udicoudco]

Hello all,

lyxdeleted is a macro used to
mark deleted parts of text when
using "show changes in output"
in track changes. Instead of directly
using \sout there is another helper
macro, \mklyxsout, which is defined as
\DeclareRobustCommand{\mklyxsout}[1]{\ifx\\#1\else\sout{#1}\fi}
If I'm understanding correctly, this macro should test if the argument
#1 is empty, if so it does nothing, otherwise it is feeding the argument
to \sout.

Why is this needed? from testing it appears \sout is just fine
with empty arguments. In addition, I don't think this test is
really robust, I attached an example where the output is wrong.
Since the first object in the deleted part is \\ the comparison
result with the true branch, so \sout is not applied and the \\
is not used.

Now for greyedout. When I tried to add a space at the beginning
of a greyedout inset, LyX complained that I cannot add space
at the beginning of a paragraph, although it is not the start of
a paragraph. Then I tried to forcefully add that space in an ERT
but couldn't as I discovered later that greyedout use \ignorespaces
in its definition. Is this really needed? That feels really restrictive and
non intuitive to me.


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

Re: [LyX/master] Fix change tracking colors with RTL languages (#12923)

[Udicoudco]

On Wed, Jun 12, 2024 at 6:40 PM Pavel Sanda  wrote:
>
> On Wed, Jun 12, 2024 at 01:11:23PM +0300, Udicoudco wrote:
> > Does this matter? i.e. do we hold strongly
> > backwards compatibility of the output of change track?
>
> Generally we do in between minor version. Here I am ambivalent. I think users
> should feel confident between switching 2.4.x minor versions while their 
> output
> remain the same. At the same time this fixes bug and it's early in the 2.4 
> cycle.
>
> That's why I am asking how bad things can get with this change.
>
> Pavel
>
> PS: submitting revised manuscript with change tracking on was part of
> revision process in the last journal I interacted with. Obviously
> depending whether your last export was in different minor version of
> lyx might backfire, esp. if changes are more than cosmetic.

Hmm, from your comments I'm not really sure I understand
what people are looking for with this feature.
As I see it, when show changes in output
is selected, the output is not even remotely close to the final
manuscript. In general, line breaks, vertical spaces between
paragraphs and equations, page breaks and more will be different.
Is there anyway to rely on what you see in the result while change
track with "show changes in output" are on?

I thought this feature was more for earlier drafts.
Can you describe a change that will
backfire?

This commit could potentially, in some cases,
change some vertical spaces, nothing more
really.

I can always define separate commands
for RTL scripts, I just did not think it was
needed in this case.

Udi
> --
> 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: [LyX/master] Fix change tracking colors with RTL languages (#12923)

[Udicoudco]

On Wed, Jun 12, 2024 at 10:32 AM Pavel Sanda  wrote:
>
> On Mon, Jun 10, 2024 at 12:19:18PM +, Udi Fogiel wrote:
> > commit a5749b9c1f5c5b42e6d6db7cd9f2aab16bc28f5b
> > Author: Udi Fogiel 
> > Date:   Mon Jun 10 15:19:08 2024 +0300
> >
> > Fix change tracking colors with RTL languages (#12923)
> > ---
> >  src/LaTeXFeatures.cpp | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/LaTeXFeatures.cpp b/src/LaTeXFeatures.cpp
> > index 4a4385fc01..e68f850d0a 100644
> > --- a/src/LaTeXFeatures.cpp
> > +++ b/src/LaTeXFeatures.cpp
> > @@ -208,8 +208,8 @@ static docstring const lyxdot_def = from_ascii(
> >
> >  static docstring const changetracking_xcolor_ulem_base_def = from_ascii(
> >   "%% Change tracking with ulem and xcolor: base macros\n"
> > - 
> > "\\DeclareRobustCommand{\\mklyxadded}[1]{\\bgroup\\color{lyxadded}{}#1\\egroup}\n"
> > - 
> > "\\DeclareRobustCommand{\\mklyxdeleted}[1]{\\bgroup\\color{lyxdeleted}\\mklyxsout{#1}\\egroup}\n"
> > + 
> > "\\DeclareRobustCommand{\\mklyxadded}[1]{\\textcolor{lyxadded}\\bgroup#1\\egroup}\n"
> > + 
> > "\\DeclareRobustCommand{\\mklyxdeleted}[1]{\\textcolor{lyxdeleted}\\bgroup\\mklyxsout{#1}\\egroup}\n"
> >   
> > "\\DeclareRobustCommand{\\mklyxsout}[1]{\\ifx#1\\else\\sout{#1}\\fi}\n");
> >
> >  static docstring const changetracking_xcolor_ulem_def = from_ascii(
>
> I am sorry if I missed some discussion on ML (please redirect me then),
> but is this patch just RTL related or it can break something in CT
> in "normal" documents?

There was no discussion,  but I explained the reasoning a bit in the bug.
The change is basically reordering of the operations. Start a paragraph
before injecting any color specials into the list, it fixes the problems with
RTL stuff, and it is the recommended way (usually) to go, so I thought
to change it for  all cases.

See https://tex.stackexchange.com/a/589156/264024,
https://tex.stackexchange.com/a/47053/264024,
and enrico's comment here https://tex.stackexchange.com/a/207228/264024
for example.

I just used \textcolor as it basically does \leavevmode\color{...
and this is how greyedout is defined. But giving to it a bit more
thought we should probably use \leavevmode\color instead of
\textcolor in both cases (the fact that it works now with greyedout
is a fluke I think).

Can this change the spacing of existing documents? yes, only if
"show changes in output" is selected, and in most cases the output
should be better.  Does this matter? i.e. do we hold strongly
backwards compatibility of the output of change track?

Udi

> --
> 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: [LyX/master] Remove hebrew letter document class

[Udicoudco]

On Wed, Jun 12, 2024 at 6:42 AM Udicoudco  wrote:
>
> On Wed, Jun 12, 2024 at 3:07 AM Richard Kimberly Heck
>  wrote:
> > In this case,
> > removing this file will prevent a document that uses it from loading
> > properly, let alone compiling. So we keep it and mark it obsolete.
>
> A document that directly uses this layout from the settings
> will be loaded with the letter layout, and the LaTeX export,
> and as a consequence the pdf output will stay identical.
> This is why I did the format change in this commit.

Briefly looking in lyx_2_4.py there are several format changes
which are dependent on the value of document.textclass,
so they have the same flaw as in my commit, i.e. they don't catch
the case of a custom user layout file that input the layout file
related to said format change.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Remove hebrew letter document class

[Udicoudco]

On Wed, Jun 12, 2024 at 3:07 AM Richard Kimberly Heck
 wrote:
> In this case,
> removing this file will prevent a document that uses it from loading
> properly, let alone compiling. So we keep it and mark it obsolete.

A document that directly uses this layout from the settings
will be loaded with the letter layout, and the LaTeX export,
and as a consequence the pdf output will stay identical.
This is why I did the format change in this commit.

If that's still a problem I'll revert though.

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

Re: [LyX/master] Remove hebrew letter document class

[Udicoudco]

On Tue, Jun 11, 2024 at 9:37 PM Udicoudco  wrote:
>
> How can it break old documents?
> Other than custom user layouts,
> which requires this one, I can't think
> of a problem.

And in such a rare case they can simply input
the regular letter layout instead (which gives
the correct alignment in the GUI anyway).
> > --
> > 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: [LyX/master] Remove hebrew letter document class

[Udicoudco]

On Tue, Jun 11, 2024 at 9:33 PM  wrote:
>
> Am Dienstag, dem 11.06.2024 um 18:15 + schrieb Udi Fogiel:
> > commit 3854086e59db47a38f61ae94b08c5bc9e207767a
> > Author: Udi Fogiel 
> > Date:   Tue Jun 11 21:14:27 2024 +0300
> >
> > Remove hebrew letter document class
> >
> > The only difference from regular letter is the alignment of
> > "Send To Address" layout, but it no longer reflect the output
> > corrctly, probably because LyX revert the alignment of layouts
> > in RTL context now.
>
> I don't think we want to remove layouts. This breaks old documents.
> Rather than that, mark it as obsolete, please.

How can it break old documents?
Other than custom user layouts,
which requires this one, I can't think
of a problem.

Udi
> --
> 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: Preview use dvipng when the document use pdflatex

[Udicoudco]

On Sun, Jun 9, 2024 at 1:35 PM Udicoudco  wrote:

>
>
> On Sun, Jun 9, 2024 at 11:09 AM Udicoudco  wrote:
>
>> Is there any particular reason why preview use dvi mode when the document
>> is configured
>> to use pdfmode with pdftex? For example, the attached compiles fine but
>> the preview fails
>>
>
Opened a ticket
https://www.lyx.org/trac/ticket/13073

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

Re: current font parameters are not updated in math equations

[Udicoudco]

On Sun, Jun 9, 2024 at 2:42 PM Enrico Forestieri  wrote:
>
> Should be fixed at afb70c90.
>

Just tested and it looks great, thanks! any chance it will be
backported as it made some shortcuts to not work properly?

> >To me, it looks like the text in equations does not update any
> >parameters
> >of the current font.
> >
> >The changes in the LaTeX source can be explained by 58103cf, but this
> >commit is not the fault, it just worsen the symptoms.
>
> Yes, this was also broken in 2.3. The code simply expected all text
> properties to be specified instead of just some of them. In 2.3 only the
> color was taken into account and thus the breakage was limited to that
> case only. However, using the text properties dialog everything should
> have worked right.

That is what I suspect, thanks for confirming.

> Note that the code is expecting numerical parameters, so that
> "textstyle-update series bold" does not work. One should use
> "textstyle-update series 1", instead.

ah yes, thanks for the correction.

Udi

> --
> 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: [LyX/master] missing background in xetex and fix RTL stuff in preview

[Udicoudco]

On Sun, Jun 9, 2024 at 1:55 PM Udi-Fogiel  wrote:
>
> commit 64aad586f49b9047082356e5f217fc6147ac9500
> Author: Udi-Fogiel 
> Date:   Sun Jun 9 13:36:35 2024 +0300
>
> missing background in xetex and fix RTL stuff in preview
>
> * previwes with xetex did not produce any background (\pagecolor does not 
> work for some reason), adding the direct command for that, 
> \special{background } inside the preview box solved it.
>
> * similar to #12923 we should push the color node in horizontal mode
>
> * there is a bug in preview with LuaTeX with main RTL language, this 
> commit fix this bug, but it should be removed when it is fixed upstream (the 
> code related to \pr@set@pagerightoffset)

Riki, is this ok for stable?
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Preview use dvipng when the document use pdflatex

[Udicoudco]

On Sun, Jun 9, 2024 at 11:09 AM Udicoudco  wrote:

> Is there any particular reason why preview use dvi mode when the document
> is configured
> to use pdfmode with pdftex? For example, the attached compiles fine but
> the preview fails
>

Actually it looks like this situation was already thought of in
https://git.lyx.org/gitweb/?p=lyx.git;a=commit;h=75f7eafd6561c4926e7c15e89b7d65b7b479dd4d
but it does not work for some reason.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Preview use dvipng when the document use pdflatex

[Udicoudco]

Is there any particular reason why preview use dvi mode when the document
is configured
to use pdfmode with pdftex? For example, the attached compiles fine but the
preview fails

Udi


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

current font parameters are not updated in math equations

[Udicoudco]

Hello all,

I've got a report on a strange behaviour of textstyle-update in LyX 2.4.0.
If I select a character (say a) in math equation, then execute
textstyle-update color 3
in LyX 2.3 is simply turned the character into blue, and in th LaTeX
source I see
{\color{blue}a} as expected, but with LyX 2.4.0 the character is also
turning upright instead
of staying italic, and the LaTeX source shows

{\color{blue}{\normalsize \mathrm{\mathrm{\mathrm{a}

which is probably undesired.


To me, it looks like the text in equations does not update any parameters
of the current font.

The changes in the LaTeX source can be explained by 58103cf, but this
commit is not the fault, it just worsen the symptoms.


You can see that in LyX 2.3 with colors, as this is a parameter math knew
about then.

If I create a blue character then select it and execute textstyle-update
series bold,

the character is turned black and the LaTeX source has an undesired
\normalcolor.


Should the font parameters be tracked in equations? I would expect the
default shape

would be italic in an equation.


Another problem with 58103cf is that \mathrm does not only change the font
family, but

the shape as well, so I'm not sure it should be used as it is being used
now...


Somewhat but not entirely related to that, if I execute textstyle-update
shape up, LyX crash and I get a segmentation fault in 2.3.7, and "Exception:
basic_string::_M_construct null not valid" on LyX 2.4 and master.


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

Re: Uncompatiable syntax of \set_color

[Udicoudco]

On Fri, Jun 7, 2024 at 8:50 PM Richard Kimberly Heck  wrote:
>
> On 6/7/24 11:33, Udicoudco wrote:
> > Hello all,
> >
> > The old syntax of \set_color in 2.3 was
> > \set_color "lyxcolorname" "color in normal mode"
> > but now it is
> > \set_color "lyxcolorname" "color in normal mode" "color in darkmode"
> > and so all the color schemes in https://wiki.lyx.org/Tips/ColorSchemes
> > or other places do not work. Is there a way to make the last argument
> > optional to keep all these color schemes work?
>
> I think this was meant to be handled in the prefs2prefs script. Check
> the file prefs2prefs_prefs.py, especially the add_dark_color routine.
>
Oh, I see, thanks! I'll probably mention that in the wiki page.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Uncompatiable syntax of \set_color

[Udicoudco]

On Fri, Jun 7, 2024 at 6:33 PM Udicoudco  wrote:
>
> Hello all,
>
> The old syntax of \set_color in 2.3 was
> \set_color "lyxcolorname" "color in normal mode"
> but now it is
> \set_color "lyxcolorname" "color in normal mode" "color in darkmode"
> and so all the color schemes in https://wiki.lyx.org/Tips/ColorSchemes
> or other places do not work. Is there a way to make the last argument
> optional to keep all these color schemes work?
>
> Another question, what is the meaning the of the foreground color that is
> documented in Appendix B.3 of the Customization manual, but does not appear in
> the GUI?

Does lexrc.next() check beyond end of line?
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Uncompatiable syntax of \set_color

[Udicoudco]

Hello all,

The old syntax of \set_color in 2.3 was
\set_color "lyxcolorname" "color in normal mode"
but now it is
\set_color "lyxcolorname" "color in normal mode" "color in darkmode"
and so all the color schemes in https://wiki.lyx.org/Tips/ColorSchemes
or other places do not work. Is there a way to make the last argument
optional to keep all these color schemes work?

Another question, what is the meaning the of the foreground color that is
documented in Appendix B.3 of the Customization manual, but does not appear in
the GUI?
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: quotes around argument of PackageOptions

[Udicoudco]

On Thu, Jun 6, 2024 at 8:01 AM Jürgen Spitzmüller  wrote:
>
> Am Donnerstag, dem 06.06.2024 um 00:19 +0300 schrieb Udicoudco:
> > I attached a file that compiles with 2.3.x but not with 2.4.0.
> > If I remove the quotes around the second argument of PackageOptions
> > then LyX 2.3.7 complains that the layout is invalid, and with 2.4.0
> > the file compiles.
>
> That's due to a77c84a0b4d5.
>
> Fixed in master (1449fbf9ae3ec), candidate for 2.4.1.
>

Great, thanks!

Udi
> --
> 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

quotes around argument of PackageOptions

[Udicoudco]

Hello all,

I attached a file that compiles with 2.3.x but not with 2.4.0.
If I remove the quotes around the second argument of PackageOptions
then LyX 2.3.7 complains that the layout is invalid, and with 2.4.0
the file compiles.


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

Re: Windows (?) Table Crash

[Udicoudco]

On Sun, Jun 2, 2024 at 7:53 PM Richard Kimberly Heck  wrote:
>
> On 6/2/24 12:35, Udicoudco wrote:
> > On Sun, Jun 2, 2024 at 7:32 PM Richard Kimberly Heck  
> > wrote:
> >> We've had a report of the following sort of crash, or maybe assertion.
> >>
> >> Create a table. Mark more than half the rows or columns. Delete those
> >> (using the toolbar button, but I doubt that matters). Boom.
> >>
> >> I cannot reproduce on Linux, but Eugene was able to reproduce on
> >> Windows. Anyone else?
> > I can reproduce on Windows as well.
>
> Can you get a backtrace?

Here is the output when running with -dbg any from the point of
clicking the delete rows button:

Undo.cpp (23b): +++ Creating new group c for buffer 02A164FFF720
frontends\qt\GuiApplication.cpp (6d8): cmd:  action: 362
[tabular-feature]  arg: 'delete-row' x: 0 y: 0
BufferView.cpp (556): BufferView::dispatch: cmd:  action: 362
[tabular-feature]  arg: 'delete-row' x: 0 y: 0
Buffer.cpp (b55): Buffer::dispatch: cmd:  action: 362
[tabular-feature]  arg: 'delete-row' x: 0 y: 0
Cursor.cpp (30d): Cursor::dispatch: cmd:  action: 362
[tabular-feature]  arg: 'delete-row' x: 0 y: 0

 cursor:| anchor:
 inset: 02A163DE44B0 idx: 0 par: 0 pos: 0 | inset:
02A163DE44B0 idx: 0 par: 0 pos: 0
 inset: 02A1640B77B0 idx: 12 par: 0 pos: 0 | inset:
02A1640B77B0 idx: 5 par: 0 pos: 0
 selection: 1 boundary: 0

Cursor.cpp (32c): Cursor::dispatch: cmd:  action: 362
[tabular-feature]  arg: 'delete-row' x: 0 y: 0

 cursor:| anchor:
 inset: 02A163DE44B0 idx: 0 par: 0 pos: 0 | inset:
02A163DE44B0 idx: 0 par: 0 pos: 0
 inset: 02A1640B77B0 idx: 12 par: 0 pos: 0 | inset:
02A1640B77B0 idx: 5 par: 0 pos: 0
 selection: 1 boundary: 0

insets\InsetTabular.cpp (13bd): # InsetTabular::doDispatch: cmd:
action: 362 [tabular-feature]  arg: 'delete-row' x: 0 y: 0
  cur:
 cursor:| anchor:
 inset: 02A163DE44B0 idx: 0 par: 0 pos: 0 | inset:
02A163DE44B0 idx: 0 par: 0 pos: 0
 inset: 02A1640B77B0 idx: 12 par: 0 pos: 0 | inset:
02A1640B77B0 idx: 5 par: 0 pos: 0
 selection: 1 boundary: 0

Undo.cpp (152): Create undo element of group c
insets\InsetTabular.cpp (19d9): Feature: delete-row value:
 C:/Users/pc1/newfile14.lyx.emergency
support/os_win32.cpp (149): 
[~/newfile14.lyx.emergency]->>[~\newfile14.lyx.emergency]

Is this what you meant (or is there a better way to backtrace)?
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows (?) Table Crash

[Udicoudco]

On Sun, Jun 2, 2024 at 7:32 PM Richard Kimberly Heck  wrote:
>
> We've had a report of the following sort of crash, or maybe assertion.
>
> Create a table. Mark more than half the rows or columns. Delete those
> (using the toolbar button, but I doubt that matters). Boom.
>
> I cannot reproduce on Linux, but Eugene was able to reproduce on
> Windows. Anyone else?

I can reproduce on Windows as well.

Udi

> --
> 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: Regression in 2.4.0

[Udicoudco]

On Fri, May 17, 2024 at 12:05 AM Jean-Marc Lasgouttes
 wrote:
>
> Le 16/05/2024 à 22:38, Jean-Marc Lasgouttes a écrit :
> >> Why do we have an exception for arabic-arabi?
> >> Is the output different from hebrew?
> >
> > My guess is that it was in 2017 when I wrote f1dd80f464b46f61:
> >
> > * the language arabic_arabi also sets leqno by default. This is
> >currently hardcoded for lack of a better idea.
> >
> > I tried again, and indeed I do not see that. I see though that numbers
> > are like )1(. Is this expected?

No, this is probably a bug in LyX.
the arabi package (the .ldf file) has the following

\addto\extrasarabic{%
\let\SAV@@eqnnum\@eqnnum
\let\SAV@tagform@\tagform@
\def\tagform@#1{\maketag@@@{)\ignorespaces#1\unskip\@@italiccorr(}}%
if amsmath is loaded
\renewcommand{\@eqnnum}{)\theequation(}% otherwise
}

\addto\noextrasarabic{%
\let\@eqnnum\SAV@@eqnnum
\let\tagform@\SAV@tagform@
}

probably \textLR does not use \noextrasarabic so the parenthesis are
reversed in left to right context, but they should not be.

> I just read the arabi package change log and source and, indeed, I see
> nothing suggesting that the number should be on the left.

There is maybe something related in page 76 of the documentation (the
last point),
it is suggested to pass the reqno option. Strangely if I use reqn or leqno, with
or without amsmath, or with or without ams class, e.g. amsart, I get different
and arguably unexpected results.

> I can change that later in the 2.4.x lifetime. Also, LyX believes that
> numbers should be with arabic glyphs, but I see an output as normal
> numbers. What is normally expected?

If I remove the \textLR that wraps the equation in the LaTeX source
I get correct parenthesis, the equation number is on the left side,
and the number is an arabic glyph. This is probably related to
https://www.lyx.org/trac/ticket/12731

When I tested now, for hebrew it looks great, but
now arabic_arabi looks the same in the GUI, i.e.
the equation tag is not flipped like in LyX 2.3.x.

Udi


> --
> 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: Regression in 2.4.0

[Udicoudco]

For some reason I only received Riki's message, and yours Jean-Marc
(but I can read them in the archive...)

On Thu, May 16, 2024 at 6:05 PM Richard Kimberly Heck
 wrote:
>
> On 5/16/24 09:03, Jean-Marc Lasgouttes wrote:
> > Le 15/05/2024 à 15:00, Udicoudco a écrit :
> >>> About the side, I thought I had tested that in some way. Is the side
> >>> consistent across all methods to switch to Hebrew (babel, polyglossia,
> >>> something else I do not know…)?
> >
> > It turns out that we kept the equation number to the right (in intent)
> > for all languages but "arabic_arabi". Would it be worth trying to
> > reflect output in the case of luabidi? It is probably easy.
> >
> > The real issue is now fixed at b469c142ad579d.
> >

I'm not currently at home, I'm house sitting my mothers place for the weekend.
I've actually brought my PC with me, but was disappointed to discover that
the only monitor here is not compatible with my PC...
The neighbours lent me a TV screen so now I'm setting up
everything and will test soon (internet connection is very slow).

As for luabidi, maybe there will be a change upstream,
so I wouldn't reflect the equation tags yet.

Why do we have an exception for arabic-arabi?
Is the output different from hebrew?
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Regression in 2.4.0

[Udicoudco]

On Wed, May 15, 2024 at 1:45 PM Jean-Marc Lasgouttes  wrote:
>
> Le 10/05/2024 à 20:34, Udicoudco a écrit :
> > Dear all,
> >
> > I think I've encountered a regression in the 2.4 branch.
> >
> > The location of equation numbers/tags in RTL paragraphs seems wrong to me.
>
> Could you give more details about why it seems wrong? I did not manage
> to set up a working Hebrew environment, so I cannot really compare to
> PDF output.
>
> What I do see is that the number position is too low. Is that what you
> are describing?
>

Yes, sorry for not being clear, the  PDF output is OK, it is the GUI
that has changed, the equation tagging is
on the wrong side and a bit lower than the equation. I attached an
example file and a couple of screenshots.


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

Regression in 2.4.0

[Udicoudco]

Dear all,

I think I've encountered a regression in the 2.4 branch.

The location of equation numbers/tags in RTL paragraphs seems wrong to me.

When I tried to bisect yesterday I got way back to 2019 until I could not
compile anymore.

My suspicion is that it is related to the fact that Layouts alignment in
RTL context in 2.4 is flipped (right alignment is left in RTL context) but
I could not confirm that.

I don't have access to the bug tracker anymore (which is probably not
surprising), sorry for reporting it by mail in the last minute.

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

Re: [LyX/2.4.x] Remerge strings for 2.4.0 release

[Udicoudco]

On Fri, May 10, 2024, 8:14 PM Richard Kimberly Heck 
wrote:

> commit 544cf0794eddcd44bc872e5a28c1a97ada109b1b
> Author: Richard Kimberly Heck 
> Date:   Fri May 10 13:14:09 2024 -0400
>
> Remerge strings for 2.4.0 release
>

Riki,

Sorry for reporting that in the last minute, but I've noticed that there
are some inconsistencies in the hebrew.po after the last updates. Is there
still time to fix them? I won't have access to a computer until tomorrow
evening to push a fix.

Udi

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

Re: Test failure after tlmgr update (not a LyX issue)

[Udicoudco]

On Sat, May 4, 2024, 9:46 PM Kornel Benko  wrote:

> Am Fri, 3 May 2024 10:31:42 -0400
> schrieb Scott Kostyshak :
>
> > This is likely not a LyX issue so feel free to ignore.
> >
> > After a tlmgr update, the following tests now fail:
> >
> >   export/export/latex/languages/en-ja_platex_dvi3_systemF (Failed)
> >   export/export/latex/languages/en-ja_platex_pdf4_systemF (Failed)
> >   export/export/latex/languages/en-ja_platex_pdf5_systemF (Failed)
> >
> > I attach the file that corresponds to the pdf4_systemF test for
> > convenience.
> >
> > The LaTeX error I now get is the following:
> >
> >   ! Illegal parameter number in definition of \l__exp_internal_tl.
> >
> > I'm going to ask a question on tex.se to figure out where to report this
> > potential regression, but first I wanted to check in here and see if
> > anyone else can reproduce this error after a tlmgr update or if it might
> > be something local to my system (I have a few hacks in there).
> >
> > Scott
>
> I don't have these errors. (TL24 updated today)
>  # ctest -R en-ja_platex_
> ...
> 100% tests passed, 0 tests failed out of 7
>
> Kornel
> --


See: https://tug.org/pipermail/tex-live/2024-May/050511.html

Udi

>
> 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: Deleted citations in CT mode

[Udicoudco]

On Wed, Jan 24, 2024 at 11:20 PM Pavel Sanda  wrote:
> Do you see any other trick than manually breaking the citation inset into
> several ones?

You can use lua-ul (requires LuaTeX) instead of ulem,
as suggested in https://www.lyx.org/trac/ticket/11577.
See the attached file.

Udi


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

Delete documentation about non existent feature

[Udicoudco]

Riki, I know you said I should not do any substantive
changes to the documentation, but a feature called
"Respect OS keyboared language" is documented
in appendix C.5.1.2 while it is not  part of 2.4.0,
see https://www.lyx.org/trac/ticket/6450.

What do you think? should I remove it from UsersGuide.lyx,
or is it better to wait for translators to finish and then remove it
from all the translations, or keep things as they are?

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

Re: Europe CV not compiling

[Udicoudco]

On Wed, Oct 11, 2023 at 1:50 AM José Matos  wrote:
>
> On Tue, 2023-10-10 at 23:58 +0200, Dan wrote:
> > Hello,
> >
> > I stumbled upon a problem compiling with pdflatex the "Europe CV"
> > example. I get the following error, in both languages available:
> > Spanish and English.
> > Can someone try and reproduce the problem so that I know whether it
> > is specific to me or the document itself? Thanks.
> >
> > PROBLEM
> > ---
> >   1. File > Open Examples... > Europe CV.
> >   2. Generate the preview of the document.
> >   3. Check whether the following error arises.

See https://github.com/gsilano/EuropeCV/pull/30

Since LyX does not load inputenc with utf8x in this document,
maybe you just don't have the latest version of europecv?


> I get this error repeated several times:
>
> ! LaTeX hooks Error: Sorting rule for 'begindocument' hook applied too
> late.

I'm not sure why the maintainer was reluctant to load hyperref earlier
(with \AddToHook{begindocument/before} rather than \AddToHook{begindocument}),
as it is clearly a problem, see
https://github.com/latex3/hyperref/issues/242 and
https://github.com/gsilano/EuropeCV/pull/33 .

Adding to the preamble \AddToHook{begindocument/before}{\usepackage{hyperref}}
should fix this error (maybe LyX should add that...).

Best regards,
Udi

> --
> 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: [LyX/master] Amend 087f6bce

[Udicoudco]

On Sun, Oct 1, 2023 at 11:55 AM Jürgen Spitzmüller  wrote:
>
> Am Sonntag, dem 01.10.2023 um 11:29 +0300 schrieb Udicoudco:
> > Probably not for 2.4.0, but we can use
> > \adjustbox from the adjustbox package
> > for that. See section 4.5 (cfbox in particular).
>
> An easier fix for the page background problem is to use
> page_backgroundcolor if it is defined. This can be done for 2.4.

There is also the fbox package. Documentation only 5 page long,
the code only about 100 lines, required packages only xcolor and
xkeyval, and the author is Herbert Voß. Looks pretty good, might
be worth looking into that.

> --
> 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: [LyX/master] Amend 087f6bce

[Udicoudco]

On Sun, Oct 1, 2023 at 12:37 PM Jürgen Spitzmüller  wrote:
> I'd expect the page color here, actually.

Ok, if this is subjective I'll leave that.

> Sure. But \fcolorbox is quite simplistic.

Not sure I understand. Is there a reason for not using \fcolorbox
when the frame color is explicitly black and the background is none?
It means that the behavior of framed boxes is not consistent between
black and other colors (of course default should be different).

> --
> 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: [LyX/master] Amend 087f6bce

[Udicoudco]

On Sun, Oct 1, 2023 at 11:55 AM Jürgen Spitzmüller  wrote:
>
> Am Sonntag, dem 01.10.2023 um 11:29 +0300 schrieb Udicoudco:
> > Probably not for 2.4.0, but we can use
> > \adjustbox from the adjustbox package
> > for that. See section 4.5 (cfbox in particular).
>
> An easier fix for the page background problem is to use
> page_backgroundcolor if it is defined. This can be done for 2.4.

What about framed boxes inside colored boxes? (See newfile1.lyx).
Also, setting a "correct" background color is quite different from no
background, with regards the internal structure of the pdf.

About not using \fcolorbox when the color is explicitly black, I don't
currently have a good example, but what about situations like in
newfile2.lyx? Are we sure a user can't somehow get the wrong color?
Doesn't seem very robust.

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


newfile1.lyx
Description: application/lyx


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

Re: [LyX/master] Amend 087f6bce

[Udicoudco]

On Sun, Oct 1, 2023 at 10:59 AM Jürgen Spitzmüller  wrote:
>
> Am Sonntag, dem 01.10.2023 um 10:47 +0300 schrieb Udicoudco:
> > It still looks like \fcolorbox is used with an explicit black
> > color. Is this intentional?
>
> Yes, if the background color is non-empty. Likewise, with non-default
> frame color, the background color is set to white
>
> This is not ideal (and wrong e.g. with non-white page color), but alas
> \fcolorbox requires us to pass explicit colors for both frame and
> background.
>
> There are some workarounds on stackexchange for this, but all those
> strike me pretty ugly.

Probably not for 2.4.0, but we can use
\adjustbox from the adjustbox package
for that. See section 4.5 (cfbox in particular).

> --
> 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: [LyX/master] Amend 087f6bce

[Udicoudco]

On Sun, Oct 1, 2023 at 10:36 AM Jürgen Spitzmüller  wrote:
>
> Am Sonntag, dem 01.10.2023 um 09:26 +0200 schrieb Jürgen Spitzmüller:
> > This is wrong. We must not load xcolor either with default and with
> > (explicit) black color.

It still looks like \fcolorbox is used with an explicit black
color. Is this intentional?

I would prefer to leave things as is.
Setting the color to be black explicitly
sound to me like the frame should be
affected form lines like

\definecolor{black}{rgb}{0.8, 0.8, 0.9}

Best regards,
Udi

> --
> 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: Many ctests failing on current master

[Udicoudco]

On Sat, Sep 30, 2023 at 9:36 PM Scott Kostyshak  wrote:
>
> The list of ctests below fail for me due to a recent commit. I don't
> currently have time to look into them. If no one gets to it before, I
> can take a look next week.
>
>   DEFAULTOUTPUT_export/export/latex/inputenc-utf8-platex_pdf (Failed)
>   export/export/latex/inputenc-utf8-platex_pdf3 (Failed)

This one is probably my fault:
https://www.lyx.org/trac/changeset/48eda746dabecf100bd163b822ed9db68ab9eb3f/lyxgit
I actually tested platex before changing that, not sure what is going
on with this particular
document, it claims David CLM does not contain hebrew punctuation.
Let's just drop the change
in platex export until 2.4 will be released.

>   export/templates/Articles/IEEE_Transactions_Computer_Society_lyx22 (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_lyx23 (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_dvi (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_dvi3_texF 
> (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_dvi3_systemF 
> (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_pdf (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_pdf2 (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_pdf3 (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_pdf4_systemF 
> (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_pdf5_texF 
> (Failed)
>   export/templates/Articles/IEEE_Transactions_Computer_Society_pdf5_systemF 
> (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_lyx22 (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_lyx23 (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_dvi (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_dvi3_texF (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_dvi3_systemF (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_pdf (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_pdf2 (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_pdf3 (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_pdf4_systemF (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_pdf5_texF (Failed)
>   export/templates/Articles/IEEE_Transactions_Journal_pdf5_systemF (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_lyx22 (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_lyx23 (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_dvi (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_dvi3_texF (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_dvi3_systemF 
> (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_pdf (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_pdf2 (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_pdf3 (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_pdf4_systemF 
> (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_pdf5_texF (Failed)
>   export/templates/Articles/IEEE_Transactions_on_Magnetics_pdf5_systemF 
> (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_lyx22 (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_lyx23 (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_dvi (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_dvi3_texF (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_dvi3_systemF (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_pdf (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_pdf2 (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_pdf3 (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_pdf4_systemF (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_pdf5_texF (Failed)
>   export/templates/Articles/REVTeX_%28V._4.1%29_pdf5_systemF (Failed)
>   export/templates/Posters/A0_Poster/Simple_lyx22 (Failed)
>   export/templates/Posters/A0_Poster/Simple_lyx23 (Failed)
>   export/templates/Posters/A0_Poster/Simple_dvi (Failed)
>   export/templates/Posters/A0_Poster/Simple_dvi3_texF (Failed)
>   export/templates/Posters/A0_Poster/Simple_dvi3_systemF (Failed)
>   export/templates/Posters/A0_Poster/Simple_pdf (Failed)
>   export/templates/Posters/A0_Poster/Simple_pdf2 (Failed)
>   export/templates/Posters/A0_Poster/Simple_pdf3 (Failed)
>   export/templates/Posters/A0_Poster/Simple_pdf4_systemF (Failed)
>   export/templates/Posters/A0_Poster/Simple_pdf5_texF (Failed)
>   export/templates/Posters/A0_Poster/Simple_pdf5_systemF (Failed)
>   export/templates/Theses/PhD_Thesis/Main_File_lyx22 (Failed)
>   export/templates/Theses/PhD_Thesis/Main_File_lyx23 (Failed)
>   export/templates/Theses/PhD_Thesis/Main_File_dvi (Failed)
>   export/templates/Theses/PhD_Thesis/Main_File_dvi3_texF (Failed)
>   

Re: redundant cprotect's

[Udicoudco]

On Thu, Sep 28, 2023 at 6:19 PM Scott Kostyshak  wrote:
>
> On Thu, Sep 28, 2023 at 04:34:45PM +0300, Udicoudco wrote:
> > Hello all,
> >
> > Can anyone think of a simple case where cprotect is used?
> > I think we have some redundant cases where we can remove
> > the protection (such as before \L or \R because they don't really
> > take an argument), and I want to test that.
>
> We have some test documents. Do you by chance use CMake to build LyX? If
> so, add the flag "-DLYX_ENABLE_EXPORT_TESTS=ON" in your 'cmake' call
> (unfortunately this flag adds some time, e.g., 20 seconds) and then you
> can run:
>
>   ctest -R "cprotect"
>
> First run that to confirm the tests currently pass for you (all 30 do
> for me).
>
> Then make the code change and run those tests again.
>
> Those tests took just 42 seconds to run serially, but if you want to
> speed things up, you can run them in parallel, e.g.:
>
>   ctest -j8 -R "cprotect"
>
> This took 10 seconds.
>
> If something in the above process doesn't work, let us know and we can
> try to figure it out. I think only Kornel and I have been running the
> ctests so it would be great to have other testers.

I don't yet tried to use CMake to build LyX, But I'm actually plan to do
a fresh install on my windows machine. I've read that it is recommended
to use CMake to build LyX on windows, so I'll almost surely give it a try.
Hopefully I'll be able to set up a proper environment without any troubles.
Thanks for all the details!

> If you don't want to use the ctests, you can also search the repository
> for "cprotect" to find the test documents. It would be great to have
> some test documents in Hebrew if you can contribute some. Currently, I
> think our tests only check compilation errors. i.e., they don't check
> that the appearance is correct.

I'm not sure I follow. Did you mean that the current Hebrew test files
only test for compilation errors? or that in general, if I would like
to contribute
some test files, the appearance is not a factor for the document?

How do the tests check for errors? Does the .log file get parsed
somehow or we are
only interested in major errors and not warning?

Best regards,
Udi

> --
> 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

redundant cprotect's

[Udicoudco]

Hello all,

Can anyone think of a simple case where cprotect is used?
I think we have some redundant cases where we can remove
the protection (such as before \L or \R because they don't really
take an argument), and I want to test that.

Best regards,
Udi
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: spurious spaces around forceLTR insets

[Udicoudco]

On Mon, Apr 10, 2023 at 1:43 PM Jürgen Spitzmüller  wrote:
>
> Am Montag, dem 10.04.2023 um 08:38 +0200 schrieb Jürgen Spitzmüller:
> > Am Montag, dem 10.04.2023 um 08:08 +0200 schrieb Jürgen Spitzmüller:
> > > Let's address this next. I'll push the patch meanwhile.
> >
> > I have integrated a modification of the former patch on top of the
> > other. Please test.
>
> Udi,
>
> It seems that with luabidi (luatex/polyglossia), the \LRE needs to be
> wrapped itself in a group. Otherwise text that follows the \LRE{} is
> lost.
>
> Can you confirm?
> A MWE to try is https://www.lyx.org/trac/attachment/ticket/3005/LRE.lyx
>
> Attached a patch that fixes the issue for me.
>
> (Probably a bug in luabidi, but this package is virtually unmaintained)
>

Jürgen,

I've made a pull request  to luabidi that should fix this issue.
If you will commit, we can revert this patch.

Best regards,
Udi

> 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: Re: [LyX/master] + es/Letter standard class (from Dan)

[Udicoudco]

On Sun, Sep 24, 2023 at 9:24 PM Udicoudco  wrote:
>
> On Sun, Sep 24, 2023 at 8:59 PM Dan  wrote:
> > I could not reproduce the problem in "article" or "book" document classes, 
> > but it does arise in these classes (test LaTeX document attached)
> >   - paper
> >   - Koma-Script variants: scrartcl, scrbook, scrreport.
>
> As the bug report show, the symbols '>' and '<' are activated (have
> category code 13 and their
> definition is of the form \active@prefix >\active@char>), this is
> regardless of the documentclass.
> The fact that there is an error really depends on the body of the
> document (see the attachment
> for a simple example of a document that use article and produce an error).
>
>
> > The last activity in that repository was two years ago... I am unsure 
> > whether he still watches that. I can try to reach him through 
> > http://www.cervantex.es/. Also, to see if anyone there has experienced this 
> > problem with babel-spanish, as there is a mailing list for users of (La)TeX 
> > in Spanish.
>
> Javier is the maintainer of babel in general and is very active.
> I think it is reasonable to wait a few days before trying to reach
> him in other ways.
>
> > That is another option, with the plus that the user can turn it on/off at 
> > will.
> > That line alone in the preamble will not work, the language package must be 
> > added as well, like this
> >
> > \usepackage[spanish]{babel}
> > \deactivatequoting
> >
> > because LyX puts the preamble code BEFORE the language-package inclusion.
>
> I meant to add the macro \deactivatequoting to the PostBabelPreamble tag
> of Spanish in lib/languages, i.e. replacing
>
> \addto\shorthandsspanish{\spanishdeactivate{~<>}}
>
> with
>
> \addto\shorthandsspanish{\spanishdeactivate{~}}
> \deactivatequoting
>
> Best regards,
> Udi
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Re: [LyX/master] + es/Letter standard class (from Dan)

[Udicoudco]

On Sun, Sep 24, 2023 at 5:12 AM Dan  wrote:
>
> Data: 24 de set. de 2023, 2:40
> De: skost...@lyx.org
> A: d3v...@tutanota.com
> Assumpte: Re: [LyX/master] + es/Letter standard class (from Dan)
>
>
> > On Sun, Sep 24, 2023 at 01:48:17AM +0200, Dan wrote:
> >
> >> I provide a better workaround for this problem: custom command to set the 
> >> language in Document > Settings... > Language.
> >> The command is
> >>  \usepackage[spanish,es-noquoting]{babel}
> >> which sets the document's language to Spanish and disables the shorthands 
> >> < and >; and for some reason seems to work ^^'.

Yes, I've noticed this option exists, the problem is not just with Letter
document class. The problem that babel-spanish activates '<' and '>'
at the beginning of the document (unless the es-noquoting option
is passed or the macro \deactivatequoting is issued before that), so using

\addto\shorthandsspanish{\spanishdeactivate{<>}}

won't work correctly. I've made a bug report at babel-spanish,
and I'm waiting for a reply from Javier.

> > Thanks, I committed it at fa67f709. If anyone suggests a different
> > approach/fix, feel free to change it.

It fixes the problem only for the example file. But all other files would
still have '<' and '>' activated, and from the line

\addto\shorthandsspanish{\spanishdeactivate{~<>}}

in the languages file we are clearly trying to avoid that.
I don't think passing the option es-noquoting is good for a general solution,
as it prevents from users to activate '<' and '>' if they would like
to, probably
adding to the preamble the line \deactivatequoting is the best way to go.

Let's wait and see what Javier is saying at
https://github.com/jbezos/babel-spanish/issues/11


Best regards,
Udi
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] + es/Letter standard class (from Dan)

[Udicoudco]

On Sat, Sep 23, 2023 at 9:09 PM Udicoudco  wrote:
>
> On Sat, Sep 23, 2023 at 7:37 PM Scott Kostyshak  wrote:
> >
> > On Sat, Sep 23, 2023 at 05:40:19PM +0200, Dan wrote:
> > >
> > >
> > > > On Tue, Sep 19, 2023 at 10:31:16PM +0200, Pavel Sanda wrote:
> > > >
> > > >> commit a624e52c95f43dacc0dfb19a3392fcc642f3ae4d
> > > >> Author: Pavel Sanda 
> > > >> Date:   Tue Sep 19 23:47:58 2023 +0200
> > > >>
> > > >>  + es/Letter standard class (from Dan)
> > > >> ---
> > > >>
> > > >
> > > > Does this compile for you? For me I get an error:
> > > >
> > > >  ! Extra \fi.
> > > >  \language@active@arg> ...string #1@\endcsname \fi
> > > >
> > > > Scott
> > > >
> >
>
> See section 1.10 of babel's manual, on page 12 under
> "TROUBLESHOOTING". There cannot be
> a closing curly brace after a shorthand, and in babel-spanish ">" is a
> shorthand.
>
> Attached is a manual workaround for this particular document, but it
> should be fixed somehow.
> maybe we should keep a list of shorthands for each language and check
> if there is a closing curley
> brace after a shorthand?
>

Oh  wait, I did not notice that LyX adds the line

\addto\shorthandsspanish{\spanishdeactivate{~<>}}

to the preamble. but for some reason the shorthand does not get
deactivated... even the category code is wrong.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] + es/Letter standard class (from Dan)

[Udicoudco]

On Sat, Sep 23, 2023 at 7:37 PM Scott Kostyshak  wrote:
>
> On Sat, Sep 23, 2023 at 05:40:19PM +0200, Dan wrote:
> >
> >
> > > On Tue, Sep 19, 2023 at 10:31:16PM +0200, Pavel Sanda wrote:
> > >
> > >> commit a624e52c95f43dacc0dfb19a3392fcc642f3ae4d
> > >> Author: Pavel Sanda 
> > >> Date:   Tue Sep 19 23:47:58 2023 +0200
> > >>
> > >>  + es/Letter standard class (from Dan)
> > >> ---
> > >>
> > >
> > > Does this compile for you? For me I get an error:
> > >
> > >  ! Extra \fi.
> > >  \language@active@arg> ...string #1@\endcsname \fi
> > >
> > > Scott
> > >
>

See section 1.10 of babel's manual, on page 12 under
"TROUBLESHOOTING". There cannot be
a closing curly brace after a shorthand, and in babel-spanish ">" is a
shorthand.

Attached is a manual workaround for this particular document, but it
should be fixed somehow.
maybe we should keep a list of shorthands for each language and check
if there is a closing curley
brace after a shorthand?

Best regards,
Udi


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

Re: Is loading inputenc with two encodings a bug?

[Udicoudco]

On Sun, Aug 20, 2023 at 12:52 AM Udicoudco  wrote:
>
>
> Should the second input encoding be changed from latin9 to utf8,
> now that utf8 is the default encoding?
>
or are we separating traditional and unicode encoding
entirely?
> > --
> > 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: Is loading inputenc with two encodings a bug?

[Udicoudco]

On Sat, Dec 17, 2022 at 10:44 AM Jürgen Spitzmüller  wrote:
>
> Am Freitag, dem 16.12.2022 um 10:32 -0500 schrieb Scott Kostyshak:
> > Attached is a .lyx file that produces the following code when
> > exported
> > with LaTeX (pdflatex):
> >
> >   \usepackage[latin9,cp1255]{inputenc}
> >
> > Ulrike Fisher points out the following [1]:
> >
> >   \usepackage[latin9,cp1255]{inputenc} doesn't make any sense, your
> >   files can't have two encodings at the same time.
> >
> > Should I make a trac ticket for this?
>
> Yes. Of course a file can have multiple encodings, and encodings can be
> switch via \inputencoding with a file. The inputenc package, however,
> only expects one option. It sets the latter to the inputencoding at at
> package loading time, which is cp1255 here.

Should the second input encoding be changed from latin9 to utf8,
now that utf8 is the default encoding?

I mean the encoding used in the command \inputencoding,
not the option of the package.

> --
> 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: Customization ctests now failing on master

[Udicoudco]

On Fri, Aug 11, 2023 at 11:11 PM Udicoudco  wrote:
> I propose a different approach. see the patch prettyref.patch.

Another possible patch attached

>  lyx-devel mailing list
>  lyx-devel@lists.lyx.org
>  http://lists.lyx.org/mailman/listinfo/lyx-devel
diff --git a/src/LaTeXFeatures.cpp b/src/LaTeXFeatures.cpp
index 0e678ea62a..457d7236ac 100644
--- a/src/LaTeXFeatures.cpp
+++ b/src/LaTeXFeatures.cpp
@@ -1107,7 +1107,6 @@ char const * simplefeatures[] = {
 	"pifont",
 	// subfig is handled in BufferParams.cpp
 	"varioref",
-	"prettyref",
 	"refstyle",
 	/*For a successful cooperation of the `wrapfig' package with the
 	  `float' package you should load the `wrapfig' package *after*
@@ -1286,10 +1285,16 @@ string const LaTeXFeatures::getPackages() const
 
 	// Babel languages with activated colon (such as French) break
 	// with prettyref. Work around that.
-	if (!runparams_.isFullUnicode() && useBabel()
-	&& mustProvide("prettyref") && contains(getActiveChars(), ':')) {
-		packages << "% Make prettyref compatible with babel active colon\n"
-			 << "\\def\\prettyref#1{\\expandafter\\@prettyref\\detokenize{#1:}}\n";
+	bool const fix_prettyref = (!runparams_.isFullUnicode() && useBabel()
+	&& contains(getActiveChars(), ':'));
+
+	if (mustProvide("prettyref")) {
+		if (fix_prettyref)
+			packages << "% Make prettyref compatible with babel active colon\n"
+ << "\\edef\\LyXFixForPrettyRef{\\the\\catcode`:}\\catcode`:=13\n";
+		packages << "\\usepackage{prettyref}\n";
+		if (fix_prettyref)
+			packages << "\\catcode`:=\\LyXFixForPrettyRef\\relax\n";
 	}
 
 	if (mustProvide("changebar")) {
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Customization ctests now failing on master

[Udicoudco]

On Fri, Aug 11, 2023 at 8:09 PM Jürgen Spitzmüller  wrote:
>
> Am Freitag, dem 11.08.2023 um 17:39 +0200 schrieb Jürgen Spitzmüller:
> > Should be fixed now.
>
> Not yet. It does compile, but the references are broken.

Jürgen, your code should work, you just forgot
to  change the category code of @.
See the patch prettyref-detokenize.patch.

But I think we should note it could potentially
change the behaviour of the package, If you'll
export the file newfile1.lyx after applying prettyref-detokenize.patch,
you will get different results if the language of the document
 is english or french.

I propose a different approach. see the patch prettyref.patch.
I'm not sure what is the best way to stream strings into the latex source,
so feel free to change things, and if you have the patience to explain
what I should have done, I'll appreciate it :)

> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
diff --git a/src/LaTeXFeatures.cpp b/src/LaTeXFeatures.cpp
index 0e678ea62a..ffddef2b85 100644
--- a/src/LaTeXFeatures.cpp
+++ b/src/LaTeXFeatures.cpp
@@ -1289,7 +1289,9 @@ string const LaTeXFeatures::getPackages() const
 	if (!runparams_.isFullUnicode() && useBabel()
 	&& mustProvide("prettyref") && contains(getActiveChars(), ':')) {
 		packages << "% Make prettyref compatible with babel active colon\n"
-			 << "\\def\\prettyref#1{\\expandafter\\@prettyref\\detokenize{#1:}}\n";
+			 << "\\makeatletter\n"
+			 << "\\def\\prettyref#1{\\expandafter\\@prettyref\\detokenize{#1:}}\n"
+			 << "\\makeatother\n";
 	}
 
 	if (mustProvide("changebar")) {
diff --git a/src/LaTeXFeatures.cpp b/src/LaTeXFeatures.cpp
index 0e678ea62a..6c53e19e23 100644
--- a/src/LaTeXFeatures.cpp
+++ b/src/LaTeXFeatures.cpp
@@ -1289,7 +1289,18 @@ string const LaTeXFeatures::getPackages() const
 	if (!runparams_.isFullUnicode() && useBabel()
 	&& mustProvide("prettyref") && contains(getActiveChars(), ':')) {
 		packages << "% Make prettyref compatible with babel active colon\n"
-			 << "\\def\\prettyref#1{\\expandafter\\@prettyref\\detokenize{#1:}}\n";
+			"\\bgroup\n"
+			"\\makeatletter\n"
+			"\\catcode`:=13\n"
+			"\\gdef\\prettyref#1{\\@prettyref#1:}\n"
+			"\\gdef\\@prettyref#1:#2:{%\n"
+			" 	\\expandafter\\ifx\\csname pr@#1\\endcsname\\relax\n"
+			"		\\PackageWarning{prettyref}{Reference format #1\\space undefined}%\n"
+			"		\\ref{#1:#2}%\n"
+			"	\\else\n"
+			"		\\csname pr@#1\\endcsname{#1:#2}%\n"
+			"	\\fi}\n"
+			"\\egroup\n";
 	}
 
 	if (mustProvide("changebar")) {


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

Re: Customization ctests now failing on master

[Udicoudco]

On Fri, Aug 11, 2023 at 8:09 PM Jürgen Spitzmüller  wrote:
>
> Am Freitag, dem 11.08.2023 um 17:39 +0200 schrieb Jürgen Spitzmüller:
> > Should be fixed now.
>
> Not yet. It does compile, but the references are broken. I'll see if I

I think

   \def\prettyref#1{\expandafter\@prettyref\expanded{#1\string:}}

will give correct results

> --
> 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: \lBrack [was Re: Double brackets]

[Udicoudco]

On Sat, Jul 22, 2023 at 10:53 PM Richard Kimberly Heck
 wrote:
>
> On 7/22/23 14:45, Udicoudco wrote:
> > On Sat, Jul 22, 2023 at 9:40 PM Richard Kimberly Heck
> >  wrote:
> >> On 7/22/23 14:28, Herbert Voss wrote:
> >>> Am 22.07.23 um 17:24 schrieb Dan:
> >>> if you want to use the old names. However, LyX do not know the new
> >>> names and do not render it.
> >> That should be an easy one to fix. I'm cc'ing devel.
> >>
> > This is probably an example of https://www.lyx.org/trac/ticket/10540
>
> I think this one is easier. In that case, the same command has a
> different unicode meaning than in standard LaTeX. In this case, we can
> treat it almost like an alias, as far as display is concerned.
>

Oh, I thought this ticket was about general support for unicode-math commands.
If this is not the case, maybe https://www.lyx.org/trac/ticket/11885
should not be
considered as a duplicate? As far as I can tell, we can treat, for
example, \symbf
as an alias of \mathbf, as far as display is concerned.

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

Re: \lBrack [was Re: Double brackets]

[Udicoudco]

On Sat, Jul 22, 2023 at 9:40 PM Richard Kimberly Heck
 wrote:
>
> On 7/22/23 14:28, Herbert Voss wrote:
> > Am 22.07.23 um 17:24 schrieb Dan:
> >> I am trying to write a Lie bracket [[a, b ]].  The commands
> >> \llbracket and \rrbracket work just fine in the LyX math formula, but
> >> doesn't render in LuaTex.  I could conceivably use a negative space
> >> and join the symbols | and [ (with some fussing) but I can't get LyX
> >> to recognize \! as a negative spacer.  (That's another question,
> >> really.  I don't need that answered here if there is a simpler way to
> >> do this.)
> >
> > The names for uniicode-math ate \lBrack and \rBrack.
> >
> > Write into the preamble
> >
> > \let\llbracket\lBrack
> >
> > \let\rrbracket\rBrack
> >
> > if you want to use the old names. However, LyX do not know the new
> > names and do not render it.
>
> That should be an easy one to fix. I'm cc'ing devel.
>
This is probably an example of https://www.lyx.org/trac/ticket/10540
> --
> 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: Insert underscore (_) in math ERT?

[Udicoudco]

On Fri, Jul 7, 2023 at 11:30 AM Udicoudco  wrote:
> \let\Scott_
Sorry, it should be \let\foo_ of course... I mixed things a bit :)
Attached a corrected example.


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


math_ert_underscore.23.lyx
Description: application/lyx
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Insert underscore (_) in math ERT?

[Udicoudco]

On Fri, Jul 7, 2023 at 11:09 AM Scott Kostyshak  wrote:
> Basically, is there any workaround to be able to use LyX's math mode and 
> output the LaTeX \Sexpr{mean(x_draws)}?
>
> If I try to paste from LaTeX, LyX converts it to the following: 
> $\Sexpr{mean(x_{d}raws)}$, which gives a knitr error.

I cannot test my proposition (I don't think I have knitr installed),
but I've done similar tricks with xy-pic.
You can trick LyX by \let-ing a macro to "_" (for example
\let\Scott_), then create a math macro, say named
\foo, with an TeX part, and \_ in the LyX part, then using
\Sexpr{mean(x\foo draws)} should work. Attached an example.

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


math_ert_underscore.23.lyx
Description: application/lyx
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Udicoudco]

On Fri, Jun 16, 2023 at 6:17 PM Pavel Sanda  wrote:
>
> On Thu, Jul 14, 2022 at 07:20:13AM +0300, Udicoudco wrote:
> > I wrote a module that provides essentially the same layouts as the "
> > Theorems (Numbered by Type within Sections)" module, but with a new
>
> Dear Udi,
>
> I got somewhat lost in the long and detailed thread. Would you mind to 
> summarize
> the current status (current patch, missing things, unfixed bugs, objections 
> from
> others on so on).
>
Sorry for the delayed response. I've noticed that users (sometimes even me)
are getting confused with the current situation of the theorems
modules, especially
with regards to the `Requires` and `Excludes` attributes, and I don't
want to accentuate
the confusion with more modules.

For example see this thread
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg219221.html
theoretically the situation with `Requires` and `Excludes` graphs
could be messy, practically
it only happens with the theorems modules, without a real
justification for the mess, while
all other modules seem to be fine.

I think it would be better to organize the existing  modules before
adding a new one.
I'll open a ticket where I'll explain the current situation, add some
suggestions and ask for
some advice.

>I think this is the last moment to consider this stuff into 2.4...

This is not really urgent so it could wait for the next release. In the meantime
I will upload the new modules to LyX wiki.

As for the minor bugs I described in
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg218016.html
the fix for them could potentially modify the output (at least the one
related to named theorems and the one
about theorems-proof-std.inc), so I'm not sure what the policy is here
(maybe a file format change is required?).

Best,
Udi

> --
> 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: Wrong Clines with RTL tabular

[Udicoudco]

On Sat, Dec 24, 2022 at 2:03 AM Udicoudco  wrote:
>
> Yes, it behaves like that only if the option layout=tabular is passed.
> I think that currently without it, any RTL text inside tabulars is written
> as LTR

With recent versions of babel the default column direction (without
layout=tabular)
of tabulars when a bidi option is used is LTR, and the text should
render correctly, so we can probably drop this subject.

Regards,
Udi

>> 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: Unicode characters in mathed

[Udicoudco]

On Sat, Apr 1, 2023 at 4:10 PM Jean-Marc Lasgouttes  wrote:
> In particular, instead of typing \neq in mathed, why not copy and paste
> a ≠ from some PDF or HTML page?
>
> When doing this, two things happen :
> 1/ on screen, there is no spacing around the ≠
> 2/ in LaTeX output, the character is exported as \neq and all is well
>
> So how should I solve problem 1/ ? I see 3 solutions
> a/ replace ≠ with a \neq directly in the document at input time; we
> might not want to do that in case we eventually use unicode in math too
> b/ replace ≠ with a \neq on screen only
> c/ keep the ≠ on screen, but use the mathrel math class from \neq so
> that we have a good spacing

I would say option b, as unicode-math supports unicode characters inside
math mode. Maybe some users would prefer a latex source that
contains the unicode symbols  and not the corresponding macros.

Ot maybe a better solution would be to add a checkbox in
Document->Settings->Math Options and let the user decide
between option a and option b. but that would probably
require more work.

> --
> 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: spurious spaces around forceLTR insets

[Udicoudco]

On Mon, Apr 10, 2023 at 5:49 PM Scott Kostyshak  wrote:
>
> On Mon, Apr 10, 2023 at 03:08:52PM +0200, Jürgen Spitzmüller wrote:
> > Am Montag, dem 10.04.2023 um 15:49 +0000 schrieb Udicoudco:
> >
> > Thanks, and welcome now "officially" :-)
>
> +1 welcome! It's nice to have you around.
>

Thank you for the warm welcome!

> --
> 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: [LyX/master] Fixes to heb-article, by Udi Fogiel (#12735)

[Udicoudco]

On Mon, Apr 10, 2023 at 8:22 PM Udicoudco  wrote:
>
> On Mon, Apr 10, 2023 at 7:34 PM Scott Kostyshak  wrote:
> >
> > On Mon, Apr 10, 2023 at 05:19:51PM +0200, Juergen Spitzmueller wrote:
> > > commit d0a83d33fcc0db64bd2b8bc79671c4427ddc18e6
> > > Author: Juergen Spitzmueller 
> > > Date:   Mon Apr 10 18:24:04 2023 +0200
> > >
> > > Fixes to heb-article, by Udi Fogiel (#12735)
> > >
> > > For some reason theorems titles has \beginR without a \endR, and since
> > > this is basically inside restricted horizontal mode, TeX complains 
> > > about
> > > a missing \endR.
> > >
> > > I could not figure out why were they there in the first place so I
> > > removed them and the output did not change, and the warnings are gone.
> > >
> > > Beside that the numbering of the theorems is wrong (e.g. 1.0 instead 
> > > of
> > > 0.1), the \@makelr thing should happen after babel is loaded.
> > >
> > > The theorems layouts did not have a counter (in LyX) so I added one.
> > > ---
> >
> > >  Style Remarks
> > >   CopyStyle Theorem
> > >   LatexName remark
> > > - LabelString   "Remarks #."
> > > + LabelString   "הערות \thetheorem."
> >
> > Should the LabelString be untranslated, like: "Remarks \thetheorem." ?
>
> Note that LyX  does not translate Remarks, and הערות is hardcoded in
> the latex definition,
> isn't it preferable that LyX will display הערות in this case?

Should I add Remarks to layouttranslation for hebrew?

> > --
> > 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: [LyX/master] Fixes to heb-article, by Udi Fogiel (#12735)

[Udicoudco]

On Mon, Apr 10, 2023 at 7:34 PM Scott Kostyshak  wrote:
>
> On Mon, Apr 10, 2023 at 05:19:51PM +0200, Juergen Spitzmueller wrote:
> > commit d0a83d33fcc0db64bd2b8bc79671c4427ddc18e6
> > Author: Juergen Spitzmueller 
> > Date:   Mon Apr 10 18:24:04 2023 +0200
> >
> > Fixes to heb-article, by Udi Fogiel (#12735)
> >
> > For some reason theorems titles has \beginR without a \endR, and since
> > this is basically inside restricted horizontal mode, TeX complains about
> > a missing \endR.
> >
> > I could not figure out why were they there in the first place so I
> > removed them and the output did not change, and the warnings are gone.
> >
> > Beside that the numbering of the theorems is wrong (e.g. 1.0 instead of
> > 0.1), the \@makelr thing should happen after babel is loaded.
> >
> > The theorems layouts did not have a counter (in LyX) so I added one.
> > ---
>
> >  Style Remarks
> >   CopyStyle Theorem
> >   LatexName remark
> > - LabelString   "Remarks #."
> > + LabelString   "הערות \thetheorem."
>
> Should the LabelString be untranslated, like: "Remarks \thetheorem." ?

Note that LyX  does not translate Remarks, and הערות is hardcoded in
the latex definition,
isn't it preferable that LyX will display הערות in this case?

> --
> 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: spurious spaces around forceLTR insets

[Udicoudco]

On Mon, Apr 10, 2023 at 12:14 PM Jürgen Spitzmüller  wrote:
>
> Am Montag, dem 10.04.2023 um 14:37 + schrieb Udicoudco:
> > I think this is actually a bug in LuaTeX.
> > Attached a minimal file that produces similar
> > behaviour.
> >
> > Note that if I comment the line
> > \textdir TLT
> >
> > in the attached file the output is ok, but \textdir is TLT by
> > default,
> > so I find it strange.
>
> I see. So what do you recommend? Work around it (apply the patch) or
> only report to LuaTeX?

Since \LRE{...} already adds a grouping level, I fail to think of
a situation where adding another one would be problematic.

Should that be applied to numbers as well?
I think \LR is equivalent to \LRE.

About a permission for my contributions:

I hereby grant permission to license my contributions to LyX under the Gnu
General Public Licence, version 2 or later.



> 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: spurious spaces around forceLTR insets

[Udicoudco]

On Mon, Apr 10, 2023 at 10:43 AM Jürgen Spitzmüller  wrote:
>
> Am Montag, dem 10.04.2023 um 08:38 +0200 schrieb Jürgen Spitzmüller:
> > Am Montag, dem 10.04.2023 um 08:08 +0200 schrieb Jürgen Spitzmüller:
> > > Let's address this next. I'll push the patch meanwhile.
> >
> > I have integrated a modification of the former patch on top of the
> > other. Please test.
>
> Udi,
>
> It seems that with luabidi (luatex/polyglossia), the \LRE needs to be
> wrapped itself in a group. Otherwise text that follows the \LRE{} is
> lost.
>
> Can you confirm?
> A MWE to try is https://www.lyx.org/trac/attachment/ticket/3005/LRE.lyx
>
> Attached a patch that fixes the issue for me.
>
> (Probably a bug in luabidi, but this package is virtually unmaintained)
>

I think this is actually a bug in LuaTeX.
Attached a minimal file that produces similar
behaviour.

Note that if I comment the line
\textdir TLT

in the attached file the output is ok, but \textdir is TLT by default,
so I find it strange.

> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
%\the\textdir
\textdir TLT
ab{\textdir TRT ab}\textdir TLT ab

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

Re: Wrong Clines with RTL tabular

[Udicoudco]

On Sun, Apr 2, 2023 at 12:52 PM Jürgen Spitzmüller  wrote:
>
> Please try again with current master.
>

Can confirm it is working now.

Thanks,
Udi

> --
> 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: spurious spaces around forceLTR insets

[Udicoudco]

On Sun, Apr 9, 2023 at 1:15 PM Jürgen Spitzmüller  wrote:
>
>
> To elaborate, the attached patch demonstrates what I mean. It also
> handles "inline" environments properly, given that they have set
> "Display false" in their layout definition.
>

Oh, now I see! Yes, that would make more sense. But I still have two queries:

1) shouldn't display equations be wrapped with

   \LRE{%
   \[a+b=c\]
   }%
   otherwise vertical spacing would be wrong. Though, note that I
opened a bug ticket (https://www.lyx.org/trac/ticket/12731)
   where I explained why I think math equations shouldn't be decorated
at all with such commands.

2) The patch does not seem to fix the problematic spaces for
pdflatex+babel, and I don't think there is a counterpart for
the LTR environment in this case.

> --
> 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: spurious spaces around forceLTR insets

[Udicoudco]

On Sun, Apr 9, 2023 at 12:23 PM Jürgen Spitzmüller  wrote:
>
> Meanwhile I think we don't need this if we go for the other one and
> include inDisplayMath to the objects where we use the LTR environment
> rather than the command.
>

What about "inline" environments?

> --
> 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: spurious spaces around forceLTR insets

[Udicoudco]

On Sun, Apr 2, 2023 at 12:00 PM Jürgen Spitzmüller  wrote:
>
> Am Mittwoch, dem 22.03.2023 um 22:39 + schrieb Udicoudco:
> > In some cases, e.g. displayed equation,
> > LyX wraps a forceLTR inset like so:
> >
> > \LRE{
> > \[
> > a+b=c
> > \]
> > } continuous text here...
> >
> > which might cause undesired space
> > if the user is not careful.
> >
> > Attached a LyX file to demonstrate the problem and a patch to fix it.
>
> Thanks. Could you try if the attached patch works for you? It employs
> the slightly more elegant texstream methods rather than literal comment
> chars.
>

I've used this patch in the past few days and it looks great.

Thanks,
Udi

> --
> 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: Does anyone use dvipdfmx to export Hebrew files?

[Udicoudco]

On Tue, Apr 4, 2023 at 10:12 PM Scott Kostyshak  wrote:
>
> I used to be able to export our Hebrew documents to PDF using dvipdfmx. This 
> doesn't work for me anymore, and I'm wondering if it is worth the effort to 
> try to fix it on my system, or whether I should just drop these tests (in 
> favor of the XeTeX and LuaTeX tests).
>
> Does the export work for anyone? To check, you first need to uncheck "use 
> system fonts" in document settings.

Works for me. Both on texlive and miktex.

> If it does work, does anyone know whether this converter chain is used in 
> practice these days?

I personally have old files using this converter chain. I've also noticed
that most new lyx users aren't aware that it is much better yp use
XeLaTeX or LuaLaTeX with Hebrew, so they use it.

 Also, In some rare cases there times when I'm forced to work
with pdfTeX.

> Here is my terminal output with the error:
>
> dvipdfmx:warning: Could not locate a virtual/physical font for TFM "david".
> dvipdfmx:warning: This font is mapped to a physical font 
> "DavidCLM-Medium.pfa".
> dvipdfmx:fatal: Sorry, pfa format not supported; please convert the font to 
> pfb, e.g., with t1binary.

Note that none of the Hebrew fonts (David CLM in particular) are
shipped with TeXLive.
You can install them from here:
https://sourceforge.net/projects/ivritex/files/culmus-latex/culmus-latex-0.7/

To install, Use the MAKE file, ot copy the two directories from the
.tar.gz file called tex and fonts, from use/share/texmf/
to a local texmf tree.

If you copied the directories manually, run updmap --enable
Map=culmus.map (or updmap -sys --enable Map=culmus.map) afterwards.

Regards,
Udi

> 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: Warnings when using Listings in a RTL document

[Udicoudco]

On Wed, Mar 22, 2023 at 10:28 PM Udicoudco  wrote:
>
> > I attached a possible patch, it only fix the lstlisting case when
> > polyglossia is used, since babel-hebrew does not have an equivalent
> > to \begin{RTL}...\end{RTL} (or there is one?) and babel with luatex
> > does not need this kind of wrappers.
> I've added line breaks to the LaTeX code for
> readability.

I've forgot to test if we use polyglossia at the closing point
of the inset. Attached a new patch

> > Regards,
> > Udi
> > > --
> > > lyx-devel mailing list
> > > lyx-devel@lists.lyx.org
> > > http://lists.lyx.org/mailman/listinfo/lyx-devel
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index c43421b376..851fac846e 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1101,9 +1101,14 @@ void Paragraph::Private::latexInset(BufferParams const & bparams,
 	// ERT is an exception, it should be output with no
 	// decorations at all
 	&& inset->lyxCode() != ERT_CODE) {
-		if (runparams.use_polyglossia)
-			// (lua)bidi
-			os << "\\LRE{";
+		if (runparams.use_polyglossia) {
+ 			// (lua)bidi
+			if (inset->getLayout().name() == "Listings"
+			|| inset->getLayout().name() == "MintedListings")
+os << "\n\\begin{RTL}";
+			else	
+os << "\\LRE{";
+		}
 		else if (running_font.language()->lang() == "farsi"
 			 || running_font.language()->lang() == "arabic_arabi")
 			os << "\\textLR{" << termcmd;
@@ -1187,8 +1192,14 @@ void Paragraph::Private::latexInset(BufferParams const & bparams,
 		throw;
 	}
 
-	if (close)
-		os << '}';
+	if (close) {
+		if (runparams.use_polyglossia
+			&& (inset->getLayout().name() == "Listings"
+			|| inset->getLayout().name() == "MintedListings"))
+os << "\\end{RTL}\n";
+		else
+			os << '}';
+	}
 
 	if (os.texrow().rows() > previous_row_count) {
 		os.texrow().start(owner_->id(), i + 1);
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

spurious spaces around forceLTR insets

[Udicoudco]

Hello all,

In some cases, e.g. displayed equation,
LyX wraps a forceLTR inset like so:

\LRE{
\[
a+b=c
\]
} continuous text here...

which might cause undesired space
if the user is not careful.

Attached a LyX file to demonstrate the problem and a patch to fix it.

Regards,
Udi
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index c43421b376..c351def4ad 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1110,6 +1110,9 @@ void Paragraph::Private::latexInset(BufferParams const & bparams,
 		else
 			// babel classic
 			os << "\\L{";
+		if (inset->getLayout().latextype() == InsetLaTeXType::ENVIRONMENT 
+			|| runparams.inDisplayMath)
+os << '%';
 		close = true;
 	}
 
@@ -1187,8 +1190,12 @@ void Paragraph::Private::latexInset(BufferParams const & bparams,
 		throw;
 	}
 
-	if (close)
+	if (close) {
 		os << '}';
+		if (inset->getLayout().latextype() == InsetLaTeXType::ENVIRONMENT 
+			|| runparams.inDisplayMath)
+os << "%\n";
+	}
 
 	if (os.texrow().rows() > previous_row_count) {
 		os.texrow().start(owner_->id(), i + 1);


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

Re: Warnings when using Listings in a RTL document

[Udicoudco]

> I attached a possible patch, it only fix the lstlisting case when
> polyglossia is used, since babel-hebrew does not have an equivalent
> to \begin{RTL}...\end{RTL} (or there is one?) and babel with luatex
> does not need this kind of wrappers.
I've added line breaks to the LaTeX code for
readability.

> Regards,
> Udi
> > --
> > lyx-devel mailing list
> > lyx-devel@lists.lyx.org
> > http://lists.lyx.org/mailman/listinfo/lyx-devel
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index c43421b376..93a0a7fee5 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1101,9 +1101,14 @@ void Paragraph::Private::latexInset(BufferParams const & bparams,
 	// ERT is an exception, it should be output with no
 	// decorations at all
 	&& inset->lyxCode() != ERT_CODE) {
-		if (runparams.use_polyglossia)
+		if (runparams.use_polyglossia) {
 			// (lua)bidi
-			os << "\\LRE{";
+			if (inset->getLayout().name() == "Listings"
+			|| inset->getLayout().name() == "MintedListings")
+os << "\n\\begin{RTL}";
+			else	
+os << "\\LRE{";
+		}
 		else if (running_font.language()->lang() == "farsi"
 			 || running_font.language()->lang() == "arabic_arabi")
 			os << "\\textLR{" << termcmd;
@@ -1187,8 +1192,13 @@ void Paragraph::Private::latexInset(BufferParams const & bparams,
 		throw;
 	}
 
-	if (close)
-		os << '}';
+	if (close) {
+		if (inset->getLayout().name() == "Listings"
+			|| inset->getLayout().name() == "MintedListings")
+os << "\\end{RTL}\n";
+		else
+			os << '}';
+	}
 
 	if (os.texrow().rows() > previous_row_count) {
 		os.texrow().start(owner_->id(), i + 1);
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Warnings when using Listings in a RTL document

[Udicoudco]

On Wed, Mar 22, 2023 at 2:22 PM Scott Kostyshak  wrote:
>
> On Wed, Mar 22, 2023 at 01:13:27PM +0100, Jürgen Spitzmüller wrote:
> > Am Mittwoch, dem 22.03.2023 um 12:54 +0200 schrieb Udicoudco:
> > > I think in the case of where forceLTR insets will have multiple
> > > paragraphs, it is better to use
> > > \begin{RTL}...\end{RTL}, which basically only issues \par and sets
> > > the
> > > RTL related conditionals
> > > to be false.
> >
> > Thanks for the detailed explanation. Could you please file a ticket on
> > trac?
>

Sorry Jürgen, I did not notice I hit reply instead of reply all in my
last email.
I'm currently having difficulties with getting access to the bug tracker. If
I will manage to log in, I'll do that, but this is not likely to happen.

> If there's a patch, I'd be happy to run it through the ctests. If I recall 
> correctly, we have a good amount of tests for documents using Hebrew.

I attached a possible patch, it only fix the lstlisting case when
polyglossia is used, since babel-hebrew does not have an equivalent
to \begin{RTL}...\end{RTL} (or there is one?) and babel with luatex
does not need this kind of wrappers.

Regards,
Udi
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index c43421b376..93a0a7fee5 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -1101,9 +1101,14 @@ void Paragraph::Private::latexInset(BufferParams const & bparams,
 	// ERT is an exception, it should be output with no
 	// decorations at all
 	&& inset->lyxCode() != ERT_CODE) {
-		if (runparams.use_polyglossia)
+		if (runparams.use_polyglossia) {
 			// (lua)bidi
-			os << "\\LRE{";
+			if (inset->getLayout().name() == "Listings"
+			|| inset->getLayout().name() == "MintedListings")
+os << "\\begin{RTL}";
+			else	
+os << "\\LRE{";
+		}
 		else if (running_font.language()->lang() == "farsi"
 			 || running_font.language()->lang() == "arabic_arabi")
 			os << "\\textLR{" << termcmd;
@@ -1187,8 +1192,13 @@ void Paragraph::Private::latexInset(BufferParams const & bparams,
 		throw;
 	}
 
-	if (close)
-		os << '}';
+	if (close) {
+		if (inset->getLayout().name() == "Listings"
+			|| inset->getLayout().name() == "MintedListings")
+os << "\\end{RTL}";
+		else
+			os << '}';
+	}
 
 	if (os.texrow().rows() > previous_row_count) {
 		os.texrow().start(owner_->id(), i + 1);
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Warnings when using Listings in a RTL document

[Udicoudco]

Slight correction, the lines
>
> \@RTLfalse\beginL{
> \begin{lstlisting}
> Hello
> \end{lstlisting}
> }\endL
>

should be

{\@RTLfalse\beginL
 \begin{lstlisting}
 Hello
 \end{lstlisting}
 }\endL

and the lines

>
> \@RTLfalse\beginL{
> \par
> Hello
> \par
> }\endL
>

should be

{\@RTLfalse\beginL
 \begin{lstlisting}
 Hello
 \end{lstlisting}
 }\endL

>
> Regards,
> Udi
>
> > --
> > 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: Warnings when using Listings in a RTL document

[Udicoudco]

On Tue, Mar 21, 2023 at 9:40 PM Scott Kostyshak  wrote:
>
> On Tue, Mar 21, 2023 at 12:50:06PM +0100, Jürgen Spitzmüller wrote:
> > Am Dienstag, dem 21.03.2023 um 11:27 +0000 schrieb Udicoudco:
> > > Hello all,
> > >
> > > Attached a LyX file and its export to LaTeX code.
> > > When compiling with XeLaTeX the exported code
> > > I get the warning:
> > >
> > > \endL or \endR problem (0 missing, 1 extra) in paragraph at lines
> > > 26--27
> >
> > Interestingly, I don't get this warning with your example file. This is
> > with TeXLive 2023.
>
> I can reproduce on both TeXLive 2022 and TeXLive 2023. Note that the word 
> "warning" is not used in the log file for this message. I get the same 
> message as Udi except that the line numbers are different:
>
>   \endL or \endR problem (0 missing, 1 extra) in paragraph at lines 28--29
>
> Scott

I've been reading e-TeX's and bidi's manuals, and done some experiments
To understand what is the meaning of this message, and why it is present.

It seems that the primitives \beginR and \beginL does not have to end with
\endR or \endL when used in horizontal mode (not restricted horizontal mode),
and if this is the case, e.g we started \beginR without ending it, all
subsequent text
will be typeset in a RTL paragraph, and the behaviour is restored to the default
at the start of the next paragraph.

If there is a \endL without \beginL at the paragraph level, we get a
message of the form

   \endL or \endR problem (0 missing, 1 extra) in paragraph at lines

inside \hbox the message will be a bit different.

The bidi package patches \everypar such that if the conditional \if@RTL is true
then \beginR is inserted at the start of the paragraph, otherwise
\beginL is inserted.

The command \LRE from the bidi package sets the conditional \if@RTL to
false.  In addition,
this macro does not really have an argument, it basically expands to
something of the form

\LRE{Hello} -> {\beginL Hello}\endL (the \endL is outside of the group
intentionally)

Hence there will be no error if the "argument" contains several
paragraphs, even though   \LRE
is not \long, but it is not meant to be used with such an "argument".

Now, when we do

\LRE{
\begin{lstlisting}
Hello
\end{lstlisting}
}

We basically have

\@RTLfalse\beginL{
\begin{lstlisting}
Hello
\end{lstlisting}
}\endL

Since the lstlisting start and end with \par, if we will discard
anything not important we will remain with

\@RTLfalse\beginL{
\par
Hello
\par
}\endL

Since all the primitives \beginL, \beginR, \endL, \endR are horizontal
commands, they start a paragraph.
So the line "}\endL" started a paragraph, outside of the scope  where
\if@RTL is false, hence the paragrpah
started with \beginR, and so the \endL does not match any  \beginL.

I think in the case of where forceLTR insets will have multiple
paragraphs, it is better to use
\begin{RTL}...\end{RTL}, which basically only issues \par and sets the
RTL related conditionals
to be false.

Regards,
Udi

> --
> 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

Warnings when using Listings in a RTL document

[Udicoudco]

Hello all,

Attached a LyX file and its export to LaTeX code.
When compiling with XeLaTeX the exported code
I get the warning:

\endL or \endR problem (0 missing, 1 extra) in paragraph at lines 26--27

If I replace

 \LRE{
\begin{lstlisting}
Hello
\end{lstlisting}
}

With

\begin{LTR}
\begin{lstlisting}
Hello
\end{lstlisting}
\end{LTR}

the warning is gone. Does anyone know the meaning of the warning?
Maybe it's better to use \begin{LTR} ... \end{LTR} in some cases?

Regards,
Udi
%% LyX 2.4.0-beta3-devel created this file.  For more info, see https://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[english,hebrew]{article}
\usepackage{fontspec}
\setlength{\parindent}{0bp}

\makeatletter
%% User specified LaTeX commands.
\newfontfamily\hebrewfont{David CLM}

\makeatother

\usepackage{listings}
\usepackage{polyglossia}
\setdefaultlanguage{hebrew}
\setotherlanguage{english}
\addto\captionsenglish{\renewcommand{\lstlistingname}{Listing}}
\addto\captionshebrew{\renewcommand{\lstlistingname}{רישום קוד}}
\renewcommand{\lstlistingname}{רישום קוד}

\begin{document}
\LRE{
\begin{lstlisting}
Hello
\end{lstlisting}
}

\end{document}


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

Re: reversed parentheses with babel and xe/luatex

[Udicoudco]

On Fri, Mar 17, 2023 at 4:45 PM Jürgen Spitzmüller 
wrote:
>
> Am Freitag, dem 17.03.2023 um 14:45 + schrieb Udicoudco:
> > Please ignore the last patch, here is the correct one.
>
> Isn't this the right patch? AFAIU we do not need to swap at all if
> babel is used with Xe/LuaTeX, right?
>

Yes, I was only considering parentheses for some reason. Thank you for the
correction (as usual ;)).

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

Re: reversed parentheses with babel and xe/luatex

[Udicoudco]

On Fri, Mar 17, 2023 at 2:41 PM Udicoudco  wrote:
>
> Hello all,
>
> Currently LyX reverse parentheses when babel and xe/luatex is used
> with Hebrew, and it should not do so. Attached a patch that fixes this matter.

Please ignore the last patch, here is the correct one.
> Best Regards,
> Udi
From 8c7b6228dccfb7b0ac8c786d86a1079516ba0d5d Mon Sep 17 00:00:00 2001
From: Udi Fogiel 
Date: Fri, 17 Mar 2023 14:30:13 +
Subject: [PATCH] reversed parentheses with babel and Xe/LuaTeX

---
 src/Paragraph.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 8650826e4f..9e74120155 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -2048,8 +2048,10 @@ char_type Paragraph::getUChar(BufferParams const & bparams,
 	char_type uc = c;
 
 	// 1. In the following languages, parentheses need to be reversed.
-	//Also with polyglodia/luabidi
-	bool const reverseparens = (lang == "hebrew" || rp.use_polyglossia);
+	//Also with polyglossia/luabidi
+	bool const reverseparens = (lang == "hebrew" || rp.use_polyglossia)
+	// With babel and Xe/LuaTeX parentheses should not be reversed 
+	&& (!rp.isFullUnicode() || !rp.use_babel);
 
 	// 2. In the following languages, brackets don't need to be reversed.
 	bool const reversebrackets = lang != "arabic_arabtex"
-- 
2.35.1

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

reversed parentheses with babel and xe/luatex

[Udicoudco]

Hello all,

Currently LyX reverse parentheses when babel and xe/luatex is used
with Hebrew, and it should not do so. Attached a patch that fixes this matter.

Best Regards,
Udi
From 8c7b6228dccfb7b0ac8c786d86a1079516ba0d5d Mon Sep 17 00:00:00 2001
From: Udi Fogiel 
Date: Fri, 17 Mar 2023 14:30:13 +
Subject: [PATCH] reversed parentheses with babel and Xe/LuaTeX

---
 src/Paragraph.cpp | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 8650826e4f..9e74120155 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -2048,8 +2048,10 @@ char_type Paragraph::getUChar(BufferParams const & bparams,
 	char_type uc = c;
 
 	// 1. In the following languages, parentheses need to be reversed.
-	//Also with polyglodia/luabidi
-	bool const reverseparens = (lang == "hebrew" || rp.use_polyglossia);
+	//Also with polyglossia/luabidi
+	bool const reverseparens = (lang == "hebrew" || rp.use_polyglossia)
+	// With babel and Xe/LuaTeX parentheses should not be reversed 
+	&& (!runparams.isFullUnicode() || !runparams.use_babel);
 
 	// 2. In the following languages, brackets don't need to be reversed.
 	bool const reversebrackets = lang != "arabic_arabtex"
-- 
2.35.1

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

Re: New Theorems Module

[Udicoudco]

On Sat, Dec 31, 2022 at 12:49 PM Udicoudco  wrote:

>
>
> On Sat, Dec 31, 2022 at 10:33 AM Thibaut Cuvelier 
> wrote:
>
>> 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?)
>> --
>>
> I will restore the missing modules, so we don't need to do anything about
> lyx2lyx.
>

If i ill change the non-AMS modules to not use amsthm, and will add to
their name `-plain`
prefix, would it be possible to make lyx2lyx update files using e.g.
theorems.module to use
theorems-ams.module?

If so, I could add the changes to the non-AMS modules to the patch, but I
don't know anything about lyx2lyx.


>
>> 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

[Udicoudco]

On Sat, Dec 31, 2022 at 10:35 AM Thibaut Cuvelier 
wrote:

>
>
> 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).
>

I think that some of the confusion comes from the fact that the options for
the AMS and non-AMS are not symmetrical, and the fact that
currently the non-AMS actually use amsthm (this is the part I tried to fix
in the patch but it did not work, but it shouldn't be hard to fix).

If we would consider adding all the options to all three theorem backends
(LaTeX kernel, amsthm, and thmtools), there would
be 36 theorem modules (not including the starred theorems and named
theorems), as there will be 3 options for backends,
3 options for the parent counter (none, chapter, section), two options to
number-by type (yes/no), and two options for extended (yes, no).

Maybe it would be more user friendly to add a Theorems dialog to
Document->Settings? I think it was like that in old LyX versions.
The dialog could have a check box to indicate if the user wants to use
theorems or not.
If yes there would be a drop-down menu for each category to choose the type
of theorems
you want to use.

It will also help with the confusion that sometimes occurs with the fact
that some theorem modules
require other theorem modules to be loaded first.

I don't know how to implement that so it is just a proposal.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Udicoudco]

On Sat, Dec 31, 2022 at 10:33 AM Thibaut Cuvelier 
wrote:

> 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?)
> --
>
I will restore the missing modules, so we don't need to do anything about
lyx2lyx.


> 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

[Udicoudco]

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.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Udicoudco]

On Sat, Dec 31, 2022 at 4:36 AM 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?
>
> Scott
>
>
Hi Scott,

It is the fault of my patch, I will send a new one.

Regards,
Udi

> 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

[Udicoudco]

On Sat, Dec 31, 2022 at 3:00 AM 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.
>
>
Hi Thibaut Cuvelier, thank you for the patch. After browsing LyX's bug
tracker in the past few weeks, i now realize that some of the changes i've
made on the subject discussed in this thread
  will
break backward compatibility and and will produce undesirable export to TeX
code (one that works, for example, the syntax won't be supported by IDEs).

 I will send today a patch regarding only the new module so it will be
easier to test it.


> (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
>
>
> On Sat, 31 Dec 2022 at 01:00, Thibaut Cuvelier 
> wrote:
>
>> 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
>>
>>
I will add these changes to the new patch.

Best 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

[Udicoudco]

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

Re: Wrong Clines with RTL tabular

[Udicoudco]

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

[Udicoudco]

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: Wrong Clines with RTL tabular

[Udicoudco]

On Fri, Dec 23, 2022 at 9:05 AM Jürgen Spitzmüller 
wrote:

> Am Donnerstag, dem 22.12.2022 um 18:49 + schrieb Udicoudco:
>
> If you set "Always babel" you can use in preamble
>
> \PassOptionsToPackage{bidi=basic,layout=tabular,provide=*}{babel}
>
> As babel is loaded after the user preamble, the babel-specific commands
> need to be set as
>
> \AddToHook{package/babel/after}{
> \babelfont[hebrew]{rm}{David CLM}
> \babelfont[english]{rm}{Latin Modern Roman}
> }
>
> See attached modified file.
>
>
> Thank you  for the advice and the file, it looks much better now.


> Yes, this looks like a bug. I have pushed a fix to master. If you could
> test that, this would be great.
>
>
I've tried the fix. it does remove most of \R and \L instances, but:

1) Every forceRTL layout is still wrapped with \L{} (except ERT, as usual)

2) The cursor movement is backward inside forceRTL layout written in hebrew
   (including ERT, and in english the movement direction is correct).


>
> Probably, and we have a similar report concerning \inputencoding with
> no inputenc package. But then, OTOH, some people might have used this
> setting for the case babel or inputenc are loaded in the class. These
> documents would break, so we cannot change that without accounting for
> backwards compatibility.
>
> > Another issue with using LyX and LuaTeX with RTL language
> >  is identical to  this ticket I mentioned previously.
> > The file RTL_tabular_lua2.lyx demonstrates that.
>
> I see, so babel with bidi reverses table columns, but only if the
> layout=table option is used? This needs some more thoughts to be
> implemented properly.
>
>
> Yes, it behaves like that only if the option layout=tabular is passed.
I think that currently without it, any RTL text inside tabulars is written
as LTR, this is why i want to use babel and not polyglossia with lualatex,
as polyglossia does not have a solution for that (or i'm not aware of one).
with xetex polyglossia inputs the file *array*-*xetex*-*bidi*.*def, *which
causing
similar effect as the layout=tabular option.

I could contact Javier Bezos and ask if this option should always be used
with RTL languages and lualatex. If  so, should lyx pass it by default when
using luatex and RTL language?

Note that it is not only affecting tables, but any environment that uses
tabular.
If for example you will remove this option from the file you sent
previously, the author
text will typeset backwards.

 Any comments regarding this question:
   Could math equations be made as an exception to forceRTL decoration,
just as ERT?

Thank you,
Udi


> 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: Wrong Clines with RTL tabular

[Udicoudco]

On Thu, Dec 22, 2022 at 2:49 PM Jürgen Spitzmüller 
wrote:

> Am Donnerstag, dem 22.12.2022 um 10:39 + schrieb Udicoudco:
>


> You can simply select "Language package: always babel" if you want
> babel with LuaTeX.
>
>

It seems that I can not pass the options i want to babel from
the document class declaration, if you will try to move all
the babel option to the document class declaration
in the newfile1.tex you will see the problem.

Also LyX still adds the \R and \L macros with
this configuration, even though they are not
defined.

 Unrelated to my specific problem,
 I think it would make more sense to prevent LyX from
wrapping things with \R, \L and similar macros

when you prevent LyX from adding a language package automatically,

as this will make this option unusable sometimes.
I could write in my preamble "\let\R\relax"
to prevent the error

! Undefined control sequence.

 \R


for example , but the exported code would contain a lot of unnecessary \R's
and \L's.


Another issue with using LyX and LuaTeX with RTL language

is identical to this ticket <https://www.lyx.org/trac/ticket/9686> I
mentioned previously.

The file RTL_tabular_lua2.lyx demonstrates that.


>
>
That's an effect of the fix to
> https://www.lyx.org/trac/ticket/10548
>
>
> If I understand, any layout that is tagged as forceRTL is wrapped with
\LRE (or \L if not using polyglossia),
except ERT.  Since this does not affect math equations in any way (as they
are always printed LTR),
I think that equations should be an exception too. Math equations sometimes
appear a lot in a document,
and this \LRE can cause some spacing problems  (see for example this post
<https://tex.stackexchange.com/questions/610036/bidi-lre-command-causes-too-much-vertical-space-if-put-at-end-of-an-item-in-a-li>,
and this post
<https://tex.stackexchange.com/questions/611598/stop-lyx-from-automatically-wrapping-formulas-with-lre-in-hebrew>
),
and it makes the latex code unreadable without any advantage.

Could math equations be an exception just as ERT?

Best Regards,
Udi

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


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

Re: Wrong Clines with RTL tabular

[Udicoudco]

On Thu, Dec 22, 2022 at 6:09 AM Jürgen Spitzmüller 
wrote:

> Am Donnerstag, dem 22.12.2022 um 01:02 +0200 schrieb Udicoudco:
>


> Note that this is fixed in master (2.4dev). I don't think we will
> backport the fix to stable (2.3.x), since 2.3.7 is already finished and
> 2.3.8 will presumably be released together with 2.4.0.
>
>
> That's great!  you saved me the trouble of opening a ticket (i should
 have checked what happens in master).

So, I tried to export the tabular with LuaTeX instead, and the
\cline problem is resolved, as mentioned in the ticket LyX does not
invert the syntax with LuaTeX.

The problem is that LyX use polyglossia by default with non-TeX fonts and
LuaTeX,
and to my knowledge there is no utility for RTL tabular with LuaLaTeX and
polyglossia (i.e. all the text
inside the tabular is LTR).

With XeLaTeX there's the file *array*-*xetex*-*bidi*.*def, *but as the name
suggest,
It is only used with XeTeX and bidi. Note that most latex document classes
use tabular for title (or author to be exact) and similar layouts, so this
is a bit annoying ( attached a LyX file to demonstrate the problem, i
tested this in master).

With babel there is the option layout=tabular which fixes that, but then
the tabulars need to be typed
As with Xelatex and polyglossia.

Would it be reasonable to format the output latex code when exporting an
RTL LyX document
with LuaTeX s.t it will use babel instead of polyglossia?  (attached a
latex file that demonstrates the format i want to achieve, it somewhat
resembles this example file
<https://github.com/latex3/babel/blob/main/samples/lua-hebrew.tex> from
babel repository).

I tried to disable all language support from lyx (no language package etc.)
but then LyX behaves just as with pdflatex and  RTL languages,
it inserts some RTL related code by itself, e.g., \R, \L, and with babel
and luatex these commands are not defined.

I have one final question on the matter. Why does LyX enclose every
equation with \LRE when exporting a hebrew document with XeLaTeX?
I could not figured the use of that, and  it somewhat clumps the exported
code.

Best Regards,
Udi

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


RTL_tabular_lua.lyx
Description: application/lyx
\documentclass{article}

\usepackage[english,main=hebrew,bidi=basic,layout=tabular,provide=*]{babel}

\babelfont[hebrew]{rm}{David CLM}

\babelfont[english]{rm}{Latin Modern Roman}

\begin{document}
\title{כותרת}
\author{מחבר המאמר}

\maketitle
\begin{tabular}{|c|c|}
\hline 
שלום & להתראות\tabularnewline
\hline 
\end{tabular}

שלום להתראות 
\selectlanguage{english}
Hello world
\selectlanguage{hebrew}
שלום \foreignlanguage{english}{Thank you.}
\end{document}
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Wrong Clines with RTL tabular

[Udicoudco]

Dear LyX developers,

It seems that LyX switches the directions of \cline inside the tabular
while using RTL language with XeLaTeX.

I think it is related to this ticket ,
as the fix to this bug was to invert the syntax of the tabular, but, for
example \cline{1-1} would produce a line under the left most cell,
unrelated to the macro horizontal location.

Attached a minimal example.

Regards,
Udi


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

Re: Is loading inputenc with two encodings a bug?

[Udicoudco]

On Fri, Dec 16, 2022 at 5:32 PM Scott Kostyshak  wrote:
>
> Attached is a .lyx file that produces the following code when exported
> with LaTeX (pdflatex):
>
>   \usepackage[latin9,cp1255]{inputenc}
>
> Ulrike Fisher points out the following [1]:
>
>   \usepackage[latin9,cp1255]{inputenc} doesn't make any sense, your
>   files can't have two encodings at the same time.
>
> Should I make a trac ticket for this?
>
> Scott
>
>
> [1] 
> https://tex.stackexchange.com/questions/668474/cant-compile-when-using-wrap-figure?noredirect=1#comment1661827_668474

I've exported the .lyx file to a .tex file and erased the latin9
option. It seems to work fine with both English and Hebrew. But,
wouldn't utf8 encoding be preferable?  Attached a minimal example.
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel


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

Re: Starting new environment in the middle of a line

[Udicoudco]

On Thu, Nov 10, 2022 at 9:22 AM Udicoudco  wrote:

>
>
> On Wed, Nov 9, 2022 at 7:16 PM Scott Kostyshak 
> wrote:
>
>> Sometimes (but not too often), I want to start an environment in the
>> middle of a line.
>>
>> In LaTeX, it seems to work fine, although I don't know if this is
>> considered bad practice. But in LyX, we can only start an environment at
>> the beginning of a paragraph I believe.
>>
>
> To my knowledge lyx starts  a new line with nested environments in the
> latex code, but that should not start a new paragraph, unless the latex
> environment   is forcing you to start a new paragraph with \par or a
> similar command.
>
>
>> Attached is an example in LyX that uses ERT. I haven't actually
>> implemented this environment in LyX yet (I'm still planning to). Sometimes
>> I can use the \uncover command, but other times I prefer an environment.
>>
>> I also attach an example .tex file with an environment that is
>> implemented in LyX (block). I attach the example as a .tex file
>> (example-block.tex), and the imported .lyx file
>> (example-block-imported.23.lyx). LyX makes a paragraph break and then nests
>> the environment. This causes a linebreak that I don't want in the
>> corresponding PDF.
>>
>
> I think that the differences in the output PDF are coming from using the
> block environment with the non ERT version and the uncover environment in
> the file with the ERT (note that also the .tex files produces the same pdf
> as example-block-imported.23.lyx)
>
> To check my suspicion I've tried to see if using uncover as a style layout
> in lyx will cause this problem. To do so I copied the block layout from the
> beamer.layout file to the local layout and changed the style name, latex
> name and label name to uncover. see the attached file.
>

Sorry, I now realize that you probably meant that lyx starts a new
paragraph in the GUI when starting an environment and not in the latex code
nor the pdf output.

>
>
-- 
>> 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: Starting new environment in the middle of a line

[Udicoudco]

On Wed, Nov 9, 2022 at 7:16 PM Scott Kostyshak 
wrote:

> Sometimes (but not too often), I want to start an environment in the
> middle of a line.
>
> In LaTeX, it seems to work fine, although I don't know if this is
> considered bad practice. But in LyX, we can only start an environment at
> the beginning of a paragraph I believe.
>

To my knowledge lyx starts  a new line with nested environments in the
latex code, but that should not start a new paragraph, unless the latex
environment   is forcing you to start a new paragraph with \par or a
similar command.


> Attached is an example in LyX that uses ERT. I haven't actually
> implemented this environment in LyX yet (I'm still planning to). Sometimes
> I can use the \uncover command, but other times I prefer an environment.
>
> I also attach an example .tex file with an environment that is implemented
> in LyX (block). I attach the example as a .tex file (example-block.tex),
> and the imported .lyx file (example-block-imported.23.lyx). LyX makes a
> paragraph break and then nests the environment. This causes a linebreak
> that I don't want in the corresponding PDF.
>

I think that the differences in the output PDF are coming from using the
block environment with the non ERT version and the uncover environment in
the file with the ERT (note that also the .tex files produces the same pdf
as example-block-imported.23.lyx)

To check my suspicion I've tried to see if using uncover as a style layout
in lyx will cause this problem. To do so I copied the block layout from the
beamer.layout file to the local layout and changed the style name, latex
name and label name to uncover. see the attached file.

Regards,
Udi

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


example-uncoverenv.23.lyx
Description: application/lyx
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Udicoudco]

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
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Add support for \Nameref alongside \NameRef

[Udicoudco]

On Mon, Oct 3, 2022 at 1:19 AM madmurphy  wrote:
>
> Hi Udi,
>
> I was mistaken because LyX shows it as NameRef: chap:duis-feugiat-facilisis, 
> but in reality the example attached, if exported to LaTeX, uses \nameref{...} 
> (all lowercase). What I often find more useful however is \Nameref{...} (with 
> a capital “N”) – you can find it too in the example attached (no need to 
> include packages).
>
> --madmurphy

Hi madmurphy,

I've attached two files that can solve this problem with one line of
code in the preamble of the documents (in one of the attachments it's
four lines), I hope it will help.

I think that to add a support for \Nameref would be  a bit
problematic, as it's definition contains the words "on page"
explicitly, independently of the main language of the document, which
can cause unexpected results for some LyX users (especially if the
main language is a RTL language, which will cause \Nameref to output
"page on" instead of "on page").

It might be possible to define a new, rather similar command, say
\lyxNameref, that is defined as

   \newcommand\lyxNameref#1{`\nameref{#1}' \lyxonpage~\pageref{#1}}

where LyX should define \lyxpageon depending on the language the
reference is written on.

There might be another problem concerning the quotation marks in this
definition, as some languages use different quotation marks (for
instance, I usually use a Hebrew font that does not contain the glyph
`, so I would get an error using \Nameref).

Best Regards,
Udi
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel


nameref_example_ref.lyx
Description: application/lyx


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

Re: Add support for \Nameref alongside \NameRef

[Udicoudco]

On Fri, Sep 23, 2022 at 3:32 PM madmurphy  wrote:
>
> LyX allows to use \NameRef for referencing labels. However most of the times 
> I find \Nameref (with a lowercase “r”) more useful, and so I end up manually 
> writing \Nameref{...} in a LaTeX box in a LyX document (which has the 
> inconvenient that the argument is not automatically synchronized if for any 
> reason I rename the label).
>
> Would it be possible to add \Nameref to the list of LyX supported referencing 
> systems?
>
> --madmurphy

Hi,

I do not know the command \NameRef and did not find any reference to
it on the internet. I checked all the referencing formats in
LyX2.3.6.1 and it seems that LyX supports the command \nameref (but on
the GUI the label is titled with NameRef:) that is provided by the
nameref package.

To solve your query, you can write

\usepackage{nameref}
 \AtBeginDocument{\let\ref\Nameref}

in the preamble, and use the default referencing format. If you use
the \ref command in your document, you can "sacrifice" a different
format that lyx supports, but not \nameref or \pageref, as \Nameref
uses those.

Note that the \AtBeginDocument is important because hyperref might be
changing the ref command at the beginning of the document as well (to
my  knowledge it defines \autoref at the beginning of  the document, I
did not check about \ref), also, if hyperref is loaded there is no
need to load nameref, as hyperref loads it internally.

Regards,
Udi
> 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: old lyx document in lyx 2.3.6 doesn't compile

[Udicoudco]

On Fri, Sep 16, 2022 at 10:48 AM Jean-Marc Lasgouttes 
wrote:
>
> Le 14/09/2022 à 19:16, Csikos Bela a écrit :
> > Hello:
> >
> > I have an old document I made in lyx 2.0. Lyx 2.3.6.1 opens is but
> > interprets the code incorrectly and gives compilation error:
>
> Hello,
>
> Could you please create a ticket in trac? I can confirm that the file
> does not typeset in 2.4.0dev either.
>
> JMarc

Hi,

It seems that the problem, in this case, comes from the fact that argument
insets do not inherit the language settings of the layout, so lyx adds
"\foreignlanguage{english}" to the argument in the latex code, and enumitem
does not recognize it as a key.  See the difference in the output tex files:

> > In lyx 2.0 the latex code is:
> >
> > \selectlanguage{magyar}%
> > \begin{enumerate}[nosep]
> > \inputencoding{latin2}%
> > \item Első item.\inputencoding{latin9}\foreignlanguage{english}{}\\
> > \foreignlanguage{english}{First item. }\selectlanguage{english}%
> > \end{enumerate}
> >
> > Opening the file in lyx 2.3.6.1 latex code is:
> >
> > \selectlanguage{magyar}%
> > \begin{enumerate}[\foreignlanguage{english}{nosep}]
> > \inputencoding{latin2}%
> > \item Első item.\inputencoding{latin9}\foreignlanguage{english}{}\\
> > \foreignlanguage{english}{First item. }\selectlanguage{english}%
> > \end{enumerate}

But, even if argument insets would inherit language settings, if i would
use a language that does not use the latin letters, such as hebrew, arabic,
etc., I would have to switch to english in the argument inset, and lyx
would add some language code to handle this.

Because of that, I think the proper solution would be to add to the
argument insets the PassThru tag, which will inforce lyx to not change what
written in the argument (this is especially important when using key-value
syntax, as in this case).

I've also mentioned a similar problem, regarding the Named Theorems module,
here .
After setting the PassThru tag to true, it solved the problem.

It might be wise to check if this problem occurs in other modules.

Best Regards,
Udi
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Differences Between Theorems Modules (AMS and non AMS)

[Udicoudco]

Hi,

I've tried to make a patch with all mentioned changes, and a new theorem
module that defines theorems via thmtools (so that we could use
\listoftheorems).

The patch has been sent   there
<https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg218068.html>.
Should I also send it here?

Regards udi


On Tue, Sep 20, 2022 at 5:18 AM Udicoudco  wrote:

> On Thu, Sep 15, 2022 at 6:50 PM Jean-Marc Lasgouttes 
> wrote:
> >
> > Le 15/09/2022 à 14:17, Udicoudco a écrit :
> > > Hello again,
> > >
> > > I took a look at the Named Theorems Module today, and the LaTeX code
> > > there seems to be a bit strange. In the preamble of the layout Named
> > > Theorem there is the following code:
> > >
> > >  \newcommand\thmsname{\protect\theoremname}
> > >  \newcommand\nm@thmtype{theorem}
> > >  \theoremstyle{plain}
> > >  \newtheorem*{namedtheorem}{\thmsname}
> > >  \newenvironment{namedthm}[1][Undefined Theorem Name]{
> > >\ifx{#1}{Undefined Theorem Name}\renewcommand\nm@thmtype
> {theorem*}
> > >\else\renewcommand\thmsname{#1}\renewcommand\nm@thmtype
> {namedtheorem}
> > >\fi
> > >\begin{\nm@thmtype}}
> > >{\end{\nm@thmtype}}
> >
> > Hi again Udi,
> >
> > This module has been proposed in ticket 6279
> > https://www.lyx.org/trac/ticket/6279
> >
> > Updating and fixing it would be great. I think that the LabelString
> > could be empty, so that it is clear that the argument inset will be used
> > as a label. And the default could be set to "theorem", for example.
> >
> > Feel free to propose a replacement.
> >
> > JMarc
> >
>
> Hi,
>
> I've attached a new implementation of the Named Theorems module. It
> should be noted that the argument inset currently has the tag PassThru
> on true, other wise when writing a theorem in a different language
> from the main language of the document, if the argument inset is left
> "empty", lyx actually insert there a code to set the language of the
> inset as the main language, so the output label looks empty.
>
> Another solution would be to delete the inset in this case (which will
> make TeX see the input as empty), but IMO the former solution is
> better. Feel free to change that.
>
> Regards,
> Udi
>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[Udicoudco]

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

Hello Thibaut ,

>
>
> @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.

I've decided to try and build the master, as I wanted to fix some
modules as discussed here. I've followed the instructions on the LyX
"How To Use Git" page and I believe everything went fine (as this is
my first time, i'm not sure).
I've added the docbook tags to my module (But i did not know what
should be in the List of Theorems, if any), tested DocBook export, and
it seems to work.

>
> 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 :).

I've added a file, with a name you suggested, containing all the
layouts defined in the module, and It's exported to DocBook.

Best regards,
Udi

On Tue, Sep 20, 2022 at 11:31 PM Thibaut Cuvelier  wrote:
>
> 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
<>
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: New Theorems Module

[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?
Also, could you care to explain what is the purpose of the new tags i
saw in the master (DocBookWrapperTag, DocBookTag, DocBookAttr)? 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?)

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

Re: New Theorems Module

[Udicoudco]

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


theorems-thmtools.module
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Differences Between Theorems Modules (AMS and non AMS)

[Udicoudco]

On Thu, Sep 15, 2022 at 6:50 PM Jean-Marc Lasgouttes  wrote:
>
> Le 15/09/2022 à 14:17, Udicoudco a écrit :
> > Hello again,
> >
> > I took a look at the Named Theorems Module today, and the LaTeX code
> > there seems to be a bit strange. In the preamble of the layout Named
> > Theorem there is the following code:
> >
> >  \newcommand\thmsname{\protect\theoremname}
> >  \newcommand\nm@thmtype{theorem}
> >  \theoremstyle{plain}
> >  \newtheorem*{namedtheorem}{\thmsname}
> >  \newenvironment{namedthm}[1][Undefined Theorem Name]{
> >\ifx{#1}{Undefined Theorem Name}\renewcommand\nm@thmtype{theorem*}
> >\else\renewcommand\thmsname{#1}\renewcommand\nm@thmtype{namedtheorem}
> >\fi
> >\begin{\nm@thmtype}}
> >{\end{\nm@thmtype}}
>
> Hi again Udi,
>
> This module has been proposed in ticket 6279
> https://www.lyx.org/trac/ticket/6279
>
> Updating and fixing it would be great. I think that the LabelString
> could be empty, so that it is clear that the argument inset will be used
> as a label. And the default could be set to "theorem", for example.
>
> Feel free to propose a replacement.
>
> JMarc
>

Hi,

I've attached a new implementation of the Named Theorems module. It
should be noted that the argument inset currently has the tag PassThru
on true, other wise when writing a theorem in a different language
from the main language of the document, if the argument inset is left
"empty", lyx actually insert there a code to set the language of the
inset as the main language, so the output label looks empty.

Another solution would be to delete the inset in this case (which will
make TeX see the input as empty), but IMO the former solution is
better. Feel free to change that.

Regards,
Udi


theorems-named.module
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel