Re: [LyX/master] Simplify checking whether files are controlled by SVN and GIT.
On Fri, Jan 08, 2021 at 10:59:43PM -0500, Richard Kimberly Heck wrote: > On 1/8/21 10:45 PM, Scott Kostyshak wrote: > > On Mon, Dec 28, 2020 at 03:45:11PM +0200, Yuriy Skalko wrote: > > I am sorry not to have a time to follow this thoroughly, but is this > > cvs log / git log used only inh "register" case as initially discussed > > or you want to use it on every file load? > > Calling log could but pretty expensive operation for large archives. > The -n0 flag that Yuriy proposed should take care of that, too. So > another reason to go that way. > >>> > >>> I understood that. The minor concern was that it can still take seconds > >>> to get > >>> the first commit touching particular file in larger git repos if its > >>> buried > >>> down in the history. But maybe it's not that different from git-ls. > >>> > >>> My main concern though were changes to CVS - I haven't seen -n0 > >>> equivalent and > >>> are you positive that cvs log does not actually try to connect to server > >>> (would > >>> make us fail if you are offline)? It's really long time ago I used cvs, > >>> but > >>> IIRC each tracked directory has the needed metadata locally at the place > >>> so do we actualy need these changes to fulfil the users-list request? > >>> > >>> Sorry for nitpicking, but given that this piece of code is executed at > >>> each > >>> document load we better be super careful here... > >>> > >>> Pavel > >> Committed "-n 0" for Git. CVS has "-Q" option > >> (https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Global-options.html#Global-options) > >> that may help too, but I have no CVS installed, so cannot test this. > > I'm not sure that "git log " do > > what we want here. For me (git version 2.20.1) they do not exit with > > error if the file is not tracked. > > Hmm. I was certain I had checked this, but it is not exiting with an > error now for me either. > > > > I can see why the implementation in the previous version of using git-ls > > was complex since we had to redirect output to a file and check it, but > > what about using "git ls-files --error-unmatch " ? The > > "--error-unmatch" seems to make it so we don't have to check a file. > > The only annoyance I see is that there is no "--quiet" option so we > > would need to redirect the output. I can look into adding a "quiet" > > argument to doVCCommandCall() that would quiet both STDOUT and STDERR if > > the attached patch is on the right track. > > It looks right to me. > > Enrico may have good ideas about how to do the redirection. Sounds good. If anyone knows a good approach, please feel free to merge it into the patch and commit. Or describe the approach and I'll implement it. 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] Simplify checking whether files are controlled by SVN and GIT.
On 1/8/21 10:45 PM, Scott Kostyshak wrote: > On Mon, Dec 28, 2020 at 03:45:11PM +0200, Yuriy Skalko wrote: > I am sorry not to have a time to follow this thoroughly, but is this > cvs log / git log used only inh "register" case as initially discussed > or you want to use it on every file load? > Calling log could but pretty expensive operation for large archives. The -n0 flag that Yuriy proposed should take care of that, too. So another reason to go that way. >>> >>> I understood that. The minor concern was that it can still take seconds to >>> get >>> the first commit touching particular file in larger git repos if its buried >>> down in the history. But maybe it's not that different from git-ls. >>> >>> My main concern though were changes to CVS - I haven't seen -n0 equivalent >>> and >>> are you positive that cvs log does not actually try to connect to server >>> (would >>> make us fail if you are offline)? It's really long time ago I used cvs, but >>> IIRC each tracked directory has the needed metadata locally at the place >>> so do we actualy need these changes to fulfil the users-list request? >>> >>> Sorry for nitpicking, but given that this piece of code is executed at each >>> document load we better be super careful here... >>> >>> Pavel >> Committed "-n 0" for Git. CVS has "-Q" option >> (https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Global-options.html#Global-options) >> that may help too, but I have no CVS installed, so cannot test this. > I'm not sure that "git log " do > what we want here. For me (git version 2.20.1) they do not exit with > error if the file is not tracked. Hmm. I was certain I had checked this, but it is not exiting with an error now for me either. > I can see why the implementation in the previous version of using git-ls > was complex since we had to redirect output to a file and check it, but > what about using "git ls-files --error-unmatch " ? The > "--error-unmatch" seems to make it so we don't have to check a file. > The only annoyance I see is that there is no "--quiet" option so we > would need to redirect the output. I can look into adding a "quiet" > argument to doVCCommandCall() that would quiet both STDOUT and STDERR if > the attached patch is on the right track. It looks right to me. Enrico may have good ideas about how to do the redirection. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Simplify checking whether files are controlled by SVN and GIT.
On Mon, Dec 28, 2020 at 03:45:11PM +0200, Yuriy Skalko wrote:
> > > > I am sorry not to have a time to follow this thoroughly, but is this
> > > > cvs log / git log used only inh "register" case as initially discussed
> > > > or you want to use it on every file load?
> > > > Calling log could but pretty expensive operation for large archives.
> > >
> > > The -n0 flag that Yuriy proposed should take care of that, too. So
> > > another reason to go that way.
> >
> >
> > I understood that. The minor concern was that it can still take seconds to
> > get
> > the first commit touching particular file in larger git repos if its buried
> > down in the history. But maybe it's not that different from git-ls.
> >
> > My main concern though were changes to CVS - I haven't seen -n0 equivalent
> > and
> > are you positive that cvs log does not actually try to connect to server
> > (would
> > make us fail if you are offline)? It's really long time ago I used cvs, but
> > IIRC each tracked directory has the needed metadata locally at the place
> > so do we actualy need these changes to fulfil the users-list request?
> >
> > Sorry for nitpicking, but given that this piece of code is executed at each
> > document load we better be super careful here...
> >
> > Pavel
>
> Committed "-n 0" for Git. CVS has "-Q" option
> (https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Global-options.html#Global-options)
> that may help too, but I have no CVS installed, so cannot test this.
I'm not sure that "git log " do
what we want here. For me (git version 2.20.1) they do not exit with
error if the file is not tracked.
I can see why the implementation in the previous version of using git-ls
was complex since we had to redirect output to a file and check it, but
what about using "git ls-files --error-unmatch " ? The
"--error-unmatch" seems to make it so we don't have to check a file.
The only annoyance I see is that there is no "--quiet" option so we
would need to redirect the output. I can look into adding a "quiet"
argument to doVCCommandCall() that would quiet both STDOUT and STDERR if
the attached patch is on the right track.
Scott
From cc80dd9a6f18ac7de0ddc13f7950132fe2e4f3e5 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak
Date: Fri, 8 Jan 2021 22:37:31 -0500
Subject: [PATCH] Works but does not redirect standard error
---
src/VCBackend.cpp | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/VCBackend.cpp b/src/VCBackend.cpp
index b20a586090..078c59adaa 100644
--- a/src/VCBackend.cpp
+++ b/src/VCBackend.cpp
@@ -39,6 +39,8 @@ using namespace lyx::support;
namespace lyx {
+namespace os = support::os;
+
int VCS::doVCCommandCall(string const & cmd, FileName const & path)
{
@@ -1830,7 +1832,9 @@ bool GIT::findFile(FileName const & file)
string const fname = onlyFileName(file.absFileName());
LYXERR(Debug::LYXVC, "LyXVC: Checking if file is under git control for `"
<< fname << '\'');
- int const ret = doVCCommandCall("git log -n 0 " + quoteName(fname),
+ int const ret = doVCCommandCall("git ls-files --error-unmatch " +
+ quoteName(fname) + " > " +
+ quoteName(os::nulldev()),
file.onlyPath());
bool const found = (ret == 0);
LYXERR(Debug::LYXVC, "GIT control: " << (found ? "enabled" : "disabled"));
--
2.20.1
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] Tab binding: outline-in before depth-increment
On Fri, Jan 08, 2021 at 09:00:51PM -0500, Richard Kimberly Heck wrote: > On 1/8/21 8:32 PM, Scott Kostyshak wrote: > > On Fri, Jan 08, 2021 at 08:05:00PM -0500, Richard Kimberly Heck wrote: > >> On 1/8/21 5:59 PM, Scott Kostyshak wrote: > >>> On Fri, Sep 11, 2020 at 02:30:00PM -0400, Scott Kostyshak wrote: > On Thu, Sep 10, 2020 at 12:22:03PM -0400, Richard Kimberly Heck wrote: > > On 9/10/20 11:52 AM, Scott Kostyshak wrote: > >> On Thu, May 16, 2019 at 07:54:41PM +0200, Scott Kostyshak wrote: > >>> commit 9ab9f2b1acb8bc1a40d5a69737b43d09b7f7a597 > >>> Author: Scott Kostyshak > >>> Date: Thu May 16 13:58:18 2019 -0400 > >>> > >>> Tab binding: outline-in before depth-increment > >>> > >>> Same for BackTab. The outline-in was originally (31398779) > >>> introduced to the command-sequence at the end. Probably it was > >>> placed at the end to be conservative (i.e., so that it would only > >>> change behavior where there was a no-op before). > >>> > >>> This fixes #11576. > >>> --- > >>> lib/bind/site.bind |4 ++-- > >>> 1 files changed, 2 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/lib/bind/site.bind b/lib/bind/site.bind > >>> index 4c3c609..615c685 100644 > >>> --- a/lib/bind/site.bind > >>> +++ b/lib/bind/site.bind > >>> @@ -27,10 +27,10 @@ Format 5 > >>> \bind "Up" "up" > >>> \bind "Down" "down" > >>> > >>> -\bind "Tab""command-alternatives > >>> completion-accept;cell-forward;tab-insert;depth-increment;outline-in" > >>> +\bind "Tab""command-alternatives > >>> completion-accept;cell-forward;tab-insert;outline-in;depth-increment" > >>> \bind "C-Tab" "cell-split" > >>> \bind "~S-ISO_Left_Tab""cell-backward" > >>> -\bind "~S-BackTab" "command-alternatives > >>> cell-backward;tab-delete;depth-decrement;outline-out" > >>> +\bind "~S-BackTab" "command-alternatives > >>> cell-backward;tab-delete;outline-out;depth-decrement" > >> This commit introduced a regression (also in stable). To reproduce: > >> > >> 1. open the attached file. > >> 2. convert the "standard" layout to "frame" (it will be nested). > >> 3. try to unnest the frame with shift+tab. > >> > >> Result: on 2.3.x and master, it becomes a subsubsection. On 2.3.0, it > >> has the expected (to me) result of unnesting the frame. > >> > >> The reason for the 2.3.x behavior is because of the change of order of > >> the command alternatives in this commit. outline-out succeeds. From > >> what > >> I understand, outline-out succeeds because in the Frame layout, the > >> TocLevel is set. > >> > >> If we revert this commit, we reintroduce #11576. > >> > >> I don't know much about layouts so I'm not sure what the best approach > >> is. > > One possible solution would be a new layout tag: ProhibitNesting, off by > > default. > From the little that I understand, that would be great and would prevent > the user from getting into situations they likely don't want (e.g., > having a section nested in a frame). > >>> I think adding the layout tag would be ideal. However, I don't have the > >>> time to look into that. > >>> > >>> Should I revert the commit and reintroduce #11576? > >> Tell me what layout tag you need. I can add it very easily. > > It would be nice to get someone else's feedback (Jürgen?) before you > > work on it. I see a few possibilities: > > > > 1. A tag that does not allow layouts to nest other layouts of the same > >type. > > > > 2. A tag that does not allow a layout to be nested at all. > > > > 3. A tag that is similar to the "AutoNests" tag, where we can list all > >of the layouts that a layout should not nest (or should not be nested > > by?). > > > > (3) is the most general so my initial guess is that's the way to go. I > > like your name for the tag that you proposed earlier, ProhibitNesting. > > Note that we can separate two tasks here: getting the tag itself into > the code and then actually making it do something. There have been times > we did the former without doing the latter because we were too close to > release and didn't have time but didn't want to wait for another major > release, either. Ah I forgot about that possibility. In that case we would just have to figure out the name. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Add move constructor and move assignment operator for FileName class
On 1/6/21 7:33 PM, Yuriy Skalko wrote: > This should reduce memory allocations for this heavily used class. I don't know enough about this stuff to say much. I think this would be worth doing for 2.4.0, as it will probably provide for some speed as well. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Tab binding: outline-in before depth-increment
On 1/8/21 8:32 PM, Scott Kostyshak wrote: > On Fri, Jan 08, 2021 at 08:05:00PM -0500, Richard Kimberly Heck wrote: >> On 1/8/21 5:59 PM, Scott Kostyshak wrote: >>> On Fri, Sep 11, 2020 at 02:30:00PM -0400, Scott Kostyshak wrote: On Thu, Sep 10, 2020 at 12:22:03PM -0400, Richard Kimberly Heck wrote: > On 9/10/20 11:52 AM, Scott Kostyshak wrote: >> On Thu, May 16, 2019 at 07:54:41PM +0200, Scott Kostyshak wrote: >>> commit 9ab9f2b1acb8bc1a40d5a69737b43d09b7f7a597 >>> Author: Scott Kostyshak >>> Date: Thu May 16 13:58:18 2019 -0400 >>> >>> Tab binding: outline-in before depth-increment >>> >>> Same for BackTab. The outline-in was originally (31398779) >>> introduced to the command-sequence at the end. Probably it was >>> placed at the end to be conservative (i.e., so that it would only >>> change behavior where there was a no-op before). >>> >>> This fixes #11576. >>> --- >>> lib/bind/site.bind |4 ++-- >>> 1 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/lib/bind/site.bind b/lib/bind/site.bind >>> index 4c3c609..615c685 100644 >>> --- a/lib/bind/site.bind >>> +++ b/lib/bind/site.bind >>> @@ -27,10 +27,10 @@ Format 5 >>> \bind "Up" "up" >>> \bind "Down" "down" >>> >>> -\bind "Tab""command-alternatives >>> completion-accept;cell-forward;tab-insert;depth-increment;outline-in" >>> +\bind "Tab""command-alternatives >>> completion-accept;cell-forward;tab-insert;outline-in;depth-increment" >>> \bind "C-Tab" "cell-split" >>> \bind "~S-ISO_Left_Tab""cell-backward" >>> -\bind "~S-BackTab" "command-alternatives >>> cell-backward;tab-delete;depth-decrement;outline-out" >>> +\bind "~S-BackTab" "command-alternatives >>> cell-backward;tab-delete;outline-out;depth-decrement" >> This commit introduced a regression (also in stable). To reproduce: >> >> 1. open the attached file. >> 2. convert the "standard" layout to "frame" (it will be nested). >> 3. try to unnest the frame with shift+tab. >> >> Result: on 2.3.x and master, it becomes a subsubsection. On 2.3.0, it >> has the expected (to me) result of unnesting the frame. >> >> The reason for the 2.3.x behavior is because of the change of order of >> the command alternatives in this commit. outline-out succeeds. From what >> I understand, outline-out succeeds because in the Frame layout, the >> TocLevel is set. >> >> If we revert this commit, we reintroduce #11576. >> >> I don't know much about layouts so I'm not sure what the best approach >> is. > One possible solution would be a new layout tag: ProhibitNesting, off by > default. From the little that I understand, that would be great and would prevent the user from getting into situations they likely don't want (e.g., having a section nested in a frame). >>> I think adding the layout tag would be ideal. However, I don't have the >>> time to look into that. >>> >>> Should I revert the commit and reintroduce #11576? >> Tell me what layout tag you need. I can add it very easily. > It would be nice to get someone else's feedback (Jürgen?) before you > work on it. I see a few possibilities: > > 1. A tag that does not allow layouts to nest other layouts of the same >type. > > 2. A tag that does not allow a layout to be nested at all. > > 3. A tag that is similar to the "AutoNests" tag, where we can list all >of the layouts that a layout should not nest (or should not be nested by?). > > (3) is the most general so my initial guess is that's the way to go. I > like your name for the tag that you proposed earlier, ProhibitNesting. Note that we can separate two tasks here: getting the tag itself into the code and then actually making it do something. There have been times we did the former without doing the latter because we were too close to release and didn't have time but didn't want to wait for another major release, either. Tags are cheap, so we can add more than one if need be. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Tab binding: outline-in before depth-increment
On Fri, Jan 08, 2021 at 08:05:00PM -0500, Richard Kimberly Heck wrote: > On 1/8/21 5:59 PM, Scott Kostyshak wrote: > > On Fri, Sep 11, 2020 at 02:30:00PM -0400, Scott Kostyshak wrote: > >> On Thu, Sep 10, 2020 at 12:22:03PM -0400, Richard Kimberly Heck wrote: > >>> On 9/10/20 11:52 AM, Scott Kostyshak wrote: > On Thu, May 16, 2019 at 07:54:41PM +0200, Scott Kostyshak wrote: > > commit 9ab9f2b1acb8bc1a40d5a69737b43d09b7f7a597 > > Author: Scott Kostyshak > > Date: Thu May 16 13:58:18 2019 -0400 > > > > Tab binding: outline-in before depth-increment > > > > Same for BackTab. The outline-in was originally (31398779) > > introduced to the command-sequence at the end. Probably it was > > placed at the end to be conservative (i.e., so that it would only > > change behavior where there was a no-op before). > > > > This fixes #11576. > > --- > > lib/bind/site.bind |4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/lib/bind/site.bind b/lib/bind/site.bind > > index 4c3c609..615c685 100644 > > --- a/lib/bind/site.bind > > +++ b/lib/bind/site.bind > > @@ -27,10 +27,10 @@ Format 5 > > \bind "Up" "up" > > \bind "Down" "down" > > > > -\bind "Tab""command-alternatives > > completion-accept;cell-forward;tab-insert;depth-increment;outline-in" > > +\bind "Tab""command-alternatives > > completion-accept;cell-forward;tab-insert;outline-in;depth-increment" > > \bind "C-Tab" "cell-split" > > \bind "~S-ISO_Left_Tab""cell-backward" > > -\bind "~S-BackTab" "command-alternatives > > cell-backward;tab-delete;depth-decrement;outline-out" > > +\bind "~S-BackTab" "command-alternatives > > cell-backward;tab-delete;outline-out;depth-decrement" > This commit introduced a regression (also in stable). To reproduce: > > 1. open the attached file. > 2. convert the "standard" layout to "frame" (it will be nested). > 3. try to unnest the frame with shift+tab. > > Result: on 2.3.x and master, it becomes a subsubsection. On 2.3.0, it > has the expected (to me) result of unnesting the frame. > > The reason for the 2.3.x behavior is because of the change of order of > the command alternatives in this commit. outline-out succeeds. From what > I understand, outline-out succeeds because in the Frame layout, the > TocLevel is set. > > If we revert this commit, we reintroduce #11576. > > I don't know much about layouts so I'm not sure what the best approach > is. > >>> One possible solution would be a new layout tag: ProhibitNesting, off by > >>> default. > >> From the little that I understand, that would be great and would prevent > >> the user from getting into situations they likely don't want (e.g., > >> having a section nested in a frame). > > I think adding the layout tag would be ideal. However, I don't have the > > time to look into that. > > > > Should I revert the commit and reintroduce #11576? > > Tell me what layout tag you need. I can add it very easily. It would be nice to get someone else's feedback (Jürgen?) before you work on it. I see a few possibilities: 1. A tag that does not allow layouts to nest other layouts of the same type. 2. A tag that does not allow a layout to be nested at all. 3. A tag that is similar to the "AutoNests" tag, where we can list all of the layouts that a layout should not nest (or should not be nested by?). (3) is the most general so my initial guess is that's the way to go. I like your name for the tag that you proposed earlier, ProhibitNesting. Thank you for helping with this! 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] Tab binding: outline-in before depth-increment
On 1/8/21 5:59 PM, Scott Kostyshak wrote: > On Fri, Sep 11, 2020 at 02:30:00PM -0400, Scott Kostyshak wrote: >> On Thu, Sep 10, 2020 at 12:22:03PM -0400, Richard Kimberly Heck wrote: >>> On 9/10/20 11:52 AM, Scott Kostyshak wrote: On Thu, May 16, 2019 at 07:54:41PM +0200, Scott Kostyshak wrote: > commit 9ab9f2b1acb8bc1a40d5a69737b43d09b7f7a597 > Author: Scott Kostyshak > Date: Thu May 16 13:58:18 2019 -0400 > > Tab binding: outline-in before depth-increment > > Same for BackTab. The outline-in was originally (31398779) > introduced to the command-sequence at the end. Probably it was > placed at the end to be conservative (i.e., so that it would only > change behavior where there was a no-op before). > > This fixes #11576. > --- > lib/bind/site.bind |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lib/bind/site.bind b/lib/bind/site.bind > index 4c3c609..615c685 100644 > --- a/lib/bind/site.bind > +++ b/lib/bind/site.bind > @@ -27,10 +27,10 @@ Format 5 > \bind "Up" "up" > \bind "Down" "down" > > -\bind "Tab""command-alternatives > completion-accept;cell-forward;tab-insert;depth-increment;outline-in" > +\bind "Tab""command-alternatives > completion-accept;cell-forward;tab-insert;outline-in;depth-increment" > \bind "C-Tab" "cell-split" > \bind "~S-ISO_Left_Tab""cell-backward" > -\bind "~S-BackTab" "command-alternatives > cell-backward;tab-delete;depth-decrement;outline-out" > +\bind "~S-BackTab" "command-alternatives > cell-backward;tab-delete;outline-out;depth-decrement" This commit introduced a regression (also in stable). To reproduce: 1. open the attached file. 2. convert the "standard" layout to "frame" (it will be nested). 3. try to unnest the frame with shift+tab. Result: on 2.3.x and master, it becomes a subsubsection. On 2.3.0, it has the expected (to me) result of unnesting the frame. The reason for the 2.3.x behavior is because of the change of order of the command alternatives in this commit. outline-out succeeds. From what I understand, outline-out succeeds because in the Frame layout, the TocLevel is set. If we revert this commit, we reintroduce #11576. I don't know much about layouts so I'm not sure what the best approach is. >>> One possible solution would be a new layout tag: ProhibitNesting, off by >>> default. >> From the little that I understand, that would be great and would prevent >> the user from getting into situations they likely don't want (e.g., >> having a section nested in a frame). > I think adding the layout tag would be ideal. However, I don't have the time > to look into that. > > Should I revert the commit and reintroduce #11576? Tell me what layout tag you need. I can add it very easily. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Move handling of LFUN_COPY to BufferView
Le 08/01/2021 à 22:44, Kornel Benko a écrit : Am Fri, 8 Jan 2021 21:27:28 +0100 schrieb Jean-Marc Lasgouttes : Le 08/01/2021 à 19:59, Kornel Benko a écrit : Thanks, works nice. The same issue is also still in display of 'Table of Contents'. Would you mind to check this too? Nonetheless, the situation now is much better with your change. Yes, Open Table of Contents click there on chapter (or section or subsection, ...) ==> TOC will be rebuild 3 to 4 times. The effect is awkward flickering of TOC This is with QT 5.9.5. Compiled with QT4.8 ==> no such effect (no visible rebuild, no flicker) (Just rechecked) Oh, so it is the same issue but totally different :) I can take a look, but I have more at ease with weirdness in our code than weirdness in Qt. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Move handling of LFUN_COPY to BufferView
Am Fri, 8 Jan 2021 22:44:57 +0100 schrieb Kornel Benko : > Am Fri, 8 Jan 2021 21:27:28 +0100 > schrieb Jean-Marc Lasgouttes : > > > Le 08/01/2021 à 19:59, Kornel Benko a écrit : > > > Thanks, works nice. The same issue is also still in display of 'Table of > > > Contents'. > > > > > > Would you mind to check this too? Nonetheless, the situation now is much > > > better > > > with your change. > > > > Can you be more specific? > > > > JMarc > > Yes, > Open Table of Contents > click there on chapter (or section or subsection, ...) > ==> TOC will be rebuild 3 to 4 times. The effect is awkward flickering of TOC > > > This is with QT 5.9.5. > Compiled with QT4.8 ==> no such effect (no visible rebuild, no flicker) > (Just rechecked) > > Kornel For what is worth, bug #11660 describes it too. Kornel pgpvnKV1zPSsk.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Tab binding: outline-in before depth-increment
On Fri, Sep 11, 2020 at 02:30:00PM -0400, Scott Kostyshak wrote: > On Thu, Sep 10, 2020 at 12:22:03PM -0400, Richard Kimberly Heck wrote: > > On 9/10/20 11:52 AM, Scott Kostyshak wrote: > > > On Thu, May 16, 2019 at 07:54:41PM +0200, Scott Kostyshak wrote: > > >> commit 9ab9f2b1acb8bc1a40d5a69737b43d09b7f7a597 > > >> Author: Scott Kostyshak > > >> Date: Thu May 16 13:58:18 2019 -0400 > > >> > > >> Tab binding: outline-in before depth-increment > > >> > > >> Same for BackTab. The outline-in was originally (31398779) > > >> introduced to the command-sequence at the end. Probably it was > > >> placed at the end to be conservative (i.e., so that it would only > > >> change behavior where there was a no-op before). > > >> > > >> This fixes #11576. > > >> --- > > >> lib/bind/site.bind |4 ++-- > > >> 1 files changed, 2 insertions(+), 2 deletions(-) > > >> > > >> diff --git a/lib/bind/site.bind b/lib/bind/site.bind > > >> index 4c3c609..615c685 100644 > > >> --- a/lib/bind/site.bind > > >> +++ b/lib/bind/site.bind > > >> @@ -27,10 +27,10 @@ Format 5 > > >> \bind "Up" "up" > > >> \bind "Down" "down" > > >> > > >> -\bind "Tab""command-alternatives > > >> completion-accept;cell-forward;tab-insert;depth-increment;outline-in" > > >> +\bind "Tab""command-alternatives > > >> completion-accept;cell-forward;tab-insert;outline-in;depth-increment" > > >> \bind "C-Tab" "cell-split" > > >> \bind "~S-ISO_Left_Tab""cell-backward" > > >> -\bind "~S-BackTab" "command-alternatives > > >> cell-backward;tab-delete;depth-decrement;outline-out" > > >> +\bind "~S-BackTab" "command-alternatives > > >> cell-backward;tab-delete;outline-out;depth-decrement" > > > This commit introduced a regression (also in stable). To reproduce: > > > > > > 1. open the attached file. > > > 2. convert the "standard" layout to "frame" (it will be nested). > > > 3. try to unnest the frame with shift+tab. > > > > > > Result: on 2.3.x and master, it becomes a subsubsection. On 2.3.0, it > > > has the expected (to me) result of unnesting the frame. > > > > > > The reason for the 2.3.x behavior is because of the change of order of > > > the command alternatives in this commit. outline-out succeeds. From what > > > I understand, outline-out succeeds because in the Frame layout, the > > > TocLevel is set. > > > > > > If we revert this commit, we reintroduce #11576. > > > > > > I don't know much about layouts so I'm not sure what the best approach > > > is. > > > > One possible solution would be a new layout tag: ProhibitNesting, off by > > default. > > From the little that I understand, that would be great and would prevent > the user from getting into situations they likely don't want (e.g., > having a section nested in a frame). I think adding the layout tag would be ideal. However, I don't have the time to look into that. Should I revert the commit and reintroduce #11576? 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] Move handling of LFUN_COPY to BufferView
Am Fri, 8 Jan 2021 21:27:28 +0100 schrieb Jean-Marc Lasgouttes : > Le 08/01/2021 à 19:59, Kornel Benko a écrit : > > Thanks, works nice. The same issue is also still in display of 'Table of > > Contents'. > > > > Would you mind to check this too? Nonetheless, the situation now is much > > better > > with your change. > > Can you be more specific? > > JMarc Yes, Open Table of Contents click there on chapter (or section or subsection, ...) ==> TOC will be rebuild 3 to 4 times. The effect is awkward flickering of TOC This is with QT 5.9.5. Compiled with QT4.8 ==> no such effect (no visible rebuild, no flicker) (Just rechecked) Kornel pgp6HQklpap4i.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Display bookmarks in the workarea.
Le 08/01/2021 à 18:07, Kornel Benko a écrit : But I see the point. OTOH, if you have a good idea of a unicode character that helps understand that this is a bookmark, this might be useful. U+1f516 ? No emoji, unfortunately. I also tried an anchor symbol. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Move handling of LFUN_COPY to BufferView
Le 08/01/2021 à 19:59, Kornel Benko a écrit : Thanks, works nice. The same issue is also still in display of 'Table of Contents'. Would you mind to check this too? Nonetheless, the situation now is much better with your change. Can you be more specific? JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Move handling of LFUN_COPY to BufferView
Am Fri, 8 Jan 2021 19:31:38 +0100 (CET) schrieb Jean-Marc Lasgouttes : > commit 9e1db65932b895778525c48d524adfad2ae37739 > Author: Jean-Marc Lasgouttes > Date: Fri Jan 8 19:27:19 2021 +0100 > > Move handling of LFUN_COPY to BufferView > > It turns out that the code is the same in texted ans mathed and that > whatever is done in InsetTabular is not useful. > > This means that we do not need to deal Text::dispatch idiosyncrasies > (in particular forcing the cursor to be visible). > > Fix bug #11225. Thanks, works nice. The same issue is also still in display of 'Table of Contents'. Would you mind to check this too? Nonetheless, the situation now is much better with your change. Kornel pgplu9ZvtOq_R.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] FindAdv: Save sub-matches in MatchStringAdv class
Am Fri, 08 Jan 2021 12:15:00 +0100 schrieb Jürgen Spitzmüller : > Am Freitag, dem 08.01.2021 um 12:10 +0100 schrieb Kornel Benko: > > commit c3cda5ffd4e17d79c8fb09a2b122efa959418885 > > Author: Kornel Benko > > Date: Fri Jan 8 12:05:51 2021 +0100 > > > > FindAdv: Save sub-matches in MatchStringAdv class > > > > Prepare for use while replacing: > > (backslashed numbers in the replace buffer should be replaced > > with the relevant > > sub-matched strings.) > > Cool! > > Jürgen > Thanks, unfortunately I need help. 1.) How to get the text-part (docstring or utf8) from replace buffer and 2.) how to write modified text to lyx-buffer Kornel pgpDqKAOOhYA8.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Display bookmarks in the workarea.
Am Fri, 8 Jan 2021 18:07:15 +0100 schrieb Kornel Benko : > Am Fri, 8 Jan 2021 15:57:38 +0100 > schrieb Jean-Marc Lasgouttes : > > > Le 08/01/2021 à 14:16, Pavel Sanda a écrit : > > > On Wed, Jan 06, 2021 at 08:32:50PM +0100, Jean-Marc Lasgouttes wrote: > > >> Please try it out even if you are not big users of bookmarks. I do not > > >> use > > >> them myself, so I do not know what a good UI is. > > > > > > I think it should have tootltip saying it's bookmark, otherwise it migh > > > be confusing for someone randomly encoutering this element. > > > > We do not have support for that currently. Tootips are for insets. > > > > But I see the point. OTOH, if you have a good idea of a unicode > > character that helps understand that this is a bookmark, this might be > > useful. > > > > JMarc > > U+1f516 ? > > Kornel Interestingly 'vi' can display the char, while lyx does not. Not many fonts have it: Font : Emoji One Regular [ADBO] Font : Hana Min A Regular [PfEd] Font : Noto Color Emoji Regular [GOOG] Font : Noto Emoji Regular [GOOG] Font : Symbola Regular [Free] Font : fontello Medium [PfEd] and only "Symbola Regular" and "Hana Min A Regular" contain also ascii Kornel pgpg3Z2xFPvc2.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Display bookmarks in the workarea.
Am Fri, 8 Jan 2021 15:57:38 +0100 schrieb Jean-Marc Lasgouttes : > Le 08/01/2021 à 14:16, Pavel Sanda a écrit : > > On Wed, Jan 06, 2021 at 08:32:50PM +0100, Jean-Marc Lasgouttes wrote: > >> Please try it out even if you are not big users of bookmarks. I do not use > >> them myself, so I do not know what a good UI is. > > > > I think it should have tootltip saying it's bookmark, otherwise it migh > > be confusing for someone randomly encoutering this element. > > We do not have support for that currently. Tootips are for insets. > > But I see the point. OTOH, if you have a good idea of a unicode > character that helps understand that this is a bookmark, this might be > useful. > > JMarc U+1f516 ? Kornel pgpmfaDa8KiPD.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Legacy graphics conversion problems
Le 08/01/2021 à 16:50, José Abílio Matos a écrit : On Tuesday, January 5, 2021 5:10:13 PM WET Jean-Marc Lasgouttes wrote: > José, what is the status on this? Honestly? Since I am not masochist I do not play with hornets nests. :-) So as far I remember the issue is: is there any reason in 2021 not to use dvipng? I have no idea about that, but I al the kind of guy who thinks that we do not care about dvi file... Try to put your hand in this nest. Maybe these are not hornets, after all :) JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Legacy graphics conversion problems
On Tuesday, January 5, 2021 5:10:13 PM WET Jean-Marc Lasgouttes wrote: > Le 13/06/2019 à 17:41, José Abílio Matos a écrit : > > Last week while working with python2/python3 differences I found clues > > that > > the legacy graphics conversion has problems. > > > > Like I said in bugs #11457 and #11282: > > "This also means that the legacy conversion has some issues but I think > > that by now everyone should be using dvipng to that part of the code is > > not used." > > > > So my question now is if we should, or not, make dvipng is a requirement > > for the instant preview mode. > > > > What do you think? > > José, what is the status on this? > > JMarc Honestly? Since I am not masochist I do not play with hornets nests. :-) Actually once I was with Sara and she was attacked and stung three times in less than a few seconds, I did not even notice until a minute later... So as far I remember the issue is: is there any reason in 2021 not to use dvipng? -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Virtual meetings
On Monday, January 4, 2021 7:27:12 PM WET Richard Kimberly Heck wrote: > That works for me. > > > I could send zoom invitiation if you all are ok with that. Otherwise > > suggest your tool and manage the managment side of the meeting. > > Also fine by me. This is fine with me. I will be there. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Display bookmarks in the workarea.
Le 08/01/2021 à 14:16, Pavel Sanda a écrit : On Wed, Jan 06, 2021 at 08:32:50PM +0100, Jean-Marc Lasgouttes wrote: Please try it out even if you are not big users of bookmarks. I do not use them myself, so I do not know what a good UI is. I think it should have tootltip saying it's bookmark, otherwise it migh be confusing for someone randomly encoutering this element. We do not have support for that currently. Tootips are for insets. But I see the point. OTOH, if you have a good idea of a unicode character that helps understand that this is a bookmark, this might be useful. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Display bookmarks in the workarea.
On Wed, Jan 06, 2021 at 08:32:50PM +0100, Jean-Marc Lasgouttes wrote: > Please try it out even if you are not big users of bookmarks. I do not use > them myself, so I do not know what a good UI is. I think it should have tootltip saying it's bookmark, otherwise it migh be confusing for someone randomly encoutering this element. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] FindAdv: Save sub-matches in MatchStringAdv class
Am Freitag, dem 08.01.2021 um 12:10 +0100 schrieb Kornel Benko: > commit c3cda5ffd4e17d79c8fb09a2b122efa959418885 > Author: Kornel Benko > Date: Fri Jan 8 12:05:51 2021 +0100 > > FindAdv: Save sub-matches in MatchStringAdv class > > Prepare for use while replacing: > (backslashed numbers in the replace buffer should be replaced > with the relevant > sub-matched strings.) Cool! 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
Howto modify selection from replace buffer (FindAdv)
I have problems to _use_ matched substrings in replace-mode.
For instance given regular expression containing some groups, like
'()()()'
and I want to change the found value to '', so in regex I would
write
'\3\2\1'
Now the selection contains '\3\2\1', this is selected (in
lyxfind.cpp:findAdvReplace())
with
cap::pasteParagraphList(cur, repl_buffer.paragraphs(),
repl_buffer.params().documentClassPtr(),
bv->buffer().errorList("Paste"));
LYXERR(Debug::FIND, "After pasteParagraphList() cur=" << cur <<
endl);
sel_len = repl_buffer.paragraphs().begin()->size();
and then follows
bv->putSelectionAt(DocIterator(cur), sel_len, !opt.forward);
bv->processUpdateFlags(Update::Force);
How can I modify the data prior to inserting into buffer ?
The values of '\1', '\2', '\3' are known here, but are not used.
Kornel
pgpa0hgnxFIE_.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Arabic Beamer template
Am Donnerstag, dem 07.01.2021 um 19:09 -0500 schrieb Scott Kostyshak: > Jürgen, is this a languages-switching issue? I remember those issues > are often very tricky to fix. No, errors in the document. These are fixed, and the document compiles. But the output does not look good. I think the author should look if the beamer-rl class improves things. As the documentation is written in Arabic, I cannot help here. 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
