Am Wed, 25 Nov 2020 23:48:18 +0200
schrieb Yuriy Skalko :
> >> I assume that careful replacement string to docstring will be mostly
> >> enough.
> >
> > No, we need wstring. Regular expressions (wregex) work on wchar_t.
> >
> >
> > Kornel
>
> wchar_t can cause problems with portab
I assume that careful replacement string to docstring will be mostly
enough.
No, we need wstring. Regular expressions (wregex) work on wchar_t.
Kornel
wchar_t can cause problems with portability (it is 4 bytes on Unix and 2
on Windows). So maybe defining docregex as basic_regex (lik
Am Wed, 25 Nov 2020 03:05:43 +0200
schrieb Yuriy Skalko :
> > Yes, that is a problem with non-ascii. These characters takes more than one
> > byte,
> > but tour search-engine uses UTF8 instead of wchar.
> > So, for instance you cannot use structs like [е-р] (Cyrillic chars).
> > Would be a good p
Yes, that is a problem with non-ascii. These characters takes more than one
byte,
but tour search-engine uses UTF8 instead of wchar.
So, for instance you cannot use structs like [е-р] (Cyrillic chars).
Would be a good project IMHO ...
Kornel
I assume that careful replacement string to
Am Tue, 24 Nov 2020 00:26:39 +0200
schrieb Yuriy Skalko :
> > You mean inside math? What is your regex and what should be found?
> >
> > Kornel
>
> Not just in math, in plain text too. Just insert some letters inside
> regular expression inset. Without the regex inset adv-search works
You mean inside math? What is your regex and what should be found?
Kornel
Not just in math, in plain text too. Just insert some letters inside
regular expression inset. Without the regex inset adv-search works
correctly with Cyrillic.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.
As of commit be50eb50, you should be able to find the string "\rho\cdot V".
But since it is search with format enabled, you have to select flalign
environment (so,
NOT 'flalign*')
Kornel
Thanks. So with my very shallow manual testing std::regex works fine as
boost::regex replacement.
Am Mon, 23 Nov 2020 23:07:26 +0200
schrieb Yuriy Skalko :
> > This is not so easy. There are tests, but they are using shortcuts (because
> > of
> > lack of
> > available functions). The shortcuts itself are language dependent, so one
> > cannot use them
> > for instance in Russian GUI.
> >
>
This is not so easy. There are tests, but they are using shortcuts (because of
lack of
available functions). The shortcuts itself are language dependent, so one
cannot use them
for instance in Russian GUI.
As an example (cua shortcuts, Slovak GUI, compare findadv-re-04-in.txt):
#select Slovak G
Am Sun, 22 Nov 2020 16:01:12 +0200
schrieb Yuriy Skalko :
> >> Thanks for testing. Now we now that LyX compiles with std regex on MSVC
> >> 2019. Probably it would be also useful if somebody test this on previous
> >> MSVC (2017?).
> >>
> >> Yuriy
> >
> > But do we know if it works as expect
Am Sun, 22 Nov 2020 21:04:05 +0200
schrieb Yuriy Skalko :
> > Lyx2.3 is not in the best shape for checking adv-find. But you are right,
> > this
> > is not the
> > expected outcome.
> >
> > Kornel
>
> If there are some advanced search strings to test basic regex
> functionality in L
Lyx2.3 is not in the best shape for checking adv-find. But you are right, this
is not the
expected outcome.
Kornel
If there are some advanced search strings to test basic regex
functionality in LyX, I can provide manual check on MinGW64-compiled LyX
in Windows.
Yuriy
--
lyx-devel m
Le 21/11/2020 à 20:29, Yuriy Skalko a écrit :
This is how the code is elsewhere. Do you use tab size == 4 ?
Yes, 4 spaces, so the formatting below is right? As for me it is hard to
separate condition from following statements.
if (!current_view_
|| (!lyxrc.open_buffers_in_tabs
Am Sun, 22 Nov 2020 16:01:12 +0200
schrieb Yuriy Skalko :
> >> Thanks for testing. Now we now that LyX compiles with std regex on MSVC
> >> 2019. Probably it would be also useful if somebody test this on previous
> >> MSVC (2017?).
> >>
> >> Yuriy
> >
> > But do we know if it works as expect
Thanks for testing. Now we now that LyX compiles with std regex on MSVC
2019. Probably it would be also useful if somebody test this on previous
MSVC (2017?).
Yuriy
But do we know if it works as expected? One way would be to test Adv-Find.
But there is no test-environment for Windows availabl
Am Sun, 22 Nov 2020 14:58:13 +0200
schrieb Yuriy Skalko :
> > Indeed, it now builds correctly on Windows!
>
>
> Thanks for testing. Now we now that LyX compiles with std regex on MSVC
> 2019. Probably it would be also useful if somebody test this on previous
> MSVC (2017?).
>
> Yuriy
But d
Indeed, it now builds correctly on Windows!
Thanks for testing. Now we now that LyX compiles with std regex on MSVC
2019. Probably it would be also useful if somebody test this on previous
MSVC (2017?).
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/lis
This is how the code is elsewhere. Do you use tab size == 4 ?
Yes, 4 spaces, so the formatting below is right? As for me it is hard to
separate condition from following statements.
if (!current_view_
|| (!lyxrc.open_buffers_in_tabs
&& current_view_->documentBufferView() !
On Sat, 21 Nov 2020 at 20:17, Yuriy Skalko wrote:
> > It compiles flawlessly with MSVC 2019 (16.7.1):
> >
> > C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>cl /v
> >> Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29111 for x64
> >> Copyright (C) Microsoft Corporation. All
It compiles flawlessly with MSVC 2019 (16.7.1):
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>cl /v
Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29111 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
However, it fails when linking (but I'm not sure i
On Sat, 21 Nov 2020 at 19:54, Yuriy Skalko wrote:
> >
> > I like them, but a couple remarks.
> >
> > * patch 2: broken indentation
> >
> > if (!current_view_
> > - || (!lyxrc.open_buffers_in_tabs
> > - && current_view_->documentBufferView()
Le 21/11/2020 à 19:54, Yuriy Skalko a écrit :
I "broke" it because now condition and nested block have same level of
indentation and it is hard to see where they are separated. Comment
helps but still...
This is how the code is elsewhere. Do you use tab size == 4 ?
* concerning std::any, curr
I like them, but a couple remarks.
* patch 2: broken indentation
if (!current_view_
- || (!lyxrc.open_buffers_in_tabs
- && current_view_->documentBufferView() != 0
- && !is_open)) {
+ || (!lyxrc.
Le 21/11/2020 à 16:18, Richard Kimberly Heck a écrit :
What about to get rid of std algorithms and use just plain range for
loops? No lambdas, no boost::range, fast compilation and code speed :)
This one looks good to me, but I'd like also to know what JMarc thinks.
Person
Le 21/11/2020 à 15:37, Yuriy Skalko a écrit :
If Boost is only used for temporary implementation of really useful
features from newer standards (and only for older compilers) it should
be Ok. And this dependency will drop itself over time.
Some steps in this direction are in attached patches.
Le 21/11/2020 à 16:18, Richard Kimberly Heck a écrit :
What about to get rid of std algorithms and use just plain range for
loops? No lambdas, no boost::range, fast compilation and code speed :)
This one looks good to me, but I'd like also to know what JMarc thinks.
Personally I prefer it a l
On 11/20/20 7:50 PM, Yuriy Skalko wrote:
>> Le 20/11/2020 à 18:33, Pavel Sanda a écrit :
>>> On Fri, Nov 20, 2020 at 04:14:57PM +0100, Jean-Marc Lasgouttes wrote:
Le 20/11/2020 ?? 15:33, Yuriy Skalko a écrit :
> I assume that it is a template-heavy thing and it can significantly
> incr
If Boost is only used for temporary implementation of really useful features
from newer standards (and only for older compilers) it should be Ok. And this
dependency will drop itself over time.
Some steps in this direction are in attached patches.
Yuriy
From 32ac6a047bda71c47c17a4ff1417bd273a
Le 20/11/2020 à 18:33, Pavel Sanda a écrit :
On Fri, Nov 20, 2020 at 04:14:57PM +0100, Jean-Marc Lasgouttes wrote:
Le 20/11/2020 ?? 15:33, Yuriy Skalko a écrit :
I assume that it is a template-heavy thing and it can significantly
increase compilation time (also don't know about compatibility of
Le 20/11/2020 à 18:33, Pavel Sanda a écrit :
On Fri, Nov 20, 2020 at 04:14:57PM +0100, Jean-Marc Lasgouttes wrote:
Le 20/11/2020 ?? 15:33, Yuriy Skalko a écrit :
I assume that it is a template-heavy thing and it can significantly
increase compilation time (also don't know about compatibility of
On Fri, Nov 20, 2020 at 04:14:57PM +0100, Jean-Marc Lasgouttes wrote:
> Le 20/11/2020 ?? 15:33, Yuriy Skalko a écrit :
> >I assume that it is a template-heavy thing and it can significantly
> >increase compilation time (also don't know about compatibility of boost
> >ranges with ranges-v3 library t
Le 20/11/2020 à 16:14, Jean-Marc Lasgouttes a écrit :
Le 20/11/2020 à 15:33, Yuriy Skalko a écrit :
I assume that it is a template-heavy thing and it can significantly
increase compilation time (also don't know about compatibility of
boost ranges with ranges-v3 library that will be standard fro
Le 20/11/2020 à 15:33, Yuriy Skalko a écrit :
I assume that it is a template-heavy thing and it can significantly
increase compilation time (also don't know about compatibility of boost
ranges with ranges-v3 library that will be standard from C++20). Is it
OK to use it? And more general questio
I have to say that lambdas are not my cup of tea, but the original code is not
great either.
I've seen usage of lambdas in LyX code, so thought they are acceptable
for such small functions.
Considering the following:
transform(lyxaction.func_begin(), lyxaction.func_end(),
-
34 matches
Mail list logo
