Re: [RFC Riki!] Re: Highlighted math in dark mode is hard to see

2023-09-29 Thread Richard Kimberly Heck

On 9/29/23 15:22, Scott Kostyshak wrote:

On Fri, Sep 29, 2023 at 08:30:14PM +0200, Jean-Marc Lasgouttes wrote:

Le 29/09/2023 à 15:53, Jürgen Spitzmüller a écrit :

Am Freitag, dem 29.09.2023 um 15:11 +0200 schrieb Jürgen Spitzmüller:

Or maybe introduce a Color_selectionmath. I think this could be
easily implemented for 2.4 without having to fear collateral effects.

Like this. Involves a new string, tough. And it only works for fully
selected math insets, not for parts of it. Don't know where to set the
latter.


If it's really critical, it's OK to go ahead. We haven't frozen yet.

Riki


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


Re: [RFC Riki!] Re: Boder of Frame inset not visible in dark mode

2023-09-29 Thread Richard Kimberly Heck

On 9/29/23 08:29, Jürgen Spitzmüller wrote:

Am Sonntag, dem 24.09.2023 um 22:24 +0200 schrieb Dan:

Hello,

PROBLEM

There is a frame whose outline is not visible in dark mode because it
is black (Insert > Frame > Simple Frame).
The box inset name is "Boxed"
(https://www.lyx.org/trac/browser/lyxgit/lib/layouts/stdinsets.inc#L5
04).

See the attached image for a showcase of all the frames showing the
problem.

EXPECTED BEHAVIOUR
===
Simple Frame Box should have the same outline colour as the other
frames.

The attached patch fixes it and also resolves a regression in master
with non-default frame color and default background color.

But it's a file format change, so Riki needs to decide on whether it
qualifies as urgent enough.


Go ahead, it looks important.

Riki


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


Re: redundant cprotect's

2023-09-29 Thread 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


Re: [RFC Riki!] Re: Highlighted math in dark mode is hard to see

2023-09-29 Thread Scott Kostyshak
On Fri, Sep 29, 2023 at 08:30:14PM +0200, Jean-Marc Lasgouttes wrote:
> Le 29/09/2023 à 15:53, Jürgen Spitzmüller a écrit :
> > Am Freitag, dem 29.09.2023 um 15:11 +0200 schrieb Jürgen Spitzmüller:
> > > Or maybe introduce a Color_selectionmath. I think this could be
> > > easily implemented for 2.4 without having to fear collateral effects.
> > 
> > Like this. Involves a new string, tough. And it only works for fully
> > selected math insets, not for parts of it. Don't know where to set the
> > latter.
> 
> How can I switch to dark mode. Switching Ubuntu to dark mode does not seem
> to be enough and I did not find the switch in our prefs.

I recently joined the dark side also. Pavel put up some helpful notes
here that I followed:

  https://wiki.lyx.org/Tips/ColorSchemes

Basically, run qt5ct to make the setting (for "Color Scheme" I chose
"darker"), and then to make LyX (Qt) use those, settings, before you run
LyX, do:

  export QT_QPA_PLATFORMTHEME=qt5ct

For example, you could put that in your ~/.profile (although I don't
know what is recommended).

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [RFC Riki!] Re: Highlighted math in dark mode is hard to see

2023-09-29 Thread Jean-Marc Lasgouttes

Le 29/09/2023 à 15:53, Jürgen Spitzmüller a écrit :

Am Freitag, dem 29.09.2023 um 15:11 +0200 schrieb Jürgen Spitzmüller:

Or maybe introduce a Color_selectionmath. I think this could be
easily implemented for 2.4 without having to fear collateral effects.


Like this. Involves a new string, tough. And it only works for fully
selected math insets, not for parts of it. Don't know where to set the
latter.


How can I switch to dark mode. Switching Ubuntu to dark mode does not 
seem to be enough and I did not find the switch in our prefs.


JMarc

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


Re: [RFC Riki!] Re: Highlighted math in dark mode is hard to see

2023-09-29 Thread Daniel

