Re: [RFC] Simple Search to Bottom Dock
On Tue, Feb 16, 2021 at 07:34:27AM +0100, Jürgen Spitzmüller wrote: > Am Montag, dem 15.02.2021 um 21:51 +0100 schrieb Pavel Sanda: > > Next weird issue - enter on my numeric keypad stopped to work with > > the new > > UI. Can you reproduce? > > No. Strange, fixed now. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 21:51 +0100 schrieb Pavel Sanda: > Next weird issue - enter on my numeric keypad stopped to work with > the new > UI. Can you reproduce? No. 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
Re: Citation UI Regression
Am Montag, dem 15.02.2021 um 12:17 -0500 schrieb Richard Kimberly Heck: > If I have multiple citations, then changing their order does not > activate the OK and Apply buttons, and it does not update the display > in > the lower part of the dialog, either. Worse, even if I do something > else > (like change the before field) to activate the buttons, the change of > order does not have any effect. Should be fixed. 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
Re: Citation UI Regression
On 2/15/21 12:17 PM, Richard Kimberly Heck wrote: > If I have multiple citations, then changing their order does not > activate the OK and Apply buttons, and it does not update the display > in the lower part of the dialog, either. Worse, even if I do something > else (like change the before field) to activate the buttons, the > change of order does not have any effect. I spent some time trying to figure this out. But it did not go well I can try to bisect soon... Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
On Mon, Feb 15, 2021 at 09:46:23AM +0100, Jürgen Spitzmüller wrote: > Am Sonntag, dem 14.02.2021 um 22:54 +0100 schrieb Pavel Sanda: > > Another glitch: F3 in search pane goes forward, F3 in edit area goes > > backward. > > Should be fixed. > > Please verify. It works now, thanks. Next weird issue - enter on my numeric keypad stopped to work with the new UI. Can you reproduce? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Citation UI Regression
If I have multiple citations, then changing their order does not activate the OK and Apply buttons, and it does not update the display in the lower part of the dialog, either. Worse, even if I do something else (like change the before field) to activate the buttons, the change of order does not have any effect. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] #8055 use standard shortcut for font-emph on Mac
On Mon, Feb 15, 2021 at 11:20:35AM -0500, Richard Kimberly Heck wrote: > On 2/15/21 10:36 AM, Scott Kostyshak wrote: > > On Mon, Feb 15, 2021 at 10:31:38AM -0500, Richard Kimberly Heck wrote: > >> On 2/15/21 10:24 AM, Scott Kostyshak wrote: > >>> On Mon, Feb 15, 2021 at 09:32:01AM +0100, Stephan Witt wrote: > commit a9342ae098024e363891653d1bcf7a8d485a271c > Author: Stephan Witt > Date: Mon Feb 15 09:35:31 2021 +0100 > > #8055 use standard shortcut for font-emph on Mac > --- > lib/bind/mac.bind |5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/lib/bind/mac.bind b/lib/bind/mac.bind > index 8d54e4c..531465b 100644 > --- a/lib/bind/mac.bind > +++ b/lib/bind/mac.bind > @@ -141,7 +141,6 @@ Format 5 > \bind "C-S-D""buffer-update dvi"# 'd' > for dvi > # +: "Command-E"# Use the selection for a find > \bind "C-e" "search-string-set" > -\bind "C-M-e""font-emph" > # +: "Command-F"# Open a Find window > \bind "C-f" "dialog-toggle findreplace" > \bind "C-S-f""dialog-toggle findreplaceadv" > @@ -152,8 +151,8 @@ Format 5 > \bind "C-S-g""word-find-backward" > # +: "Command-H"# Hide the windows of the > currently running application > # +: "Option-Command-H" # Hide the windows of all other > running applications > -# -: "Command-I"# Italicize the selected text or > toggle italic text on or off > -\bind "C-i" "inset-toggle" # 'i' for Inset > +# +: "Command-I"# Italicize the selected text or > toggle italic text on or off > +\bind "C-i" "command-alternatives > inset-toggle; font-emph" # 'i' for Inset > \bind "C-M-i""inset-settings" > # -: "Option-Command-I" # Display an inspector window > # -: "Command-J"# Scroll to a selection > >>> I think this could have problems when both inset-toggle and font-emph > >>> are valid. For example, create a footnote and write text inside. Then > >>> put the cursor inside and run the command-alternatives. > >>> > >>> I don't think the C-e binding is a Linux/Windows-specific binding. > >>> Rather, I think it's a LaTeX thing. I believe the idea is that the user > >>> or document class can redefine what it means to "emphasize" text from > >>> italics to something else. > >>> > >>> I do think that a fair amount new users are confused by C-e (instead of > >>> C-i), but I have surprisingly seen few complaints so perhaps adapting is > >>> not too difficult. > >> Good catch. Stephan, I think it would be fine to re-assign inset-toggle. > >> I don't think it works terribly reliably anyway. > > I use inset-toggle often. Can you remember a specific situation where it > > is not reliable? > > I was thinking of use in front of insets like citations. > > But I didn't mean to get rid of it, just to re-assign it. I think most > users would expect Ctrl-I to do emphasis. Indeed, I've swapped Ctrl-I > and Ctrl-E locally. I see, that makes sense. 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] #8055 use standard shortcut for font-emph on Mac
On 2/15/21 10:36 AM, Scott Kostyshak wrote: > On Mon, Feb 15, 2021 at 10:31:38AM -0500, Richard Kimberly Heck wrote: >> On 2/15/21 10:24 AM, Scott Kostyshak wrote: >>> On Mon, Feb 15, 2021 at 09:32:01AM +0100, Stephan Witt wrote: commit a9342ae098024e363891653d1bcf7a8d485a271c Author: Stephan Witt Date: Mon Feb 15 09:35:31 2021 +0100 #8055 use standard shortcut for font-emph on Mac --- lib/bind/mac.bind |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/lib/bind/mac.bind b/lib/bind/mac.bind index 8d54e4c..531465b 100644 --- a/lib/bind/mac.bind +++ b/lib/bind/mac.bind @@ -141,7 +141,6 @@ Format 5 \bind "C-S-D""buffer-update dvi" # 'd' for dvi # +: "Command-E"# Use the selection for a find \bind "C-e" "search-string-set" -\bind "C-M-e""font-emph" # +: "Command-F"# Open a Find window \bind "C-f" "dialog-toggle findreplace" \bind "C-S-f""dialog-toggle findreplaceadv" @@ -152,8 +151,8 @@ Format 5 \bind "C-S-g""word-find-backward" # +: "Command-H"# Hide the windows of the currently running application # +: "Option-Command-H" # Hide the windows of all other running applications -# -: "Command-I"# Italicize the selected text or toggle italic text on or off -\bind "C-i" "inset-toggle" # 'i' for Inset +# +: "Command-I"# Italicize the selected text or toggle italic text on or off +\bind "C-i" "command-alternatives inset-toggle; font-emph" # 'i' for Inset \bind "C-M-i""inset-settings" # -: "Option-Command-I" # Display an inspector window # -: "Command-J"# Scroll to a selection >>> I think this could have problems when both inset-toggle and font-emph >>> are valid. For example, create a footnote and write text inside. Then >>> put the cursor inside and run the command-alternatives. >>> >>> I don't think the C-e binding is a Linux/Windows-specific binding. >>> Rather, I think it's a LaTeX thing. I believe the idea is that the user >>> or document class can redefine what it means to "emphasize" text from >>> italics to something else. >>> >>> I do think that a fair amount new users are confused by C-e (instead of >>> C-i), but I have surprisingly seen few complaints so perhaps adapting is >>> not too difficult. >> Good catch. Stephan, I think it would be fine to re-assign inset-toggle. >> I don't think it works terribly reliably anyway. > I use inset-toggle often. Can you remember a specific situation where it > is not reliable? I was thinking of use in front of insets like citations. But I didn't mean to get rid of it, just to re-assign it. I think most users would expect Ctrl-I to do emphasis. Indeed, I've swapped Ctrl-I and Ctrl-E locally. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] #8055 use standard shortcut for font-emph on Mac
On Mon, Feb 15, 2021 at 04:51:42PM +0100, Stephan Witt wrote: > Am 15.02.2021 um 16:36 schrieb Scott Kostyshak : > > > > On Mon, Feb 15, 2021 at 10:31:38AM -0500, Richard Kimberly Heck wrote: > >> On 2/15/21 10:24 AM, Scott Kostyshak wrote: > >>> On Mon, Feb 15, 2021 at 09:32:01AM +0100, Stephan Witt wrote: > commit a9342ae098024e363891653d1bcf7a8d485a271c > Author: Stephan Witt > Date: Mon Feb 15 09:35:31 2021 +0100 > > #8055 use standard shortcut for font-emph on Mac > --- > lib/bind/mac.bind |5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > >>> I think this could have problems when both inset-toggle and font-emph > >>> are valid. For example, create a footnote and write text inside. Then > >>> put the cursor inside and run the command-alternatives. > >>> > >>> I don't think the C-e binding is a Linux/Windows-specific binding. > >>> Rather, I think it's a LaTeX thing. I believe the idea is that the user > >>> or document class can redefine what it means to "emphasize" text from > >>> italics to something else. > >>> > >>> I do think that a fair amount new users are confused by C-e (instead of > >>> C-i), but I have surprisingly seen few complaints so perhaps adapting is > >>> not too difficult. > >> > >> Good catch. Stephan, I think it would be fine to re-assign inset-toggle. > >> I don't think it works terribly reliably anyway. > > > > I use inset-toggle often. Can you remember a specific situation where it > > is not reliable? > > > > I would prefer not to assign emph to C-i, but if we do decide to do it I > > think we should do it for all platforms. I don't think this is a > > platform-specific thing. > > I’ve reverted it for now. Thanks. > Emphasize text parts isn’t exactly the same as the change to italics. > So it’s indeed disputable to use Command-I here. > > The use of Command-E for search-string-save on Mac is in par with behavior of > many important applications now, AFAIK. I’d like to stay with the change. > Emphasize text parts (font-emph) is changed to Command-Shift-E now. > > The OP of the bug #8055 mentioned the „broken“ binding for Command-E > explicitly. I see, thanks for summarizing the ticket. So the main point was moving away from C-e, where I thought the main point was moving *to* C-i. Good to know! I see now it is platform-specific and I don't have an objection. 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] #8055 use standard shortcut for font-emph on Mac
Am 15.02.2021 um 16:36 schrieb Scott Kostyshak : > > On Mon, Feb 15, 2021 at 10:31:38AM -0500, Richard Kimberly Heck wrote: >> On 2/15/21 10:24 AM, Scott Kostyshak wrote: >>> On Mon, Feb 15, 2021 at 09:32:01AM +0100, Stephan Witt wrote: commit a9342ae098024e363891653d1bcf7a8d485a271c Author: Stephan Witt Date: Mon Feb 15 09:35:31 2021 +0100 #8055 use standard shortcut for font-emph on Mac --- lib/bind/mac.bind |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) >>> I think this could have problems when both inset-toggle and font-emph >>> are valid. For example, create a footnote and write text inside. Then >>> put the cursor inside and run the command-alternatives. >>> >>> I don't think the C-e binding is a Linux/Windows-specific binding. >>> Rather, I think it's a LaTeX thing. I believe the idea is that the user >>> or document class can redefine what it means to "emphasize" text from >>> italics to something else. >>> >>> I do think that a fair amount new users are confused by C-e (instead of >>> C-i), but I have surprisingly seen few complaints so perhaps adapting is >>> not too difficult. >> >> Good catch. Stephan, I think it would be fine to re-assign inset-toggle. >> I don't think it works terribly reliably anyway. > > I use inset-toggle often. Can you remember a specific situation where it > is not reliable? > > I would prefer not to assign emph to C-i, but if we do decide to do it I > think we should do it for all platforms. I don't think this is a > platform-specific thing. I’ve reverted it for now. Emphasize text parts isn’t exactly the same as the change to italics. So it’s indeed disputable to use Command-I here. The use of Command-E for search-string-save on Mac is in par with behavior of many important applications now, AFAIK. I’d like to stay with the change. Emphasize text parts (font-emph) is changed to Command-Shift-E now. The OP of the bug #8055 mentioned the „broken“ binding for Command-E explicitly. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] #8055 use standard shortcut for font-emph on Mac
On Mon, Feb 15, 2021 at 10:31:38AM -0500, Richard Kimberly Heck wrote: > On 2/15/21 10:24 AM, Scott Kostyshak wrote: > > On Mon, Feb 15, 2021 at 09:32:01AM +0100, Stephan Witt wrote: > >> commit a9342ae098024e363891653d1bcf7a8d485a271c > >> Author: Stephan Witt > >> Date: Mon Feb 15 09:35:31 2021 +0100 > >> > >> #8055 use standard shortcut for font-emph on Mac > >> --- > >> lib/bind/mac.bind |5 ++--- > >> 1 files changed, 2 insertions(+), 3 deletions(-) > >> > >> diff --git a/lib/bind/mac.bind b/lib/bind/mac.bind > >> index 8d54e4c..531465b 100644 > >> --- a/lib/bind/mac.bind > >> +++ b/lib/bind/mac.bind > >> @@ -141,7 +141,6 @@ Format 5 > >> \bind "C-S-D""buffer-update dvi" # 'd' for dvi > >> # +: "Command-E"# Use the selection for a find > >> \bind "C-e" "search-string-set" > >> -\bind "C-M-e""font-emph" > >> # +: "Command-F"# Open a Find window > >> \bind "C-f" "dialog-toggle findreplace" > >> \bind "C-S-f""dialog-toggle findreplaceadv" > >> @@ -152,8 +151,8 @@ Format 5 > >> \bind "C-S-g""word-find-backward" > >> # +: "Command-H"# Hide the windows of the currently > >> running application > >> # +: "Option-Command-H" # Hide the windows of all other > >> running applications > >> -# -: "Command-I"# Italicize the selected text or > >> toggle italic text on or off > >> -\bind "C-i" "inset-toggle" # 'i' for Inset > >> +# +: "Command-I"# Italicize the selected text or > >> toggle italic text on or off > >> +\bind "C-i" "command-alternatives inset-toggle; > >> font-emph" # 'i' for Inset > >> \bind "C-M-i""inset-settings" > >> # -: "Option-Command-I" # Display an inspector window > >> # -: "Command-J"# Scroll to a selection > > I think this could have problems when both inset-toggle and font-emph > > are valid. For example, create a footnote and write text inside. Then > > put the cursor inside and run the command-alternatives. > > > > I don't think the C-e binding is a Linux/Windows-specific binding. > > Rather, I think it's a LaTeX thing. I believe the idea is that the user > > or document class can redefine what it means to "emphasize" text from > > italics to something else. > > > > I do think that a fair amount new users are confused by C-e (instead of > > C-i), but I have surprisingly seen few complaints so perhaps adapting is > > not too difficult. > > Good catch. Stephan, I think it would be fine to re-assign inset-toggle. > I don't think it works terribly reliably anyway. I use inset-toggle often. Can you remember a specific situation where it is not reliable? I would prefer not to assign emph to C-i, but if we do decide to do it I think we should do it for all platforms. I don't think this is a platform-specific thing. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
On Mon, Feb 15, 2021 at 08:48:04AM +0100, Jürgen Spitzmüller wrote: > Am Sonntag, dem 14.02.2021 um 19:39 -0500 schrieb Scott Kostyshak: > > Not sure how to change themes. > > E.g., "lyx -style fusion" That's a helpful feature to know about. > > I can look into that. I can also test > > on a newer Qt version when I have time. > > Thanks. Apparently Pavel has the same issue. Just tested current master and it works well. Thanks, 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] #8055 use standard shortcut for font-emph on Mac
On 2/15/21 10:24 AM, Scott Kostyshak wrote: > On Mon, Feb 15, 2021 at 09:32:01AM +0100, Stephan Witt wrote: >> commit a9342ae098024e363891653d1bcf7a8d485a271c >> Author: Stephan Witt >> Date: Mon Feb 15 09:35:31 2021 +0100 >> >> #8055 use standard shortcut for font-emph on Mac >> --- >> lib/bind/mac.bind |5 ++--- >> 1 files changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/lib/bind/mac.bind b/lib/bind/mac.bind >> index 8d54e4c..531465b 100644 >> --- a/lib/bind/mac.bind >> +++ b/lib/bind/mac.bind >> @@ -141,7 +141,6 @@ Format 5 >> \bind "C-S-D""buffer-update dvi"# 'd' for dvi >> # +: "Command-E"# Use the selection for a find >> \bind "C-e" "search-string-set" >> -\bind "C-M-e""font-emph" >> # +: "Command-F"# Open a Find window >> \bind "C-f" "dialog-toggle findreplace" >> \bind "C-S-f""dialog-toggle findreplaceadv" >> @@ -152,8 +151,8 @@ Format 5 >> \bind "C-S-g""word-find-backward" >> # +: "Command-H"# Hide the windows of the currently >> running application >> # +: "Option-Command-H" # Hide the windows of all other >> running applications >> -# -: "Command-I"# Italicize the selected text or >> toggle italic text on or off >> -\bind "C-i" "inset-toggle" # 'i' for Inset >> +# +: "Command-I"# Italicize the selected text or >> toggle italic text on or off >> +\bind "C-i" "command-alternatives inset-toggle; >> font-emph" # 'i' for Inset >> \bind "C-M-i""inset-settings" >> # -: "Option-Command-I" # Display an inspector window >> # -: "Command-J"# Scroll to a selection > I think this could have problems when both inset-toggle and font-emph > are valid. For example, create a footnote and write text inside. Then > put the cursor inside and run the command-alternatives. > > I don't think the C-e binding is a Linux/Windows-specific binding. > Rather, I think it's a LaTeX thing. I believe the idea is that the user > or document class can redefine what it means to "emphasize" text from > italics to something else. > > I do think that a fair amount new users are confused by C-e (instead of > C-i), but I have surprisingly seen few complaints so perhaps adapting is > not too difficult. Good catch. Stephan, I think it would be fine to re-assign inset-toggle. I don't think it works terribly reliably anyway. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: configure.py assumes "python" command exists
On Mon, Feb 15, 2021 at 09:50:04AM -0500, Richard Kimberly Heck wrote:
> On 2/15/21 5:56 AM, José Abílio Matos wrote:
> >
> > On Monday, February 15, 2021 4:27:40 AM WET Richard Kimberly Heck wrote:
> >
> > > We have a Python detection routine, find_python_binary(), so it could be
> >
> > > modified to check for those commands explicitly. I'm reluctant to touch
> >
> > > that code myself though.
> >
> >
> > The detection code in LyX is working correctly, it works if the name
> > is not python. The code searches for python39 or python3.9 or ...
> >
> >
> > The issue that Scott is raising is different. The problem is that
> > configure.py always issue a "python" as the python name. When we get
> > here the lyx detection code already worked correctly.
> >
> >
> > I had thought previously about this and I have an idea to fix this.
> >
> >
> > """
> >
> > import os, sys
> >
> >
> > print(os.path.basename(sys.executable))
> >
> > """
> >
> >
> > so the idea is to replace "python" by os.path.basename(sys.executable)
> > in all the calls on configure.py.
> >
> >
> > This code is general, since it takes care of the directory separators,
> > and it should work everywhere.
> >
> >
> >
> > Funnily enough the function rescanTeXFiles (line 1920) already does
> > that. :-)
> >
> >
> > For the next stable release if we assume a minimum of python 3.6 we
> > can use the f-strings (formatted in case you wonder :-) ) and the code
> > could be simply.
> >
> >
> > python = os.path.basename(sys.executable);
> >
> > ...
> >
> >
> > print (f"{python}")
> >
> >
> > so that the content of variable python is replaced inside the function...
> >
> Well, José, you are the expert on this, so please go ahead. It probably
> would be good to have this for the next release (probably beta 1).
+1
Thanks for taking a look, José.
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] #8055 use standard shortcut for font-emph on Mac
On Mon, Feb 15, 2021 at 09:32:01AM +0100, Stephan Witt wrote: > commit a9342ae098024e363891653d1bcf7a8d485a271c > Author: Stephan Witt > Date: Mon Feb 15 09:35:31 2021 +0100 > > #8055 use standard shortcut for font-emph on Mac > --- > lib/bind/mac.bind |5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/lib/bind/mac.bind b/lib/bind/mac.bind > index 8d54e4c..531465b 100644 > --- a/lib/bind/mac.bind > +++ b/lib/bind/mac.bind > @@ -141,7 +141,6 @@ Format 5 > \bind "C-S-D""buffer-update dvi" # 'd' for dvi > # +: "Command-E"# Use the selection for a find > \bind "C-e" "search-string-set" > -\bind "C-M-e""font-emph" > # +: "Command-F"# Open a Find window > \bind "C-f" "dialog-toggle findreplace" > \bind "C-S-f""dialog-toggle findreplaceadv" > @@ -152,8 +151,8 @@ Format 5 > \bind "C-S-g""word-find-backward" > # +: "Command-H"# Hide the windows of the currently > running application > # +: "Option-Command-H" # Hide the windows of all other running > applications > -# -: "Command-I"# Italicize the selected text or toggle > italic text on or off > -\bind "C-i" "inset-toggle" # 'i' for Inset > +# +: "Command-I"# Italicize the selected text or toggle > italic text on or off > +\bind "C-i" "command-alternatives inset-toggle; > font-emph" # 'i' for Inset > \bind "C-M-i""inset-settings" > # -: "Option-Command-I" # Display an inspector window > # -: "Command-J"# Scroll to a selection I think this could have problems when both inset-toggle and font-emph are valid. For example, create a footnote and write text inside. Then put the cursor inside and run the command-alternatives. I don't think the C-e binding is a Linux/Windows-specific binding. Rather, I think it's a LaTeX thing. I believe the idea is that the user or document class can redefine what it means to "emphasize" text from italics to something else. I do think that a fair amount new users are confused by C-e (instead of C-i), but I have surprisingly seen few complaints so perhaps adapting is not too difficult. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
On 2/15/21 9:16 AM, Jürgen Spitzmüller wrote: > Am Sonntag, dem 14.02.2021 um 22:04 +0100 schrieb Jean-Marc Lasgouttes: >> 2/ when the dialog "would you like to start from start" is shown, the >> focus is not in the dock anymore and it not possible to use Enter to >> search next. > I just learned that we have a 10 year old ticket to this: > https://www.lyx.org/trac/ticket/7561 Just read this entire thread. How much I missed being on US time! Great work, everyone! Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Transform simple search dialog to dock widget (#2625)
On 2/15/21 5:51 AM, Jean-Marc Lasgouttes wrote:
> Le 15/02/2021 à 01:23, Richard Kimberly Heck a écrit :
>> I'm no expert. I doubt it really matters very much, though maybe we
>> should settle on something, just for consistency. But it looks like
>> "uniform initializaton" is a thing, so maybe we should just get into
>> the habit of using {}. But I'd be happy to say as well: With plain
>> types, we use explicit initialization, e.g., 0 for ints; nullptr, for
>> pointers; etc. But we can use {} for the default with other types.
>
> I prefer this too.
OK, sounds like a consensus. I'll add a note to Development.lyx.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: configure.py assumes "python" command exists
On 2/15/21 5:56 AM, José Abílio Matos wrote:
>
> On Monday, February 15, 2021 4:27:40 AM WET Richard Kimberly Heck wrote:
>
> > We have a Python detection routine, find_python_binary(), so it could be
>
> > modified to check for those commands explicitly. I'm reluctant to touch
>
> > that code myself though.
>
>
> The detection code in LyX is working correctly, it works if the name
> is not python. The code searches for python39 or python3.9 or ...
>
>
> The issue that Scott is raising is different. The problem is that
> configure.py always issue a "python" as the python name. When we get
> here the lyx detection code already worked correctly.
>
>
> I had thought previously about this and I have an idea to fix this.
>
>
> """
>
> import os, sys
>
>
> print(os.path.basename(sys.executable))
>
> """
>
>
> so the idea is to replace "python" by os.path.basename(sys.executable)
> in all the calls on configure.py.
>
>
> This code is general, since it takes care of the directory separators,
> and it should work everywhere.
>
>
>
> Funnily enough the function rescanTeXFiles (line 1920) already does
> that. :-)
>
>
> For the next stable release if we assume a minimum of python 3.6 we
> can use the f-strings (formatted in case you wonder :-) ) and the code
> could be simply.
>
>
> python = os.path.basename(sys.executable);
>
> ...
>
>
> print (f"{python}")
>
>
> so that the content of variable python is replaced inside the function...
>
Well, José, you are the expert on this, so please go ahead. It probably
would be good to have this for the next release (probably beta 1).
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 15:09 +0100 schrieb Enrico Forestieri: > Thanks. Another glitch is the fact that the search dialog can only be > dismissed by the X-close button (the toolbar button does not toggle). > However, when the dialog is minimized, the close button is not > available and one has to expand it to be able to dismiss it. Ctrl-F actually toggles. > Apart from that, it seems to work well. As a further info for you, > when using search-as-you-type and the "Wrap search?" dialog appears, > after dismissing it I tried to change the search string but I did not > notice that the focus was returned to the workarea and I ended up > modifying the document, instead. Yes, that's https://www.lyx.org/trac/ticket/7561 There's now the wrap option in the dialog to mitigate this. 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
Re: [RFC] Simple Search to Bottom Dock
Am Sonntag, dem 14.02.2021 um 22:04 +0100 schrieb Jean-Marc Lasgouttes: > 2/ when the dialog "would you like to start from start" is shown, the > focus is not in the dock anymore and it not possible to use Enter to > search next. I just learned that we have a 10 year old ticket to this: https://www.lyx.org/trac/ticket/7561 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
Re: [RFC] Simple Search to Bottom Dock
On Mon, Feb 15, 2021 at 08:58:11AM +0100, Jürgen Spitzmüller wrote: > Am Sonntag, dem 14.02.2021 um 22:13 +0100 schrieb Enrico Forestieri: > > There's something strange on Windows, too. I see 2 Find and 2 Replace > > perfectly equal buttons. See attached. > > This (and Scott's and Pavel's woes) should be fixed now. Thanks. Another glitch is the fact that the search dialog can only be dismissed by the X-close button (the toolbar button does not toggle). However, when the dialog is minimized, the close button is not available and one has to expand it to be able to dismiss it. Apart from that, it seems to work well. As a further info for you, when using search-as-you-type and the "Wrap search?" dialog appears, after dismissing it I tried to change the search string but I did not notice that the focus was returned to the workarea and I ended up modifying the document, instead. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 13:10 +0100 schrieb Pavel Sanda: > Thinking aloud, it might not be even necessary to have new shortcut > at all. > > What if we enhanced current word-find so that it always uses > currently selected > text for the search? > Then F3 would by default use GuiSearch pattern (which is always > slected in the > next move) as it used to. But now if you selected specific text and > just hit F3 > such new selection would be used. No CTRL+F3 needed. > > Do you find this useful as me? I think it would conflict with "Search in selection only" which is another (unimplemented) oft-requested feature. 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
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 11:49 +0100 schrieb Jean-Marc Lasgouttes: > Not that bad ;) A problem though: > > + if (instant) > + // re-query current match > + dispatch(FuncRequest(LFUN_WORD_BACKWARD)); > > The search string is not necessarily a word. Instead of going a word > backward, the best is to put the cursor at the beginning of the > selection. Right, fixed. 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
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 13:00 +0100 schrieb Pavel Sanda: > Oops, I clearly misunderstood the Big Mac Way ;) > What I thought as cool is in current state of affairs "command- > sequence search-string-set; word-find". > Would you mind if I changed CTRL+F3 in cua bind to this? No. This differs from Mac then, but I don't care about that. 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
Re: [LyX/master] Transform simple search dialog to dock widget (#2625)
Le 15/02/2021 à 12:32, José Abílio Matos a écrit :
IIRC the first option without the equal sign replaces the notation where
parenthesis are used:
BufferView const * bv_ {nullptr};
instead of
BufferView const * bv_ (nullptr);
Then it becomes evident that are not using a function call here.
I see. Still, I find it a bit confising.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 12:45 +0100 schrieb Pavel Sanda: > Don't know if intended, I still see the dialog even if performed by > GuiSearch and wrap is off. Yes, that's intended. Give the user a signal that end/begin has been reached. 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
Re: [RFC] Simple Search to Bottom Dock
On Mon, Feb 15, 2021 at 01:00:48PM +0100, Pavel Sanda wrote: > On Mon, Feb 15, 2021 at 09:11:23AM +0100, Jürgen Spitzmüller wrote: > > Am Sonntag, dem 14.02.2021 um 22:54 +0100 schrieb Pavel Sanda: > > > Another glitch: F3 in search pane goes forward, F3 in edit area goes > > > backward. > > > > This looks like an (unintended?) consequence of Stephan's work: word- > > find now uses cached search information _including_ direction. > > > > Stephan is this really how it should be? > > > > We could re-bind F3 to word-find-forward in cua, but this has the > > drawback that it doesn't open the search dialog if the buffer is empty. > > > > > If I understand correctly the situation on Mac, when some text is > > > selected, you can immediately use shortcut for find-next. Wouldn't be > > > cool to have shortcut for this in linux as well (AFAIK we don't now)? > > > > Bound to Ctrl-F3 now. > > Oops, I clearly misunderstood the Big Mac Way ;) > What I thought as cool is in current state of affairs "command-sequence > search-string-set; word-find". > Would you mind if I changed CTRL+F3 in cua bind to this? Thinking aloud, it might not be even necessary to have new shortcut at all. What if we enhanced current word-find so that it always uses currently selected text for the search? Then F3 would by default use GuiSearch pattern (which is always slected in the next move) as it used to. But now if you selected specific text and just hit F3 such new selection would be used. No CTRL+F3 needed. Do you find this useful as me? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
On Mon, Feb 15, 2021 at 09:11:23AM +0100, Jürgen Spitzmüller wrote: > Am Sonntag, dem 14.02.2021 um 22:54 +0100 schrieb Pavel Sanda: > > Another glitch: F3 in search pane goes forward, F3 in edit area goes > > backward. > > This looks like an (unintended?) consequence of Stephan's work: word- > find now uses cached search information _including_ direction. > > Stephan is this really how it should be? > > We could re-bind F3 to word-find-forward in cua, but this has the > drawback that it doesn't open the search dialog if the buffer is empty. > > > If I understand correctly the situation on Mac, when some text is > > selected, you can immediately use shortcut for find-next. Wouldn't be > > cool to have shortcut for this in linux as well (AFAIK we don't now)? > > Bound to Ctrl-F3 now. Oops, I clearly misunderstood the Big Mac Way ;) What I thought as cool is in current state of affairs "command-sequence search-string-set; word-find". Would you mind if I changed CTRL+F3 in cua bind to this? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
On Mon, Feb 15, 2021 at 11:30:51AM +0100, Jürgen Spitzmüller wrote: > Am Montag, dem 15.02.2021 um 09:09 +0100 schrieb Pavel Sanda: > > Maybe we could ditch this dialog and have check box whether to loop > > from begining? > > Done. We still have the dialog for searches not performed by GuiSearch. Don't know if intended, I still see the dialog even if performed by GuiSearch and wrap is off. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4 Alpha 3
On Sunday, February 14, 2021 7:45:37 PM WET Richard Kimberly Heck wrote: > With the Windows problem fixed, we need another alpha. So it's here: > > http://ftp.lyx.org/ftp/pub/lyx/devel/lyx-2.4/ > > Please prepare binaries. I have built packages for EPEL 7 and 8 and for Fedora 32-34 and rawhide (to be Fedora 35). Fedora 34 is still a development branch. I worked without any changes for all architectures: https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/ I still need to integrate the new dependencies on xlstproc but with classes starting today in online only mode that is the best I can do at the moment. > Riki > > PS I did remember to change the version in configure.ac this time. Thank you. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Transform simple search dialog to dock widget (#2625)
On Sunday, February 14, 2021 6:33:03 PM WET Jean-Marc Lasgouttes wrote:
> Am I right that it
> is the same to write:
> BufferView const * bv_ {};
> BufferView const * bv_ = {};
> BufferView const * bv_ = {nullptr};
> BufferView const * bv_ = nullptr;
>
> Why do we need to have all these possibilities? In particular the first
> one is weird to me.
IIRC the first option without the equal sign replaces the notation where
parenthesis are used:
BufferView const * bv_ {nullptr};
instead of
BufferView const * bv_ (nullptr);
Then it becomes evident that are not using a function call here.
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Le 15/02/2021 à 09:20, Jürgen Spitzmüller a écrit : Maybe we could ditch this dialog and have check box whether to loop from begining? I agree. In that case, however, we should make search stop after one cycle. The emacs way is to flash the screen (invert briefly?) and/or beep and continue looping. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: configure.py assumes "python" command exists
On Monday, February 15, 2021 4:27:40 AM WET Richard Kimberly Heck wrote:
> We have a Python detection routine, find_python_binary(), so it could be
> modified to check for those commands explicitly. I'm reluctant to touch
> that code myself though.
The detection code in LyX is working correctly, it works if the name is not
python. The code searches for python39 or python3.9 or ...
The issue that Scott is raising is different. The problem is that configure.py
always issue a "python" as the python name. When we get here the lyx detection
code already worked correctly.
I had thought previously about this and I have an idea to fix this.
"""
import os, sys
print(os.path.basename(sys.executable))
"""
so the idea is to replace "python" by os.path.basename(sys.executable) in all
the calls on configure.py.
This code is general, since it takes care of the directory separators, and it
should work everywhere.
Funnily enough the function rescanTeXFiles (line 1920) already does that. :-)
For the next stable release if we assume a minimum of python 3.6 we can use
the f-strings (formatted in case you wonder :-) ) and the code could be
simply.
python = os.path.basename(sys.executable);
...
print (f"{python}")
so that the content of variable python is replaced inside the function...
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Transform simple search dialog to dock widget (#2625)
Le 15/02/2021 à 01:23, Richard Kimberly Heck a écrit :
I'm no expert. I doubt it really matters very much, though maybe we
should settle on something, just for consistency. But it looks like
"uniform initializaton" is a thing, so maybe we should just get into the
habit of using {}. But I'd be happy to say as well: With plain types, we
use explicit initialization, e.g., 0 for ints; nullptr, for pointers;
etc. But we can use {} for the default with other types.
I prefer this too.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Le 15/02/2021 à 10:55, Jürgen Spitzmüller a écrit : Am Sonntag, dem 14.02.2021 um 23:40 +0100 schrieb Jean-Marc Lasgouttes: 'find as you type'. Proof of concept (as I understood it) in master. Please check. Not that bad ;) A problem though: + if (instant) + // re-query current match + dispatch(FuncRequest(LFUN_WORD_BACKWARD)); The search string is not necessarily a word. Instead of going a word backward, the best is to put the cursor at the beginning of the selection. Example: open the Intro manual and search for the string "find a problem". Another feature of this emacs search as you type is that when one types C-s the search string is empty, but a second C-s will set the search string to the last string. I am not sure this is compatible with our toggling behavior, though. Personally, I prefer a new C-f to do find-next than toggle, but it is a matter of taste. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 09:09 +0100 schrieb Pavel Sanda: > Maybe we could ditch this dialog and have check box whether to loop > from begining? Done. We still have the dialog for searches not performed by GuiSearch. 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
Re: [RFC] Simple Search to Bottom Dock
Am Sonntag, dem 14.02.2021 um 23:40 +0100 schrieb Jean-Marc Lasgouttes: > 'find as you type'. Proof of concept (as I understood it) in master. Please check. 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
Re: [RFC] Simple Search to Bottom Dock
Am Sonntag, dem 14.02.2021 um 22:04 +0100 schrieb Jean-Marc Lasgouttes: > 2/ when the dialog "would you like to start from start" is shown, the > focus is not in the dock anymore and it not possible to use Enter to > search next. Question back to you: Can we prevent the workarea to take focus of the cursor actions that are performed here? > Do we really need the dialog, BTW? See my other response. We need some reminder to the user that he has gone through a complete cycle. 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
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 10:25 +0100 schrieb Kornel Benko: > Yes. Backward search is alike, but with Ctrl-R. But I don't see how we can have both (without having back the direction shortcut we just so eagerly ditched). 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
Re: [RFC] Simple Search to Bottom Dock
Am Mon, 15 Feb 2021 10:09:17 +0100 schrieb Jürgen Spitzmüller : > Am Montag, dem 15.02.2021 um 09:59 +0100 schrieb Jean-Marc Lasgouttes: > > What's that? Perform search while you edit the search string? > > > > Yes, like emacs does with Ctrl-S. > > And this always searches forward, right? > > Jürgen > Yes. Backward search is alike, but with Ctrl-R. Kornel pgp6yvclmsP8U.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 10:09 +0100 schrieb Jürgen Spitzmüller:
> Am Montag, dem 15.02.2021 um 09:59 +0100 schrieb Jean-Marc
> Lasgouttes:
> > What's that? Perform search while you edit the search string?
> >
> > Yes, like emacs does with Ctrl-S.
>
> And this always searches forward, right?
And another question:
Let's say I type in "te". LyX searches forward and finds "te" in
"test". Now if I enter "s" ("tes") I suppose LyX should stick with the
current match and only adapt the highlighting, right? I.e., it should
only continue searching forward if the string and the match under
cursor do not equal anymore ("tesp").
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
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 10:08 +0100 schrieb Stephan Witt: > Do you think we should have both patches? > > I think so, because then the LFUN_WORD_FIND doesn’t rely on internal > defaults. I am not sure whether it's not a feature to use the previous options. 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
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 09:59 +0100 schrieb Jean-Marc Lasgouttes: > What's that? Perform search while you edit the search string? > > Yes, like emacs does with Ctrl-S. And this always searches forward, right? 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
Re: [RFC] Simple Search to Bottom Dock
Am 15.02.2021 um 10:03 schrieb Jürgen Spitzmüller :
>
> Am Montag, dem 15.02.2021 um 09:52 +0100 schrieb Stephan Witt:
>> I don’t understand. The direction isn’t stored in
>> setSearchRequestCache().
>> The direction is stripped. Probably that causes the trouble.
>
> It turned out the problem was the parsing of the search argument set
> forward to false by default (i.e., if it was not explicitly specified
> in the argument), whereas it should be true ("word-find foo" should
> find forwards, not backwards).
>
> I fixed this by introducing a way to set true as default for bool
> parser.
Yes, that’s not bad.
>
>> You did something about it. I had another proposal ready but not sent
>> yet :(
>
> Sorry about that.
It’s a hot topic :)
Do you think we should have both patches?
I think so, because then the LFUN_WORD_FIND doesn’t rely on internal defaults.
Stephan
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Transform simple search dialog to dock widget (#2625)
Am 15.02.2021 um 01:23 schrieb Richard Kimberly Heck :
>
> On 2/14/21 3:48 PM, Jean-Marc Lasgouttes wrote:
>> Le 14/02/2021 à 20:40, Richard Kimberly Heck a écrit :
Yes, it’s a matter of style and I’m ok with this too.
Latest changes made me think it’s more modern to use the {} syntax.
>>>
>>> The {} notation uses the default initializer, whatever that is. So, yes,
>>> nullptr would be more explicit but has the same effect.
>>>
>>> See
>>> https://arne-mertz.de/2015/07/new-c-features-uniform-initialization-and-initializer_list/
>>>
>>
>>
>> So Riki, what do you prefer in this case?
>
> I'm no expert. I doubt it really matters very much, though maybe we should
> settle on something, just for consistency. But it looks like "uniform
> initializaton" is a thing, so maybe we should just get into the habit of
> using {}. But I'd be happy to say as well: With plain types, we use explicit
> initialization, e.g., 0 for ints; nullptr, for pointers; etc. But we can use
> {} for the default with other types.
I’m not an expert too. But I agree to use nullptr here as it’s the style used
elsewhere and it’s recommended by Arne Mertz.
Stephan
>
> There are some other pretty cool C++11 features in this one
>
> https://arne-mertz.de/2015/08/new-c-features-inherited-and-delegating-constructors/
>
> that we might want to use, too.
>
> Riki
>
>
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 09:52 +0100 schrieb Stephan Witt:
> I don’t understand. The direction isn’t stored in
> setSearchRequestCache().
> The direction is stripped. Probably that causes the trouble.
It turned out the problem was the parsing of the search argument set
forward to false by default (i.e., if it was not explicitly specified
in the argument), whereas it should be true ("word-find foo" should
find forwards, not backwards).
I fixed this by introducing a way to set true as default for bool
parser.
> You did something about it. I had another proposal ready but not sent
> yet :(
Sorry about that.
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
Re: [RFC] Simple Search to Bottom Dock
Le 15/02/2021 à 08:50, Jürgen Spitzmüller a écrit : Am Sonntag, dem 14.02.2021 um 23:40 +0100 schrieb Jean-Marc Lasgouttes: If now is the good time for the Christmas shopping list, then I would like 'find as you type'. What's that? Perform search while you edit the search string? Yes, like emacs does with Ctrl-S. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am 15.02.2021 um 09:11 schrieb Jürgen Spitzmüller : > > Am Sonntag, dem 14.02.2021 um 22:54 +0100 schrieb Pavel Sanda: >> Another glitch: F3 in search pane goes forward, F3 in edit area goes >> backward. > > This looks like an (unintended?) consequence of Stephan's work: word- > find now uses cached search information _including_ direction. > > Stephan is this really how it should be? I don’t understand. The direction isn’t stored in setSearchRequestCache(). The direction is stripped. Probably that causes the trouble. You did something about it. I had another proposal ready but not sent yet :( Patch attached. Stephan > > We could re-bind F3 to word-find-forward in cua, but this has the > drawback that it doesn't open the search dialog if the buffer is empty. > >> If I understand correctly the situation on Mac, when some text is >> selected, you can immediately use shortcut for find-next. Wouldn't be >> cool to have shortcut for this in linux as well (AFAIK we don't now)? > > Bound to Ctrl-F3 now. LFUN_WORD_FIND.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Simple Search to Bottom Dock
Am Sonntag, dem 14.02.2021 um 22:54 +0100 schrieb Pavel Sanda: > Another glitch: F3 in search pane goes forward, F3 in edit area goes > backward. Should be fixed. Please verify. 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
Re: [RFC] Simple Search to Bottom Dock
Am Montag, dem 15.02.2021 um 09:09 +0100 schrieb Pavel Sanda: > On Sun, Feb 14, 2021 at 10:04:00PM +0100, Jean-Marc Lasgouttes wrote: > > 2/ when the dialog "would you like to start from start" is shown, > > the focus > > is not in the dock anymore and it not possible to use Enter to > > search next. > > Do we really need the dialog, BTW? > > Maybe we could ditch this dialog and have check box whether to loop > from begining? I agree. In that case, however, we should make search stop after one cycle. 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
Re: [RFC] Simple Search to Bottom Dock
Am Sonntag, dem 14.02.2021 um 22:54 +0100 schrieb Pavel Sanda: > Another glitch: F3 in search pane goes forward, F3 in edit area goes > backward. This looks like an (unintended?) consequence of Stephan's work: word- find now uses cached search information _including_ direction. Stephan is this really how it should be? We could re-bind F3 to word-find-forward in cua, but this has the drawback that it doesn't open the search dialog if the buffer is empty. > If I understand correctly the situation on Mac, when some text is > selected, you can immediately use shortcut for find-next. Wouldn't be > cool to have shortcut for this in linux as well (AFAIK we don't now)? Bound to Ctrl-F3 now. Jürgen > > Pavel 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
Re: [RFC] Simple Search to Bottom Dock
On Sun, Feb 14, 2021 at 10:04:00PM +0100, Jean-Marc Lasgouttes wrote: > 2/ when the dialog "would you like to start from start" is shown, the focus > is not in the dock anymore and it not possible to use Enter to search next. > Do we really need the dialog, BTW? Maybe we could ditch this dialog and have check box whether to loop from begining? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
