There are several ru/UserGuide ctests failing on current master, including the
default output (pdflatex).
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 1/21/21 10:10 AM, Pavel Sanda wrote:
On Thu, Jan 21, 2021 at 09:51:46AM -0500, Scott Kostyshak wrote:
On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote:
Please review my recent patches for LyX.
Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class.
Patch 4
On 1/21/21 5:59 PM, Andrew Parsloe wrote:
On 22/01/2021 11:06 am, Paul A. Rubin wrote:
On 1/21/21 4:44 PM, Richard Kimberly Heck wrote:
On 1/21/21 3:07 PM, Paul A. Rubin wrote:
I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a
possible (minor) bug that I'd like someone to confirm
On 22/01/2021 11:06 am, Paul A. Rubin wrote:
On 1/21/21 4:44 PM, Richard Kimberly Heck wrote:
On 1/21/21 3:07 PM, Paul A. Rubin wrote:
I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a
possible (minor) bug that I'd like someone to confirm. Create a math
inset and click the toolba
On 1/21/21 4:44 PM, Richard Kimberly Heck wrote:
On 1/21/21 3:07 PM, Paul A. Rubin wrote:
I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a
possible (minor) bug that I'd like someone to confirm. Create a math
inset and click the toolbar button to insert paired delimiters. The
lflo
On Thu, 21 Jan 2021 at 19:23, Kornel Benko wrote:
> Am Thu, 21 Jan 2021 18:26:38 +0100
> schrieb Thibaut Cuvelier :
>
> > Dear list, and Pavel mostly :)
> >
> > I'm starting again to configure LyX on Windows, and the CMake files do
> not behave as
> > expected.
> >
> > I am setting -DLYX_DEPENDEN
On 1/21/21 3:07 PM, Paul A. Rubin wrote:
I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a
possible (minor) bug that I'd like someone to confirm. Create a math
inset and click the toolbar button to insert paired delimiters. The
lfloor and rfloor delimiters look correct to me, but t
I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a possible
(minor) bug that I'd like someone to confirm. Create a math inset and
click the toolbar button to insert paired delimiters. The lfloor and
rfloor delimiters look correct to me, but the lceil and rceil delimiters
are just ve
Am Thu, 21 Jan 2021 18:26:38 +0100
schrieb Thibaut Cuvelier :
> Dear list, and Pavel mostly :)
>
> I'm starting again to configure LyX on Windows, and the CMake files do not
> behave as
> expected.
>
> I am setting -DLYX_DEPENDENCIES_DOWNLOAD=1 on the command line, but this is
> what it
> outp
On Thu, Jan 21, 2021 at 10:06:27AM -0500, Scott Kostyshak wrote:
> On Thu, Jan 21, 2021 at 09:05:43AM +0200, Yuriy Skalko wrote:
> > Yes, this is expected, since system libQt5*.so are dependent on libstdc++
> > (assuming you haven't rebuild Qt with libc++). ldd displays all required
> > libraries,
Dear list, and Pavel mostly :)
I'm starting again to configure LyX on Windows, and the CMake files do not
behave as expected.
I am setting -DLYX_DEPENDENCIES_DOWNLOAD=1 on the command line, but this is
what it outputs:
"C:\Program Files\JetBrains\CLion\bin\cmake\win\bin\cmake.exe"
-DCMAKE_BUILD_
On Thu, Jan 21, 2021 at 11:38:25AM -0500, Neal Becker wrote:
> In inserted graphics, we can select a page from a multi-page pdf using
> "latex and lyx options". This will show the correct graphics in the
> pdf output. But the preview always shows page 1. Would be nice to
> implement something to
In inserted graphics, we can select a page from a multi-page pdf using
"latex and lyx options". This will show the correct graphics in the
pdf output. But the preview always shows page 1. Would be nice to
implement something to fix the preview.
--
Those who don't understand recursion are doome
On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote:
> diff --git a/src/frontends/qt/DockView.h b/src/frontends/qt/DockView.h
> index 9c3a9e7460..1e7bd5f2db 100644
> --- a/src/frontends/qt/DockView.h
> +++ b/src/frontends/qt/DockView.h
> @@ -36,7 +36,7 @@ public:
>Qt::DockW
On Thu, Jan 21, 2021 at 09:51:46AM -0500, Scott Kostyshak wrote:
> On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote:
> > Please review my recent patches for LyX.
>
> Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class.
>
> Patch 4 also looks good. I thought it
Le 21/01/2021 à 08:38, Yuriy Skalko a écrit :
Please review my recent patches for LyX.
Concerning patch 1 and 5: what guideline do you use for using vector vs
list. The patches look good, I am just wondering.
Concerning patch 4: what does the replacement of 0 or nullptr by {} bring?
JMarc
-
On Thu, Jan 21, 2021 at 09:05:43AM +0200, Yuriy Skalko wrote:
> >
> > I've tried to reproduce on Linux with Clang and libc++ but cannot.
> > However, one thing that I do not understand is that in the output from
> > ldd, both libstdc++.so.6 and libc++.so.1 show up. See attached. Is this
> > expect
On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote:
> Please review my recent patches for LyX.
Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class.
Patch 4 also looks good. I thought it could break Qt 4.8 compilation but that's
not the case [1, 2].
Sorry that
Am Donnerstag, dem 21.01.2021 um 13:45 +0100 schrieb Jean-Marc
Lasgouttes:
> Hmm, what about
> code = Color_background;
> or
> code = colorset.getFromLyXName("background"):
>
> I agree 100% that this needs thinking, but my point is that the
> ColorCode is more important for LyX than the nam
Le 21/01/2021 à 10:48, Jürgen Spitzmüller a écrit :
How would that work with semantic branch names (e.g. \color
background)? Semantic branch names are essential to support branches
properly in different color themes.
Also, how would you export semantic color names in LaTeX (e.g.
\textcolor{notef
Am Donnerstag, dem 21.01.2021 um 10:41 +0100 schrieb Jean-Marc
Lasgouttes:
> Le 21/01/2021 à 09:55, Jürgen Spitzmüller a écrit :
> > Am Donnerstag, dem 21.01.2021 um 09:52 +0100 schrieb Jean-Marc
> > Lasgouttes:
> > > This is why IMO declaring a name for such colors is a mistake. An
> > > enum valu
Le 21/01/2021 à 09:55, Jürgen Spitzmüller a écrit :
Am Donnerstag, dem 21.01.2021 um 09:52 +0100 schrieb Jean-Marc
Lasgouttes:
This is why IMO declaring a name for such colors is a mistake. An
enum value generated on the fly would be enough.
And where would you store and access these enum valu
Am Donnerstag, dem 21.01.2021 um 09:55 +0100 schrieb Jürgen
Spitzmüller:
> Am Donnerstag, dem 21.01.2021 um 09:52 +0100 schrieb Jean-Marc
> Lasgouttes:
> > This is why IMO declaring a name for such colors is a mistake. An
> > enum value generated on the fly would be enough.
>
> And where would you
Am Donnerstag, dem 21.01.2021 um 09:52 +0100 schrieb Jean-Marc
Lasgouttes:
> This is why IMO declaring a name for such colors is a mistake. An
> enum value generated on the fly would be enough.
And where would you store and access these enum values?
(BTW the name now is as unique as it gets, as i
Le 21/01/2021 à 08:19, Jürgen Spitzmüller a écrit :
BTW if you want to have fun, fire up LyX 2.3.x, define a new branch
named "foreground" and see how all text (in all opened documents!)
magically disappears.
Amusing indeed :)
This is why IMO declaring a name for such colors is a mistake. An e
25 matches
Mail list logo