On 2023-09-29 15:53, Jürgen Spitzmüller wrote:

Am Freitag, dem 29.09.2023 um 15:11 +0200 schrieb Jürgen Spitzmüller:

Or maybe introduce a Color_selectionmath. I think this could be
easily implemented for 2.4 without having to fear collateral effects.


Like this. Involves a new string, tough. And it only works for fully
selected math insets, not for parts of it. Don't know where to set the
latter.


As for the latter problem, this one might be related: #12692.

Daniel


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


Re: [RFC Riki!] Re: Highlighted math in dark mode is hard to see

2023-09-29 Thread Jean-Marc Lasgouttes

Le 29/09/2023 à 15:53, Jürgen Spitzmüller a écrit :

Am Freitag, dem 29.09.2023 um 15:11 +0200 schrieb Jürgen Spitzmüller:

Or maybe introduce a Color_selectionmath. I think this could be
easily implemented for 2.4 without having to fear collateral effects.


Like this. Involves a new string, tough. And it only works for fully
selected math insets, not for parts of it. Don't know where to set the
latter.


What makes you think that it is safer to introduce a new color ? Or is 
it just for symmetry with text ?


JMarc

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

2023-09-29 Thread Scott Kostyshak
On Fri, Sep 29, 2023 at 05:01:07PM +0200, Jürgen Spitzmüller wrote:
> Am Freitag, dem 29.09.2023 um 10:42 -0400 schrieb Scott Kostyshak:
> > Thanks, done at 46a62573.
> > 
> > If I understand correctly, Udi suggested an additional change, which
> > was
> > replacing
> > 
> >   \addto\shorthandsspanish{\spanishdeactivate{~<>}}
> > 
> > with:
> > 
> >   \addto\shorthandsspanish{\spanishdeactivate{~}}
> 
> Yes, that's possible (as \deactivatequoting also deactivates <>, but
> not strictly necessary.

OK, since I don't understand this much I'll leave it as is.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Fix compilation of es/Letter standard class

2023-09-29 Thread Scott Kostyshak
On Fri, Sep 29, 2023 at 05:03:31PM +0200, Jürgen Spitzmüller wrote:
> Am Freitag, dem 29.09.2023 um 10:40 -0400 schrieb Scott Kostyshak:
> > I believe we set "Always Babel" for some reason in the Spanish
> > documents. It would be nice to set it to Automatic (or Default, I
> > forget
> > which is recommended). Should I try to do that and see how the tests
> > go,
> > and check the diffpdf to look at the appearance?
> 
> Yes, sure. Would be good if such special-casing was no longer needed.

Sounds good, I'll add this to my todo list (if anyone wants to look at
it before, please go ahead!).

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Fix compilation of es/Letter standard class

2023-09-29 Thread Jürgen Spitzmüller
Am Freitag, dem 29.09.2023 um 10:40 -0400 schrieb Scott Kostyshak:
> I believe we set "Always Babel" for some reason in the Spanish
> documents. It would be nice to set it to Automatic (or Default, I
> forget
> which is recommended). Should I try to do that and see how the tests
> go,
> and check the diffpdf to look at the appearance?

Yes, sure. Would be good if such special-casing was no longer needed.

-- 
Jürgen


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


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

2023-09-29 Thread Jürgen Spitzmüller
Am Freitag, dem 29.09.2023 um 10:42 -0400 schrieb Scott Kostyshak:
> Thanks, done at 46a62573.
> 
> If I understand correctly, Udi suggested an additional change, which
> was
> replacing
> 
>   \addto\shorthandsspanish{\spanishdeactivate{~<>}}
> 
> with:
> 
>   \addto\shorthandsspanish{\spanishdeactivate{~}}

Yes, that's possible (as \deactivatequoting also deactivates <>, but
not strictly necessary.



-- 
Jürgen


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


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

2023-09-29 Thread Scott Kostyshak
On Fri, Sep 29, 2023 at 12:42:33PM +0200, Jürgen Spitzmüller wrote:
> Am Samstag, dem 23.09.2023 um 12:37 -0400 schrieb Scott Kostyshak:
> > Jürgen, do you have time/interest to take a look?
> 
> The way to go, I think, is (as Udi suggested), the attached.

