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
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
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
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
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
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
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
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
>
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
> >
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"
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
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
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:
>
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
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
> >
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
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.
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
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
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
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
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
25 matches
Mail list logo
