Le 6 février 2025 23:42:57 GMT+01:00, Thibaut Cuvelier a
écrit :
>commit 3d7d76f578aa48a6b2add2b75b779eebe001723f
>Author: Thibaut Cuvelier
>Date: Thu Feb 6 23:35:02 2025 +0100
>
>In MathStream, change MTag and family to use `str::string` instead of C
> strings.
>
Strings are frozen in stable.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
Am Sonntag, dem 18.08.2024 um 11:55 -0400 schrieb Richard Kimberly
Heck:
> Yes.
Thanks, all done.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 8/18/24 11:48 AM, Jürgen Spitzmüller wrote:
Am Sonntag, dem 18.08.2024 um 11:42 -0400 schrieb Richard Kimberly
Heck:
If Thibaut approves, so do I. He knows more about this now than I do.
OK, I'll put it to master.
Tell me if you're fine with backporting.
Yes.
Riki
--
lyx-devel mailing
Am Sonntag, dem 18.08.2024 um 11:42 -0400 schrieb Richard Kimberly
Heck:
> If Thibaut approves, so do I. He knows more about this now than I do.
OK, I'll put it to master.
Tell me if you're fine with backporting.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/
On 8/18/24 3:22 AM, Jürgen Spitzmüller wrote:
Am Samstag, dem 17.08.2024 um 19:40 -0400 schrieb Richard Kimberly
Heck:
No, not yet, but soon. Pleases let me know if there are any commits
you'd like to get into 2.4.x that might change strings before we do
freeze.
This is important enough for 2.4
Am Sonntag, dem 18.08.2024 um 09:22 +0200 schrieb Jürgen Spitzmüller:
> This is important enough for 2.4.2, and it all works well for me.
> Just
> waiting for Thibaut's and your feedback:
>
> https://www.lyx.org/trac/ticket/12372
And of course the patch with the string ch
Am Samstag, dem 17.08.2024 um 19:40 -0400 schrieb Richard Kimberly
Heck:
> No, not yet, but soon. Pleases let me know if there are any commits
> you'd like to get into 2.4.x that might change strings before we do
> freeze.
This is important enough for 2.4.2, and it all works well for me. Just
wai
No, not yet, but soon. Pleases let me know if there are any commits
you'd like to get into 2.4.x that might change strings before we do freeze.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Donnerstag, dem 01.08.2024 um 10:17 + schrieb Juergen
Spitzmueller:
> commit 7ac4e53e37d10dc2e4b99fc5527db366bcc504f4
> Author: Juergen Spitzmueller
> Date: Thu Aug 1 12:16:10 2024 +0200
>
> Disambiguate string
>
> At least in German "label&qu
Am Donnerstag, dem 27.06.2024 um 15:21 + schrieb Doc Who:
> there should be no double quotation marks in the second string there.
>
> Is this intentional? This has been working for many years. I cannot
> find anything about the wanted format in LyX documentation, though I
> be
abels"
is causing some troubles in LyX 2.4, and I see why - there should be no double
quotation marks in the second string there.
Is this intentional? This has been working for many years. I cannot find
anything about the wanted format in LyX documentation, though I believe I
modeled
On 2/26/24 16:04, Jean-Marc Lasgouttes wrote:
Le 26/02/2024 à 21:18, Richard Kimberly Heck a écrit :
On 2/26/24 09:24, Thibaut Cuvelier wrote:
commit 6b1441036f35767c0b60af510222ba792b17b829
Author: Thibaut Cuvelier
Date: Mon Feb 26 15:24:36 2024 +0100
Use C++11 string literals to
Le 26/02/2024 à 21:18, Richard Kimberly Heck a écrit :
On 2/26/24 09:24, Thibaut Cuvelier wrote:
commit 6b1441036f35767c0b60af510222ba792b17b829
Author: Thibaut Cuvelier
Date: Mon Feb 26 15:24:36 2024 +0100
Use C++11 string literals to make code easier to read.
I didn't know
On 2/26/24 09:24, Thibaut Cuvelier wrote:
commit 6b1441036f35767c0b60af510222ba792b17b829
Author: Thibaut Cuvelier
Date: Mon Feb 26 15:24:36 2024 +0100
Use C++11 string literals to make code easier to read.
I didn't know about those. I'd guess there are lots of places we c
5 and make sure that there aren't any issues there that need a string
> >>change. We're waiting at the moment for the Windows installer.
> >Riki, how do you evaluate the current status wrt the freeze?
> >
> >I might have some time in the next few weeks
Am Montag, dem 23.10.2023 um 06:16 +0200 schrieb Jürgen Spitzmüller:
> Thanks. So its the "pat" regex in qt_l10n (lyx_pot.py) that is to
> blame. Shouldn't be too hard to fix that to consider line breaks
> within ..., no?
Correcting myself after trying: \n in ui file strings do not seem to
work.
Am Sonntag, dem 22.10.2023 um 19:34 +0200 schrieb Enrico Forestieri:
> Instead of "" you can also use the entity "
". The
> difference
> is that this is directly replaced by lyx_pot.py to "\n" so that Qt
> will
> not use the html parser simply for introducing a newline char.
Thanks. So its the "
On Sun, Oct 22, 2023 at 01:22:05PM +0200, Jürgen Spitzmüller wrote:
Am Sonntag, dem 22.10.2023 um 12:33 +0200 schrieb Dan:
Just for the record and out of curiosity, what was the problem with
that string? I see you just added a line break HTML element to it,
and suddenly it appears in the POT
22 d’oct. de 2023, 13:21 per sa...@lyx.org:
> On Sun, Oct 22, 2023 at 01:06:58PM +0200, Dan wrote:
>
>> Sorry, I did not intend to mean or hint you all should wait until I am done.
>> The strings I noted as "problematic" are, in my opinion, not that important:
>> little type errors and improvab
Am Sonntag, dem 22.10.2023 um 12:33 +0200 schrieb Dan:
> Just for the record and out of curiosity, what was the problem with
> that string? I see you just added a line break HTML element to it,
> and suddenly it appears in the POT file. Has something to do with QT
> or with Gettex
On Sun, Oct 22, 2023 at 01:06:58PM +0200, Dan wrote:
> Sorry, I did not intend to mean or hint you all should wait until I am done.
> The strings I noted as "problematic" are, in my opinion, not that important:
> little type errors and improvable UX. Also, there are just a few.
> I encounter them
l return to
>> the translator role again, restarting the cycle.
>>
>
> Dan, I don't think this is a satysfying answer :)
>
> If you want to block the string freeze and delay 2.4 release please give us
> some time when you plan to "report in bulk of the rest&quo
down some documentation
> of the translation. That's how I work when translating alone: separate the
> roles completely. After revision, most likely I will return to the translator
> role again, restarting the cycle.
Dan, I don't think this is a satysfying answer :)
If you wa
appear in English, no
>> matter the language set for the UI.
>>
>
> Fixed.
>
Just for the record and out of curiosity, what was the problem with that
string? I see you just added a line break HTML element to it, and suddenly it
appears in the POT file. Has something to do with Q
21 d’oct. de 2023, 22:15 per sa...@lyx.org:
> On Sat, Oct 21, 2023 at 10:38:36AM +0200, Dan wrote:
>
>> I must object :). I have come across some strings of the UI that should be
>> changed. For now I am only notifying the following two, which I think are
>> important; the rest I will report in
On Sat, Oct 21, 2023 at 10:38:36AM +0200, Dan wrote:
> I must object :). I have come across some strings of the UI that should be
> changed. For now I am only notifying the following two, which I think are
> important; the rest I will report in bulk when done with the translation.
What's your es
e in Spanish
> - Language (tongue) -> lengua / idioma
> - Language (programming) -> lenguaje (de programación)
> This rises a problem with the string "Language" in the dialog box
> for a listing's settings. The problematic string is the group title,
> not the lang
On 10/9/23 14:42, Pavel Sanda wrote:
On Fri, Sep 08, 2023 at 04:05:49PM -0400, Richard Kimberly Heck wrote:
I am planning to freeze strings once we have had some initial feedback on
beta 5 and make sure that there aren't any issues there that need a string
change. We're waiting at
Am Montag, dem 09.10.2023 um 20:42 +0200 schrieb Pavel Sanda:
> > 5. The string "Table" appears in quite some contexts that are
> > contradicting: in some it really means Table, while in others it
> > actually means "Tabular". Remember that Table/Tabular
p
> explaining how to use placeholders to set a custom fixed time says "01-23 in
> AM/PM", twice. This, obviously does not make any sense, as AM/PM is just for
> 00-11 hours.
This one is fixed.
> 5. The string "Table" appears in quite some contexts that are contr
On Fri, Sep 08, 2023 at 04:05:49PM -0400, Richard Kimberly Heck wrote:
> I am planning to freeze strings once we have had some initial feedback on
> beta 5 and make sure that there aren't any issues there that need a string
> change. We're waiting at the moment for the Windo
> I am planning to freeze strings once we have had some initial feedback on
> beta 5 and make sure that there aren't any issues there that need a string
> change. We're waiting at the moment for the Windows installer.
>
> That said, if there are any changes you wa
Hi, all,
I am planning to freeze strings once we have had some initial feedback
on beta 5 and make sure that there aren't any issues there that need a
string change. We're waiting at the moment for the Windows installer.
That said, if there are any changes you want to get into
On Tue, Sep 05, 2023 at 09:17:09PM +0200, Dan wrote:
> during the translation of the UI I found a string that, in my opinion, is not
> clear enough about the feature is describes: showing changes of CT in output.
> See the attached LyX file for an example.
>
> Changes, if in o
> during the translation of the UI I found a string that, in my opinion, is not
> clear enough about the feature is describes: showing changes of CT in output.
> See the attached LyX file for an example.
>
For some reason, I can not reproduce the behaviour described in the attached
Hello,
during the translation of the UI I found a string that, in my opinion, is not
clear enough about the feature is describes: showing changes of CT in output.
See the attached LyX file for an example.
Changes, if in order, should be made to the file
src/frontends/qt/ui/ChangeTrackingUi.ui
pp -o cow
$ ./cow
std::string is NOT COW.
$ /usr/sfw/bin/g++ -dumpversion
3.4.3
$ /usr/sfw/bin/g++ cow.cpp -o cow
$ ./cow
std::string is COW.
Then I tried it on cygwin:
$ g++ cow.cpp -o cow
$ ./cow
std::string is NOT COW.
and all of this despite the fact that _GLIBCXX_USE_CXX11_ABI=0 on
cygwin.
Le 11/05/2023 à 23:04, Enrico Forestieri a écrit :
Anyway, I don't think the autoconf test is broken because:
From what I read here:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
this define is merely a default. It looks like one can choose to change
it, as long as all th
STD_STRING
/* std::string uses copy-on-write */
-#define STD_STRING_USES_COW 1
+/* #undef STD_STRING_USES_COW */
So, cygwin is using COW in the std::string implementation...
Or our test is broken on cywin... I think the new thread-safe string
type is required for C++11 compliance.
JMarc
--
lyx-devel
think.
Or not, maybe, see below.
This is what I get when comparing cygwin and native windows
configuration:
$ diff -up build-cygwin/config.h build-win32/config.h | grep -B1 STD_STRING
/* std::string uses copy-on-write */
-#define STD_STRING_USES_COW 1
+/* #undef STD_STRING_USES_COW */
So
cygwin and native windows
configuration:
$ diff -up build-cygwin/config.h build-win32/config.h | grep -B1 STD_STRING
/* std::string uses copy-on-write */
-#define STD_STRING_USES_COW 1
+/* #undef STD_STRING_USES_COW */
So, cygwin is using COW in the std::string implementation...
I hacked
On Thu, May 11, 2023 at 04:32:45PM +0200, Jean-Marc Lasgouttes wrote:
Le 11/05/2023 à 15:26, Jean-Marc Lasgouttes a écrit :
In file included from ../../../../src/frontends/qt/Toolbars.cpp:15:
../../../../src/Converter.h: In member function ‘const string&
lyx::Converter::from() c
Le 11/05/2023 à 15:26, Jean-Marc Lasgouttes a écrit :
In file included from ../../../../src/frontends/qt/Toolbars.cpp:15:
../../../../src/Converter.h: In member function ‘const string&
lyx::Converter::from() const’:
../../../../src/Converter.h:55:51: warning: returning reference to
tempo
er I get a lot of warnings like the following:
In file included from ../../../../src/frontends/qt/Toolbars.cpp:15:
../../../../src/Converter.h: In member function ‘const string&
lyx::Converter::from() const’:
../../../../src/Converter.h:55:51: warning: returning reference to
temporary [-Wret
:23 2023 +0200
Do not return copies of string members
This fixes the g++ 12 warnings below.
After this commit my cygwin build crashes badly at startup. I can't
even get a backtrace. What is strange is that a native Windows build
works fine, instead. Both builds use the same versi
Le 09/05/2023 à 22:08, Enrico Forestieri a écrit :
On Fri, May 05, 2023 at 07:28:59PM +0200, Jean-Marc Lasgouttes wrote:
commit 3ae5d6bdec1df23cc0d848b2d8bf6b09323b
Author: Jean-Marc Lasgouttes
Date: Fri May 5 20:35:23 2023 +0200
Do not return copies of string members
This fixes
On Fri, May 05, 2023 at 07:28:59PM +0200, Jean-Marc Lasgouttes wrote:
commit 3ae5d6bdec1df23cc0d848b2d8bf6b09323b
Author: Jean-Marc Lasgouttes
Date: Fri May 5 20:35:23 2023 +0200
Do not return copies of string members
This fixes the g++ 12 warnings below.
After this commit my
Il giorno sab, 06/05/2023 alle 19.00 -0400, Richard Kimberly Heck ha
scritto:
> Pushed.
>
> Riki
Thank you for the quick fix.
--
Lorenzo
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 5/6/23 16:05, Jean-Marc Lasgouttes wrote:
Le 06/05/2023 à 21:30, Richard Kimberly Heck a écrit :
I see the warning when opening Document> Settings. Still happens with
some content in between, too.
It seems to happen if there's nothing after the "EndPreamble". If I
add just a comment, for e
Le 06/05/2023 à 21:30, Richard Kimberly Heck a écrit :
I see the warning when opening Document> Settings. Still happens with
some content in between, too.
It seems to happen if there's nothing after the "EndPreamble". If I add
just a comment, for example, it does away. Is the test !pimpl_->is
On 5/6/23 09:04, lorenzobertin...@gmail.com wrote:
Il giorno sab, 06/05/2023 alle 14.18 +0200, Jean-Marc Lasgouttes ha
scritto:
Le 06/05/2023 à 14:06, lorenzobertin...@gmail.com a écrit :
LyX: Long string not ended by `EndPreamble' [around line 4 of
file
current token: 'EndPreambl
Il giorno sab, 06/05/2023 alle 14.18 +0200, Jean-Marc Lasgouttes ha
scritto:
> Le 06/05/2023 à 14:06, lorenzobertin...@gmail.com a écrit :
>
> > > LyX: Long string not ended by `EndPreamble' [around line 4 of
> > > file
> > > current token: 'EndPreambl
ollow:
* the first line determines the prefix, i.e. the sequence of spaces and
tabs that are the start of string.This prefix is remembered and remove
from the string.
* the lines that follow should begin with this prefix, which will not be
kept in the strings.
* the first line that contains only th
Dear list,
since at least a year I've been getting the following after validating
a local layout in document preferences:
> LyX: Long string not ended by `EndPreamble' [around line 4 of file
> current token: 'EndPreamble' context: '']
It happens with P
Am Samstag, dem 22.04.2023 um 21:11 +0200 schrieb Pavel Sanda:
> In the same vein, anyone sees purpose in translation machinery for
> fontsizes?
Yes. Not all languages use Arabic numbering.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-dev
Am Samstag, dem 22.04.2023 um 20:59 +0200 schrieb Pavel Sanda:
> Or it's because LTR languages?
Yes, bidi, or any differing syntactic structure.
--
Jürgen
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Sat, Apr 22, 2023 at 08:59:22PM +0200, Pavel Sanda wrote:
> Hi,
>
> we have the following in GuiBranch.cpp:
>
> branchCO->addItem(
> toqstr(bformat(_("%1$s[[branch]] (%2$s)[[master]]"),
> branch, _("master"))),
> toqstr(branch));
>
> So translators a
Hi,
we have the following in GuiBranch.cpp:
branchCO->addItem(
toqstr(bformat(_("%1$s[[branch]] (%2$s)[[master]]"),
branch, _("master"))),
toqstr(branch));
So translators are asked to translate "%1$s (%2$s)".
Is this really intended or can I just elimin
her entries are translated. This is independent of cmake/automake
> created lyx.
>
> I missed to find a reason for this behaviour.
>
> Kornel
>
Forget it. The problem shows in de.po, and there the translated string is
'fuzzy'.
Kornel
pgpnKw4JcQ_Gd.pgp
Descri
lib/ui/stdcontext.inc:273
Item "Half Quad Space (1/2 em)|l" "inset-modify space \enskip{}"
is contained in the po-files, but is not translated in the context-space menu.
All other entries are translated. This is independent of cmake/automake created
lyx.
I missed to find a reason for th
On Monday, 3 January 2022 18.32.14 WET José Abílio Matos wrote:
> In any case I found other cases where the code is wrong (like the BOM
> removal that does not work) and that it does not give an error although it
> is wrong.
For future reference this is an issue that happens silently. In this case
On Monday, 3 January 2022 16.02.51 WET Pavel Sanda wrote:
> On Mon, Jan 03, 2022 at 03:16:47PM +, José Abílio Matos wrote:
> > If you want I can take care of that, in 2.4, and see if there are cases
> > where the conversion is missing.
>
> Please do, I suffer from ophidiophobia.
You keep insi
On Mon, Jan 03, 2022 at 03:16:47PM +, José Abílio Matos wrote:
> If you want I can take care of that, in 2.4, and see if there are cases where
> the conversion is missing.
Please do, I suffer from ophidiophobia.
> @Riki: is it possible to have a layout file such that the encoding is not
> u
e other code that already does that.
The issue is that in Python 2 str (string type) does not has an encoding
associated, later there was a new string type (unicode) where the string has
an encode associated.
In Python 3 strings become encoding aware and the previous strings were
renamed bytes.
On Mon, Jan 03, 2022 at 02:04:20PM +, José Abílio Matos wrote:
> Looking into further detail I would easily that the first part of the patch
> is
> correct (change "..." to b"...").
>
> The second part where it changes sys.stdin to sys.stdin.buffer is probably
> incorrect:
>
> The similar
On Wednesday, 29 December 2021 14.52.29 WET Pavel Sanda wrote:
> Jose,
>
> are the proposed changes sensible?
> I remember there were flowing similar patches to python codebase before.
The changes are reasonable for python 3.
I am not so sure about python 2 (because we support it) although it see
Jose,
are the proposed changes sensible?
I remember there were flowing similar patches to python codebase before.
Pavel
- Forwarded message from "Leo L. Schwab" -
From: "Leo L. Schwab"
To: Debian Bug Tracking System
Subject: Bug#1002821: lyx-common: Str
Hi, all,
I intend to write translators regarding 2.3.6 on Wednesday, so if
there's anything that needs to go into 2.3.x before then...
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Strings are now frozen in stable, as translators are now doing their work.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Strings are now frozen in stable branch.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Tue, Jul 23, 2019 at 05:27:02PM +0200, Pavel Sanda wrote:
> On Tue, Jul 23, 2019 at 06:08:45PM +0300, Guy Rutenberg wrote:
> > Hi,
> >
> > How can one get a list of all translatable strings that get translated
> > according to the current document's language?
>
> lib/layouttranslations
Oops,
Le 23/07/2019 à 17:08, Guy Rutenberg a écrit :
Hi,
How can one get a list of all translatable strings that get translated
accoring to the current document's language?
This is a continuation of the discussion in
https://www.lyx.org/trac/ticket/11607. I think that basically nobody
uses the He
On Tue, Jul 23, 2019 at 06:08:45PM +0300, Guy Rutenberg wrote:
> Hi,
>
> How can one get a list of all translatable strings that get translated
> according to the current document's language?
lib/layouttranslations
"he" is flagged as being not reviewed for strings:
"List of Listings"
"Nomenclatu
Hi,
How can one get a list of all translatable strings that get translated
accoring to the current document's language?
This is a continuation of the discussion in
https://www.lyx.org/trac/ticket/11607. I think that basically nobody uses
the Hebrew translation for the GUI (most people prefer Engl
Strings are frozen now in the 2.3.x branch so that translations can be
prepared for LyX 2.3.3. Please have these done by Sunday, 19 May. I'll
plan to build the release shortly thereafter.
Apologies that it has taken so long to get 2.3.3 out. It's been a crazy
semester.
Riki
PS Apologies for dupl
Am Montag, 5. November 2018 11:33:41 CET schrieb Richard Kimberly Heck
:
> On 11/4/18 8:57 AM, Kornel Benko wrote:
> > commit aa68dcefa0aa4818b2d01d69e33db4906017ebfc
> > Author: Kornel Benko
> > Date: Sun Nov 4 14:54:06 2018 +0100
> >
> > Findadv: '
On 11/4/18 8:57 AM, Kornel Benko wrote:
> commit aa68dcefa0aa4818b2d01d69e33db4906017ebfc
> Author: Kornel Benko
> Date: Sun Nov 4 14:54:06 2018 +0100
>
> Findadv: 'Optimized' detection of matched string
>
> This is clearly a hack, because I don'
An email to translators regarding the 2.3.0 release is going to be sent
soon, so if you need to make any commits that change strings, please
push them as soon as possible.
Scott
signature.asc
Description: PGP signature
El 13.05.2017 a las 18:59, Jean-Marc Lasgouttes escribió:
There are several advantages to an enum:...
Thanks for the explanation.
This requires some small changes to BufferParams, along with a file
format change. I am not at ease with these things, so I leave it to you.
OK, I'll do it righ
oing to be better.
That's OK, but we have to remember to insist when we want you in the loop.
At first many thanks for that. Nevertheless I want to understand why the
string was a bad idea. I am not a developer and therefore it is not
clear at how many possible values a string is preferr
ime during the 2.3 cycle.)
But it seems it is going to be better.
After this patch,
At first many thanks for that. Nevertheless I want to understand why the
string was a bad idea. I am not a developer and therefore it is not
clear at how many possible values a string is preferred over an enum
On 2017-05-12, Jean-Marc Lasgouttes wrote:
> Le 12/05/2017 à 15:45, Guenter Milde a écrit :
>> Note that "math_number" is also misleading: the variable determines the
>> *placement* of the equation number (left/default/right).
>> Especially in connection with "math", the term "number" implies somet
Le 12/05/2017 à 15:45, Guenter Milde a écrit :
Note that "math_number" is also misleading: the variable determines the
*placement* of the equation number (left/default/right).
Especially in connection with "math", the term "number" implies something
quite different from a layout setting.
Indeed
Dear Jean-Marc and Uwe, dear LyX developers,
On 2017-05-12, Jean-Marc Lasgouttes wrote:
...
>> This commit replaces the string math_number_before by a proper
>> math_number enum.
>> Note that the _before naming was misleading. It was chosen at a time
>>
Wrong list, and forgot to take in account that Uwe does not read us.
JMarc
Message transféré
Sujet : Re: [LyX/master] Never, never use a string for something that
has 3 values
Date : Fri, 12 May 2017 13:24:04 +0200
De : Jean-Marc Lasgouttes
Pour : lyx-...@lists.lyx.org
Le
On Thursday, 11 May 2017 15.06.42 WEST Jean-Marc Lasgouttes wrote:
> I still get:
>
> File
> "/home/local/lasgoutt/lyx/master/lib/scripts/lyxpreview2bitmap.py", line 166
> def_re =
> re.compile(rb"(newcommandx|globallongdef)([a-zA-Z]+)")
>
> ^
> SyntaxError: in
Le 09/05/2017 à 17:57, José Matos a écrit :
commit 6495cd135f15c3775613c79b008ad62f6726573e
Author: José Matos
Date: Tue May 9 16:53:32 2017 +0100
make python string compliant with python 2 and 3
I still get:
File
"/home/local/lasgoutt/lyx/master/lib/scripts/lyxpreview2bitm
Am Dienstag, 27. Dezember 2016 um 07:38:32, schrieb Jürgen Spitzmüller
> Am Dienstag, den 27.12.2016, 01:49 +0100 schrieb Kornel Benko:
> > Jürgen,
> > the relevant dialogs are in document language, but they should be in
> > gui language.
>
> Not here. Can you give me an example, please?
>
> Jü
Jean-Marc Lasgouttes wrote:
> Le 07/07/2016 ? 23:58, Jean-Marc Lasgouttes a écrit :
>> So, what is the secret patch, I hear you ask? Here it is for your
>> enjoyment. The idea is to keep around the glyph representation of our
>> row elements and to use them even for drawing. It is not quite ready,
()),
+ s.size() * sizeof(lyx::docstring::value_type)));
+}
+
+}
+
+
namespace lyx {
namespace frontend {
@@ -51,11 +70,15 @@ inline QChar const ucs4_to_qchar(char_type const ucs4)
} // anon namespace
-// Limit strwidth_cache_ size to 512kB of string data
+/*
+ * Li
1,11 +52,10 @@ inline QChar const ucs4_to_qchar(char_type const ucs4)
} // anon namespace
-// Limit strwidth_cache_ size to 512kB of string data
+// Limit (strwidth|breakat)_cache_ size to 512kB of string data
GuiFontMetrics::GuiFontMetrics(QFont const & font)
: font_(font), metrics_(
Le 17/07/2016 18:31, Jean-Marc Lasgouttes a écrit :
Guillaume, I'd like to have your input wrt this patch and Qt 5.x. I
would prefer for cleanness to avoid double caching in this case and keep
the patch Qt4 only.
Makes sense.
Le 07/07/2016 23:58, Jean-Marc Lasgouttes a écrit :
Two conclusions:
* the secret patch is fast
* Qt5.5 is fast even without it (better tests have to be done with
Qt5), and not really faster with it. For memory sake, the caching
patch should maybe by Qt4 only.
So, what is the secret patch,
Le 08/07/2016 18:29, Pavel Sanda a écrit :
2.3.0dev+Qt4 with caching: 10 seconds
I would like to reproduce this line. It is current master on some patch on
top of it?
Current master + secret patch.
I gave you antidote already ;) Seing your reaction it strikes me that the whole
thing might h
Jean-Marc Lasgouttes wrote:
>> Can you try once more, now with only left-right cursor?
>> The secret patch does not seem to help with this issue.
>
> OK, here you are (full screen, zoom 120%, UserGuide from 2.1.5, the bottom
> contains the first line of the "how LyX looks" section):
>
> 2.1.5: 8 s
Le 08/07/2016 00:42, Pavel Sanda a écrit :
Jean-Marc Lasgouttes wrote:
the User Guide, because the right arrow really requires too much time for
some reason. [Rereading your message I notice only now that you meant first
page only. Oh well.]
Can you try once more, now with only left-right curs
I will.
JMarc
Le 8 juillet 2016 00:42:47 GMT+02:00, Pavel Sanda a écrit :
>Jean-Marc Lasgouttes wrote:
>> the User Guide, because the right arrow really requires too much time
>for
>> some reason. [Rereading your message I notice only now that you meant
>first
>> page only. Oh well.]
>
>Can y
Jean-Marc Lasgouttes wrote:
> the User Guide, because the right arrow really requires too much time for
> some reason. [Rereading your message I notice only now that you meant first
> page only. Oh well.]
Can you try once more, now with only left-right cursor?
The secret patch does not seem to h
Le 07/07/2016 23:58, Jean-Marc Lasgouttes a écrit :
Le 07/07/2016 19:06, Pavel Sanda a écrit :
Can you try if you can see difference between 2.1 and master for this
scenario:
1. set high speed rate for your keyboard: xset r rate 300 180
2. load user guide, fullscreen
3. Hold right arrow until yo
1 - 100 of 498 matches
Mail list logo