Thanks, done at 46a62573.

If I understand correctly, Udi suggested an additional change, which was
replacing

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

with:

  \addto\shorthandsspanish{\spanishdeactivate{~}}

I don't understand any of this, so if that additional change makes
sense, please commit.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Fix compilation of es/Letter standard class

2023-09-29 Thread Scott Kostyshak
On Fri, Sep 29, 2023 at 12:40:29PM +0200, Jürgen Spitzmüller wrote:
> Am Sonntag, dem 24.09.2023 um 01:21 +0200 schrieb Scott Kostyshak:
> > commit fa67f70992da5f7c6cb0958d557993d6c0750534
> > Author: Scott Kostyshak 
> > Date:   Sat Sep 23 20:35:36 2023 -0400
> > 
> >     Fix compilation of es/Letter standard class
> >     
> >     The problem, described by Udi, was the following:
> >     
> >   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.
> >     
> >     Patch from Dan.
> 
> I don't think hardcoding a language package is the way to go. This is
> hardly transparent to the users. Also, we need a more general solution
> beyond this very template.

Thanks for taking a look. Done at 46a62573.

I believe we set "Always Babel" for some reason in the Spanish
documents. It would be nice to set it to Automatic (or Default, I forget
which is recommended). Should I try to do that and see how the tests go,
and check the diffpdf to look at the appearance? I think we might have
taken a look at this a while ago but for some reason didn't make the
change. I forget. But maybe with my ctesting and your expert knowledge
and Dan's Spanish, now is a good time to try to make this change?

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


[RFC Riki!] Re: Highlighted math in dark mode is hard to see

2023-09-29 Thread Jürgen Spitzmüller
Am Freitag, dem 29.09.2023 um 15:11 +0200 schrieb Jürgen Spitzmüller:
> Or maybe introduce a Color_selectionmath. I think this could be
> easily implemented for 2.4 without having to fear collateral effects.

Like this. Involves a new string, tough. And it only works for fully
selected math insets, not for parts of it. Don't know where to set the
latter.

-- 
Jürgen
diff --git a/src/Color.cpp b/src/Color.cpp
index 3b9e68ebd1..23e40a9c94 100644
--- a/src/Color.cpp
+++ b/src/Color.cpp
@@ -264,6 +264,7 @@ ColorSet::ColorSet()
 	{ Color_background, N_("background"), "background", Linen, black, "background" },
 	{ Color_foreground, N_("text"), "foreground", black, Linen, "foreground" },
 	{ Color_selection, N_("selection"), "selection", "#add8e6", "#add8e6", "selection" },
+	{ Color_selectionmath, N_("selected math"), "selectionmath", "#8B", "#8B", "selectionmath" },
 	{ Color_selectiontext, N_("selected text"), "selectiontext", black, black, "selectiontext" },
 	{ Color_latex, N_("LaTeX text"), "latex", DarkRed, "#D66613", "latex" },
 	{ Color_textlabel1, N_("Text label 1"), "textlabel1", blue, "#86a4ff", "textlabel1" },
diff --git a/src/ColorCode.h b/src/ColorCode.h
index 3439c28727..9b26e7219c 100644
--- a/src/ColorCode.h
+++ b/src/ColorCode.h
@@ -65,6 +65,8 @@ enum ColorCode {
 	Color_foreground,
 	/// Background color of selected text
 	Color_selection,
+	/// Foreground color of selected math
+	Color_selectionmath,
 	/// Foreground color of selected text
 	Color_selectiontext,
 	/// Text color in LaTeX mode
diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index d2c2159167..9415200f2f 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -697,8 +697,9 @@ void InsetMathHull::draw(PainterInfo & pi, int x, int y) const
 	}
 
 	// Then the equations
-	ColorCode color = pi.selected && lyxrc.use_system_colors
-		? Color_selectiontext : standardColor();
+	ColorCode color = pi.selected
+		? (lyxrc.use_system_colors ? Color_selectiontext : Color_selectionmath)
+		: standardColor();
 	bool const really_change_color = pi.base.font.color() == Color_none;
 	Changer dummy0 = really_change_color ? pi.base.font.changeColor(color)
 		: noChange();

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


Re: Highlighted math in dark mode is hard to see

2023-09-29 Thread Jürgen Spitzmüller
Am Samstag, dem 23.09.2023 um 21:21 +0200 schrieb Daniel:
> Is there a reason why the "selected text" color is not applied to
> maths? 
> Changing that would solve the problem since this color is visible on
> a 
> "selection" background. (I guess that is its point.)

Or maybe introduce a Color_selectionmath. I think this could be easily
implemented for 2.4 without having to fear collateral effects.

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


[RFC Riki!] Re: Boder of Frame inset not visible in dark mode

2023-09-29 Thread Jürgen Spitzmüller
Am Sonntag, dem 24.09.2023 um 22:24 +0200 schrieb Dan:
> Hello,
> 
> PROBLEM
> 
> There is a frame whose outline is not visible in dark mode because it
> is black (Insert > Frame > Simple Frame).
> The box inset name is "Boxed"
> (https://www.lyx.org/trac/browser/lyxgit/lib/layouts/stdinsets.inc#L5
> 04).
> 
> See the attached image for a showcase of all the frames showing the
> problem.
> 
> EXPECTED BEHAVIOUR
> ===
> Simple Frame Box should have the same outline colour as the other
> frames.

The attached patch fixes it and also resolves a regression in master
with non-default frame color and default background color.

But it's a file format change, so Riki needs to decide on whether it
qualifies as urgent enough.

> 
> 
> Daniel.
> --
> Enviat amb Tutanota.

-- 
Jürgen
diff --git a/development/FORMAT b/development/FORMAT
index 1711f88c78..29774522a4 100644
--- a/development/FORMAT
+++ b/development/FORMAT
@@ -7,6 +7,10 @@ changes happened in particular if possible. A good example would be
 
 ---
 
+2023-09-29 Jürgen Spitzmüller  
+	* Format incremented to 620: InsetBox default framecolor is now "foreground"
+	  rather than "black". This aligns better with dark mode.
+
 2023-09-06 Richard Kimberly Heck 
 	* Format incremented to 619: New document header \use_formatted_ref
 	  for workarea display purposes only.
diff --git a/lib/lyx2lyx/lyx_2_4.py b/lib/lyx2lyx/lyx_2_4.py
index 4cc5fe5bdf..cc350e1463 100644
--- a/lib/lyx2lyx/lyx_2_4.py
+++ b/lib/lyx2lyx/lyx_2_4.py
@@ -5554,6 +5554,21 @@ def revert_formatted_refs(document):
 del document.header[i]
 
 
+def revert_box_fcolor(document):
+i = 0
+while True:
+i = find_token(document.body, '\\begin_inset Box Boxed', i+1)
+if i == -1:
+break
+j = find_end_of_inset(document.body, i)
+if j == -1:
+document.warning("Malformed LyX document: Can't find end of framed box inset at line %d" % i)
+continue
+k = find_token(document.body, 'framecolor "foreground"', i, j)
+if k != -1:
+document.body[k] = 'framecolor "black"'
+
+
 ##
 # Conversion hub
 #
@@ -5634,11 +5649,13 @@ convert = [
[616, [convert_empty_macro]],
[617, [convert_cov_options]],
[618, []],
-   [619, []]
+   [619, []],
+   [620, []]
   ]
 
 
-revert =  [[618, [revert_formatted_refs]],
+revert =  [[619, [revert_box_fcolor]],
+   [618, [revert_formatted_refs]],
[617, [revert_hequotes]],
[616, [revert_expreambles,revert_exarg2,revert_linggloss2,revert_cov_options]],
[615, [revert_empty_macro]],
diff --git a/src/frontends/qt/GuiBox.cpp b/src/frontends/qt/GuiBox.cpp
index bda71a68ef..8cd634d27f 100644
--- a/src/frontends/qt/GuiBox.cpp
+++ b/src/frontends/qt/GuiBox.cpp
@@ -133,6 +133,8 @@ GuiBox::GuiBox(QWidget * parent) : InsetParamsWidget(parent)
 	connect(shadowsizeED, SIGNAL(textChanged(QString)), this, SIGNAL(changed()));
 	connect(shadowsizeUnitsLC, SIGNAL(selectionChanged(lyx::Length::UNIT)),
 		this, SIGNAL(changed()));
+	connect(frameColorCO, SIGNAL(currentIndexChanged(int)),
+		this, SIGNAL(changed()));
 	connect(backgroundColorCO, SIGNAL(currentIndexChanged(int)),
 		this, SIGNAL(changed()));
 
@@ -159,15 +161,18 @@ GuiBox::GuiBox(QWidget * parent) : InsetParamsWidget(parent)
 }
 
 
-void GuiBox::fillComboColor(QComboBox * combo, bool const is_none)
+void GuiBox::fillComboColor(QComboBox * combo, bool const is_background)
 {
 	combo->clear();
 	QPixmap coloritem(32, 32);
 	QColor color;
-	// frameColorCO cannot be uncolored
-	if (is_none)
+	// condition on the two possible types
+	if (is_background)
 		combo->addItem(toqstr(translateIfPossible(lcolor.getGUIName(Color_none))),
 			   toqstr(lcolor.getLaTeXName(Color_none)));
+	else
+		combo->addItem(toqstr(translateIfPossible(lcolor.getGUIName(Color_foreground))),
+			   toqstr(lcolor.getLaTeXName(Color_foreground)));
 	QList::const_iterator cit = color_codes_.begin();
 	for (; cit != color_codes_.end(); ++cit) {
 		QString const latexname = toqstr(lcolor.getLaTeXName(*cit));
@@ -215,32 +220,6 @@ void GuiBox::on_typeCO_activated(int index)
 			widthCB->setChecked(itype != "none");
 		pagebreakCB->setChecked(false);
 	}
-	// assure that the frame color is black for frameless boxes to
-	// provide the color "none"
-	int const b = frameColorCO->findData("black");
-	if (frameless && frameColorCO->currentIndex() != b)
-		frameColorCO->setCurrentIndex(b);
-	changed();
-}
-
-
-void GuiBox::on_frameColorCO_currentIndexChanged(int index)
-{
-	// if there is a non-black frame color the background cannot be uncolored
-	// therefore remove the entry "none" in this case
-	int const n = backgroundColorCO->findData("none");
-	if (index != frameColorCO->findData("black")) {
-		if (n != -1) {
-			if (backgroundColorCO->currentIndex() == n)
-backgroundColorCO->setCurrentIndex(
-	backgrou

LyX can no longer be compiled under macOS Sonoma 14.0 and Qt 6.5

2023-09-29 Thread Christoph Schmitz
Hi all,

I have been compiling LyX for a while now. A few weeks ago, I encountered a 
problem where LyX could no longer be compiled. I didn't report this issue at 
the time because I was using a beta version of macOS. However, now that macOS 
Sonoma has been officially released and the error still persists, I want to 
report this issue.

I am running macOS Sonoma 14.0 (23A344) on a 2018 13" MacBook Pro (2,7 GHz 
Quad-Core Intel Core i7, Intel Iris Plus Graphics 655 1536 MB, 16 GB 2133 MHz 
LPDDR3). Qt is installed via homebrew. The current version of Qt is 6.5.1.

I have enclosed the log file, which includes the ./configure command I use.

Best,
Chris

./configure \
--with-version-suffix=-2.4 \
--prefix=/Users/chris/Desktop/LyX.app \
--with-x=no \
--disable-stdlib-debug \
--with-included-hunspell \
--enable-qt6 \
--with-qt-dir=/usr/local/opt/qt \
--with-macos-deployment-target=13.0

configuring LyX version 2.4.0~RC1.devel
checking for build type... development
checking for version suffix... -2.4
checking whether Qt6 is requested... yes
checking build system type... x86_64-apple-darwin23.0.0
checking host system type... x86_64-apple-darwin23.0.0
checking target system type... x86_64-apple-darwin23.0.0
checking what packaging should be used... macosx
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... yes
checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether UID '501' is supported by ustar format... yes
checking whether GID '20' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking for a Python interpreter with version >= 2.7.0 or 3.5.0... python3
checking for python3... /usr/bin/python3
checking for python version... 3.9
checking for python platform... darwin
checking for GNU default python prefix... ${prefix}
checking for GNU default python exec_prefix... ${exec_prefix}
checking for python script directory (pythondir)... 
${PYTHON_PREFIX}/lib/python3.9/site-packages
checking for python extension module directory (pyexecdir)... 
${PYTHON_EXEC_PREFIX}/lib/python3.9/site-packages
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for ranlib... ranlib
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking whether the compiler is clang... yes
checking for clang version... 15.0.0
checking for a good C++ mode... -std=c++17
checking whether STL is libstdc++... no
checking whether STL is libstdc++ using the C++11 ABI... no
checking for std::call_once availability... yes
checking whether C++ compiler accepts -Wdeprecated-copy... yes
checking for gcc... gcc
checking whether the compiler supports GNU Objective C... yes
checking whether gcc accepts -g... yes
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking for main in -lole32... no
checking whether to use included nod library... yes
checking whether to use included boost library... no
checking for boost library... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for sys/select.h... yes
checking for sys/socket.h... yes
checking whether byte ordering is bigendian... no
checking whether printing callstack is possible... (cached) yes
checking whether make_unique is defined by header memory... yes
checking size of wchar_t... 4
checking for wchar_t... yes
checking for unsigned long long int... yes
checking for long long int... yes
checking for grep that 

Re: BUG: changing quotes from context menu does not work

2023-09-29 Thread Jürgen Spitzmüller
Am Sonntag, dem 24.09.2023 um 05:49 +0200 schrieb Dan:
> I think I have a patch for this (see the attachment).
> The context menu is created in src/frontends/qt/Menus.cpp and the
> command binded to that menu item is actually using the global quoting
> style, not the language default's (at the cursor position).
> 
> I have tested it and works, use the LyX file I attached in my
> previous e-mail as a test.

Thanks, that seems correct. Committed.

-- 
Jürgen
-- 
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)

2023-09-29 Thread Jürgen Spitzmüller
Am Samstag, dem 23.09.2023 um 12:37 -0400 schrieb Scott Kostyshak:
> Jürgen, do you have time/interest to take a look?

The way to go, I think, is (as Udi suggested), the attached.

-- 
Jürgen
diff --git a/lib/languages b/lib/languages
index 315707742b..a027a430b8 100644
--- a/lib/languages
+++ b/lib/languages
@@ -1438,6 +1438,7 @@ Language spanish
 	LangCode es_ES
 	PostBabelPreamble
 	\addto\shorthandsspanish{\spanishdeactivate{~<>}}
+	\deactivatequoting
 	EndPostBabelPreamble
 End
 
@@ -1454,6 +1455,7 @@ Language spanish-mexico
 	LangCode es_MX
 	PostBabelPreamble
 	\addto\shorthandsspanish{\spanishdeactivate{~<>.}}
+	\deactivatequoting
 	EndPostBabelPreamble
 End
 


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Fix compilation of es/Letter standard class

2023-09-29 Thread Jürgen Spitzmüller
Am Sonntag, dem 24.09.2023 um 01:21 +0200 schrieb Scott Kostyshak:
> commit fa67f70992da5f7c6cb0958d557993d6c0750534
> Author: Scott Kostyshak 
> Date:   Sat Sep 23 20:35:36 2023 -0400
> 
>     Fix compilation of es/Letter standard class
>     
>     The problem, described by Udi, was the following:
>     
>   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.
>     
>     Patch from Dan.

I don't think hardcoding a language package is the way to go. This is
hardly transparent to the users. Also, we need a more general solution
beyond this very template.

-- 
Jürgen


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel