Re: Bringing a hidden window to the front on a mac.
On Sat, May 21, 2016 at 06:07:19PM -0400, Scott Kostyshak wrote: > On Sat, May 21, 2016 at 11:58:36PM +0200, Stephan Witt wrote: > > Am 21.05.2016 um 23:50 schrieb Scott Kostyshak : > > > > > > On Sat, May 21, 2016 at 11:13:54AM +0200, pdv wrote: > > >> If one has 2 documents open in LyX 2.2 in 2 separate windows and one > > >> wants > > >> to bring the one in the back to the front via the menu View/Hidden/... > > >> then > > >> (on a mac, OSX 10.11.4) nothing happens. Although the window has been > > >> activated, it's not brought to the front. [When switching to e.g. the > > >> Finder > > >> and then back to LyX by clicking on the LyX icon in the Dock, the hidden > > >> window will now be shown in front.] > > >> > > >> The problem is solved by adding a raise() call to the activateWindow() > > >> call > > >> in GuiView.cpp (see included patch). > > >> > > >> Regards, > > >> > > >> P. De Visschere > > > > > >> diff --git a/src/frontends/qt4/GuiView.cpp > > >> b/src/frontends/qt4/GuiView.cpp > > >> index c2101f3..89bff9a 100644 > > >> --- a/src/frontends/qt4/GuiView.cpp > > >> +++ b/src/frontends/qt4/GuiView.cpp > > >> @@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, > > >> DispatchResult & dr) > > >> for (; i != ids.size(); ++i) { > > >> GuiView & gv = guiApp->view(ids[i]); > > >> if (gv.workArea(*buffer)) { > > >> +gv.raise(); > > >> gv.activateWindow(); > > >> gv.setBuffer(buffer); > > >> break; > > > > > > Since this part of the code is contained in "case LFUN_BUFFER_SWITCH" > > > and is only reached if there are multiple views, I think it could go > > > in for 2.2.0. > > > > > > Let's see if anyone else has an opinion, otherwise I will test on Linux > > > and commit it before rc2. > > > > You may consider to cherry-pick change > > 5f368aec7b3206c873c94294def906911523dc8e. > > Aha, I thought I saw that somewhere. > > Go ahead with the cherry-pick. I will still test on Linux. Tested and pushed at 1719fa6c. Thanks Stephan and pdv. Scott signature.asc Description: PGP signature
Re: Bringing a hidden window to the front on a mac.
On Sat, May 21, 2016 at 11:58:36PM +0200, Stephan Witt wrote: > Am 21.05.2016 um 23:50 schrieb Scott Kostyshak : > > > > On Sat, May 21, 2016 at 11:13:54AM +0200, pdv wrote: > >> If one has 2 documents open in LyX 2.2 in 2 separate windows and one wants > >> to bring the one in the back to the front via the menu View/Hidden/... then > >> (on a mac, OSX 10.11.4) nothing happens. Although the window has been > >> activated, it's not brought to the front. [When switching to e.g. the > >> Finder > >> and then back to LyX by clicking on the LyX icon in the Dock, the hidden > >> window will now be shown in front.] > >> > >> The problem is solved by adding a raise() call to the activateWindow() call > >> in GuiView.cpp (see included patch). > >> > >> Regards, > >> > >> P. De Visschere > > > >> diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp > >> index c2101f3..89bff9a 100644 > >> --- a/src/frontends/qt4/GuiView.cpp > >> +++ b/src/frontends/qt4/GuiView.cpp > >> @@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, > >> DispatchResult & dr) > >>for (; i != ids.size(); ++i) { > >>GuiView & gv = guiApp->view(ids[i]); > >>if (gv.workArea(*buffer)) { > >> + gv.raise(); > >>gv.activateWindow(); > >>gv.setBuffer(buffer); > >>break; > > > > Since this part of the code is contained in "case LFUN_BUFFER_SWITCH" > > and is only reached if there are multiple views, I think it could go > > in for 2.2.0. > > > > Let's see if anyone else has an opinion, otherwise I will test on Linux > > and commit it before rc2. > > You may consider to cherry-pick change > 5f368aec7b3206c873c94294def906911523dc8e. Aha, I thought I saw that somewhere. Go ahead with the cherry-pick. I will still test on Linux. Thanks, Scott signature.asc Description: PGP signature
Re: Bringing a hidden window to the front on a mac.
Am 21.05.2016 um 23:50 schrieb Scott Kostyshak : > > On Sat, May 21, 2016 at 11:13:54AM +0200, pdv wrote: >> If one has 2 documents open in LyX 2.2 in 2 separate windows and one wants >> to bring the one in the back to the front via the menu View/Hidden/... then >> (on a mac, OSX 10.11.4) nothing happens. Although the window has been >> activated, it's not brought to the front. [When switching to e.g. the Finder >> and then back to LyX by clicking on the LyX icon in the Dock, the hidden >> window will now be shown in front.] >> >> The problem is solved by adding a raise() call to the activateWindow() call >> in GuiView.cpp (see included patch). >> >> Regards, >> >> P. De Visschere > >> diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp >> index c2101f3..89bff9a 100644 >> --- a/src/frontends/qt4/GuiView.cpp >> +++ b/src/frontends/qt4/GuiView.cpp >> @@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, >> DispatchResult & dr) >> for (; i != ids.size(); ++i) { >> GuiView & gv = guiApp->view(ids[i]); >> if (gv.workArea(*buffer)) { >> +gv.raise(); >> gv.activateWindow(); >> gv.setBuffer(buffer); >> break; > > Since this part of the code is contained in "case LFUN_BUFFER_SWITCH" > and is only reached if there are multiple views, I think it could go > in for 2.2.0. > > Let's see if anyone else has an opinion, otherwise I will test on Linux > and commit it before rc2. You may consider to cherry-pick change 5f368aec7b3206c873c94294def906911523dc8e. Stephan
Fix for using system icons
There is a patch for http://www.lyx.org/trac/ticket/10052 at http://www.lyx.org/trac/attachment/ticket/10052/10052_alternative.diff I'm planning to commit the patch before rc2 unless someone objects. The patch is simple and has been tested. Scott signature.asc Description: PGP signature
Re: Bringing a hidden window to the front on a mac.
On Sat, May 21, 2016 at 11:13:54AM +0200, pdv wrote: > If one has 2 documents open in LyX 2.2 in 2 separate windows and one wants > to bring the one in the back to the front via the menu View/Hidden/... then > (on a mac, OSX 10.11.4) nothing happens. Although the window has been > activated, it's not brought to the front. [When switching to e.g. the Finder > and then back to LyX by clicking on the LyX icon in the Dock, the hidden > window will now be shown in front.] > > The problem is solved by adding a raise() call to the activateWindow() call > in GuiView.cpp (see included patch). > > Regards, > > P. De Visschere > diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp > index c2101f3..89bff9a 100644 > --- a/src/frontends/qt4/GuiView.cpp > +++ b/src/frontends/qt4/GuiView.cpp > @@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, > DispatchResult & dr) > for (; i != ids.size(); ++i) { > GuiView & gv = guiApp->view(ids[i]); > if (gv.workArea(*buffer)) { > + gv.raise(); > gv.activateWindow(); > gv.setBuffer(buffer); > break; Since this part of the code is contained in "case LFUN_BUFFER_SWITCH" and is only reached if there are multiple views, I think it could go in for 2.2.0. Let's see if anyone else has an opinion, otherwise I will test on Linux and commit it before rc2. Scott signature.asc Description: PGP signature
Re: We will have to change our output for newest LuaTeX
On Sat, May 21, 2016 at 04:23:24PM +, Guenter Milde wrote: > On 2016-05-20, Guillaume Munch wrote: > > Le 20/05/2016 19:26, Scott Kostyshak a écrit : > >> On Fri, May 20, 2016 at 04:06:22PM +, Guenter Milde wrote: > >>> On 2016-05-20, Jean-Marc Lasgouttes wrote: > Le 20/05/2016 à 13:17, Guenter Milde a écrit : > > On 2016-05-20, Scott Kostyshak wrote: > > >> There have been some changes in the luatex engine that will be > >> shipped with TeX Live 2016 that cause many of our tests to fail > >> (500 something instead of 100 something on TL 2015). The root > >> issue is discussed on the LuaTeX mailing list at [1]. > > >> There is a transitional package available, luatex85, that should > >> make our current LuaTeX code work. A reasonable approach for now > >> would be to use the package if it is available and to not use it > >> if not, keeping the rest of our LuaTeX export code the same. > ... > > We could just add > ... > \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{} > ... > > >> Should we do this only when we use code that we think needs it? Or > >> should we just add it to all of our LuaTeX exports? > > I propose to do this with every LuaTeX export > > +3 simple (no LyX-logic required) > +1 no risk of LyX getting it wrong > -1 eventually spurious package loading I agree. > > For 2.2 this could be shipped as a module, to be deprecated and updated > > into an empty module once LyX decides to adopt the new luatex syntax. > > I'd rather keep this simple as well: insert > > \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{} > > with every LuaTeX export for the next years to come untill we can be safe > every user has the new version and can start using the new syntax in our > export. Makes sense. And because LuaTeX is still beta, I don't think we should feel too much pressure an old LuaTeX version for a long time. What about the attached patch? The most controversial change is putting something before \documentclass. In BufferParams::writeLaTeX() we have the following warning: // Do not try to load any other package before the document class, unless you // have a thorough understanding of the LATEX internals and know exactly what you // are doing! I do not have a thorough understanding of the LATEX internals and I very rarely know exactly what I'm doing. The package documentation of luatex85 does suggest that it should be the first line of the document. Any thoughts? Jürgen, since you've done a lot of work on the LuaTeX code, do you have an opinion? Scott From 7a94d6a64919c791e49f2c3e712770d611bc2b55 Mon Sep 17 00:00:00 2001 From: Scott Kostyshak Date: Sat, 21 May 2016 17:04:42 -0400 Subject: [PATCH] Fix LuaTeX export for TL >= 2016 If the transitional package luatex85 is available we use it. Otherwise, we assume that an older luatex engine is being used. For more information, see the following lyx-devel thread: https://www.mail-archive.com/search?l=mid&q=20160520075810.yi3uspufehev5aln%40cotopaxi The luatex85 manual suggests to users to load the package "as the first line of their document". --- src/BufferParams.cpp | 11 +++ 1 file changed, 11 insertions(+) diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp index 9d121cb..1689513 100644 --- a/src/BufferParams.cpp +++ b/src/BufferParams.cpp @@ -1426,6 +1426,17 @@ bool BufferParams::writeLaTeX(otexstream & os, LaTeXFeatures & features, // Do not try to load any other package before the document class, unless you // have a thorough understanding of the LATEX internals and know exactly what you // are doing! + + // our LuaTeX export is broken with TL >= 2016. If the transitional + // package luatex85 is available we use it. Otherwise, we assume that + // an older luatex engine is being used. + // https://www.mail-archive.com/search?l=mid&q=20160520075810.yi3uspufehev5aln%40cotopaxi + // The luatex85 manual suggests to users to load the package "as the + // first line of their document" + if (features.runparams().flavor == OutputParams::LUATEX || + features.runparams().flavor == OutputParams::DVILUATEX) + os << "\\IfFileExists{luatex85.sty}{\\usepackage{luatex85}}{}\n"; + if (features.mustProvide("fix-cm")) os << "\\RequirePackage{fix-cm}\n"; // Likewise for fixltx2e. If other packages conflict with this policy, -- 2.1.4 signature.asc Description: PGP signature
Plan to tag and tar 2.2.0rc2 on Monday
Dear all, Unless something comes up, I'm planning to tag and tar rc2 on Monday. At that point I'll put the tar balls on the FTP and whenever Mac and Win binaries are uploaded we will announce the release. Thank you all for your help, Scott signature.asc Description: PGP signature
Re: LyX does work with ImageMagick 7
On Sat, May 21, 2016 at 11:27:27AM +0200, Georg Baum wrote: > Hi, > > now I found some time to test and it turned out that some information in > this thread is wrong. Therefore I removed the warning from release notes > again. > > 1) Imagemagick 7 does still contain the 'convert' utility. If you install > from source on unix, it is simply a symlink to 'magick'. If you use the > binary installer on windows, you need to tick the "Install legacy utilities" > option in order to install a convert.exe along magick.exe (but for LyX this > is no longer needed since we prefer 'magick' if it is available). > > 2) LyX works perfectly with Imagemagick 7. I tested that without the convert > symlink. I could not see any difference to IM 6 (and I made sure I deleted > the image cache and reconfigured). I guess what might have lead to the > assumption that IM 7 does not work is the fact that the info inset produces > text output for .svgz images, but an image link for .png images. This should > be changed, modern browsers support svg (but may need uncompressing, I don't > know). Good to know that 2.2.0 is expected to work with IM 7. Scott signature.asc Description: PGP signature
Re: Python 2 in release notes
On Sat, May 21, 2016 at 10:16:25AM +0200, Georg Baum wrote: > José Matos wrote: > > > On Monday, May 9, 2016 9:46:01 PM WEST Scott Kostyshak wrote: > >> Georg or José, please feel free to make changes to the RELEASE-NOTES > >> regarding Python if you think it would make things more clear. > >> > >> Scott > > > > I think that Georg's formulation is clear and more correct than what we > > have now. > > Actually it was not correct either, since building LyX works with python 3. > I just committed a hopefully better version at 8d4236bd1d95. Thanks. Scott signature.asc Description: PGP signature
Re: [patch] fix bug 10124 (XHTML export of some symbols)
On Sat, May 21, 2016 at 09:56:07AM -0400, Richard Heck wrote: > On 05/21/2016 05:11 AM, Georg Baum wrote: > > While testing imagemagick 7 (more on that later) I stumbled upon bug 10124 > > as well. It is a simple typo where LyX outputs / instead of . OK > > for 2.2.0? > > Scott's call, of course, but it certainly looks safe to me. Go ahead for master. Scott signature.asc Description: PGP signature
Re: enhancing search: make it find everything; including source
On 21.05.16 18:15, Guenter Milde wrote: > On 2016-05-21, mn wrote: >> Currently it seems quite difficult to get the search function to really >> find everything that might be in a lyx-document. > >> One example: >> Open a new document, language is set to English. >> Enter a word enclosed in smart quotes. >> Change document language to German with the corresponding smart quotes. > > (it actually suffices to change the smart quotes) > >> Enter a word enclosed with smart quotes. >> Enter a third word, this time enclosing it with direct quotes (Opt-^ / >> Opt-2) > > This is a locale/system specific input. I assume you mean insert the Unicode > characters „ and “ (here on Linux with locale de-UTF8 it is AltGr-V AltGr-B). > Yes. In any case: this is the direct-input I meant. >> This results in the following source: >> ``word'' ,,word`` \quotedblbase word\textquotedblleft{} > > This is not the LyX source, it is the LaTeX source which also depends on > document settings: > With Document>Settings>Language>LaTeX encoding Unicode (utf8), this becomes > > ``word'' ,,word`` „word“ > > In the source view pane, you can also set the "format" to LyX to see the LyX > source (or open the file in a text editor). > > Then you realize that this is still inconsistent: > > * smart quotes are converted to LyX insets, e.g. «Wort becomes > >\begin_inset Quotes fld >\end_inset > >Wort > > (a relict from pre-Unicode times) while > > * Unicode quotes are stored as Unicode (fine). > > Also the different export via pseudo-ligatures (`` '') or LICR macros is > inconsistent. > These inconsistencies are there, working as designed, I assumed, for reasons I missed. (Historical) For new documents I strive to have a completely streamlined unicode toolchain. [Whistling while waiting for full biblatex-support… ;) ] > This might be worth a bug report. > Thanks, I was looking for exactly this kind of feedback, also to clarify thoughts and words for such a report. Will this be classified as a bug or an enhancement request? >> When you open the search panel and enter the key-combo used for >> smart-quotes you will get the "ascii-quote" sign and will not find anything. >> When entering the direct German closing quote, you will only find >> \textquotedblleft{}, but not ``. > > Because you find the Unicode character but not the "pseudo-ligature" > (conversion to typographical quotes is done at the font level). > Precisely. >> The ‘smart’-quotes are invisible to search? > > I don't know whether they are found via some "inset name". > > I'd like to see a regexp search, then I could search for > "some .+word.+ and follwing text". > Given the *nix-background of most of the devs I am puzzled why it wasn’t included already. > But this special case would be solved as a nice side effect when the > "smart quote" feature inserts appropriate Unicode characters instead of > the legacy insets from pre-Unicode times. +1 > >> But wouldn’t it be a treat to start it by enhancing the source view with >> a find-in-source facility? > > Which source LyX/LaTeX/HTML/...? All of them? I imagined find-in-source as the least intrusive approach and I am still unsure where this would make the most sense. It does’t matter to me where this is implemented. Ultimately, I like to be able to find everything by using a search and not by close-reading the whole document and the different source-views when revising a document. ERT, formatting-instructions, you name it. Also, basically most of the stuff Insert-menu offers: All hard to find by themselves. Now, where is that next margin-note again? greetings Mike
Re: We will have to change our output for newest LuaTeX
On 2016-05-20, Guillaume Munch wrote: > Le 20/05/2016 19:26, Scott Kostyshak a écrit : >> On Fri, May 20, 2016 at 04:06:22PM +, Guenter Milde wrote: >>> On 2016-05-20, Jean-Marc Lasgouttes wrote: Le 20/05/2016 à 13:17, Guenter Milde a écrit : > On 2016-05-20, Scott Kostyshak wrote: >> There have been some changes in the luatex engine that will be >> shipped with TeX Live 2016 that cause many of our tests to fail >> (500 something instead of 100 something on TL 2015). The root >> issue is discussed on the LuaTeX mailing list at [1]. >> There is a transitional package available, luatex85, that should >> make our current LuaTeX code work. A reasonable approach for now >> would be to use the package if it is available and to not use it >> if not, keeping the rest of our LuaTeX export code the same. ... > We could just add ... \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{} ... >> Should we do this only when we use code that we think needs it? Or >> should we just add it to all of our LuaTeX exports? I propose to do this with every LuaTeX export +3 simple (no LyX-logic required) +1 no risk of LyX getting it wrong -1 eventually spurious package loading > For 2.2 this could be shipped as a module, to be deprecated and updated > into an empty module once LyX decides to adopt the new luatex syntax. I'd rather keep this simple as well: insert \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{} with every LuaTeX export for the next years to come untill we can be safe every user has the new version and can start using the new syntax in our export. Günter
Re: enhancing search: make it find everything; including source
On 2016-05-21, mn wrote: > Currently it seems quite difficult to get the search function to really > find everything that might be in a lyx-document. > One example: > Open a new document, language is set to English. > Enter a word enclosed in smart quotes. > Change document language to German with the corresponding smart quotes. (it actually suffices to change the smart quotes) > Enter a word enclosed with smart quotes. > Enter a third word, this time enclosing it with direct quotes (Opt-^ / > Opt-2) This is a locale/system specific input. I assume you mean insert the Unicode characters „ and “ (here on Linux with locale de-UTF8 it is AltGr-V AltGr-B). > This results in the following source: > ``word'' ,,word`` \quotedblbase word\textquotedblleft{} This is not the LyX source, it is the LaTeX source which also depends on document settings: With Document>Settings>Language>LaTeX encoding Unicode (utf8), this becomes ``word'' ,,word`` „word“ In the source view pane, you can also set the "format" to LyX to see the LyX source (or open the file in a text editor). Then you realize that this is still inconsistent: * smart quotes are converted to LyX insets, e.g. «Wort becomes \begin_inset Quotes fld \end_inset Wort (a relict from pre-Unicode times) while * Unicode quotes are stored as Unicode (fine). Also the different export via pseudo-ligatures (`` '') or LICR macros is inconsistent. This might be worth a bug report. > When you open the search panel and enter the key-combo used for > smart-quotes you will get the "ascii-quote" sign and will not find anything. > When entering the direct German closing quote, you will only find > \textquotedblleft{}, but not ``. Because you find the Unicode character but not the "pseudo-ligature" (conversion to typographical quotes is done at the font level). > The ‘smart’-quotes are invisible to search? I don't know whether they are found via some "inset name". I'd like to see a regexp search, then I could search for "some .+word.+ and follwing text". But this special case would be solved as a nice side effect when the "smart quote" feature inserts appropriate Unicode characters instead of the legacy insets from pre-Unicode times. > (btw: entering `` into the search panel renders it inoperable? > This is on OS X: the input obviously waits for a second compose > character that the acent goes to and doesn’t treat this as a backtick. > Nevertheless, the search button ist dead and when you switch to the > document and back to the search panel one of the `’s is gone. > As a workaround entering space and deleting that right away reactivates > the button.) This is a feature of your system keybindings with "dead" keys. Nothing that can be solved by LyX. Some "dead" keys can be made self-inserting by double press (`` becomes ` and becomes ``). ... > But wouldn’t it be a treat to start it by enhancing the source view with > a find-in-source facility? Which source LyX/LaTeX/HTML/...? Günter
Re: [patch] fix bug 10124 (XHTML export of some symbols)
On 05/21/2016 05:11 AM, Georg Baum wrote: > While testing imagemagick 7 (more on that later) I stumbled upon bug 10124 as > well. It is a simple typo where LyX outputs / instead of . OK for > 2.2.0? Scott's call, of course, but it certainly looks safe to me. Richard
LyX does work with ImageMagick 7
Hi, now I found some time to test and it turned out that some information in this thread is wrong. Therefore I removed the warning from release notes again. 1) Imagemagick 7 does still contain the 'convert' utility. If you install from source on unix, it is simply a symlink to 'magick'. If you use the binary installer on windows, you need to tick the "Install legacy utilities" option in order to install a convert.exe along magick.exe (but for LyX this is no longer needed since we prefer 'magick' if it is available). 2) LyX works perfectly with Imagemagick 7. I tested that without the convert symlink. I could not see any difference to IM 6 (and I made sure I deleted the image cache and reconfigured). I guess what might have lead to the assumption that IM 7 does not work is the fact that the info inset produces text output for .svgz images, but an image link for .png images. This should be changed, modern browsers support svg (but may need uncompressing, I don't know). Georg
Bringing a hidden window to the front on a mac.
If one has 2 documents open in LyX 2.2 in 2 separate windows and one wants to bring the one in the back to the front via the menu View/Hidden/... then (on a mac, OSX 10.11.4) nothing happens. Although the window has been activated, it's not brought to the front. [When switching to e.g. the Finder and then back to LyX by clicking on the LyX icon in the Dock, the hidden window will now be shown in front.] The problem is solved by adding a raise() call to the activateWindow() call in GuiView.cpp (see included patch). Regards, P. De Visschere diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp index c2101f3..89bff9a 100644 --- a/src/frontends/qt4/GuiView.cpp +++ b/src/frontends/qt4/GuiView.cpp @@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, DispatchResult & dr) for (; i != ids.size(); ++i) { GuiView & gv = guiApp->view(ids[i]); if (gv.workArea(*buffer)) { + gv.raise(); gv.activateWindow(); gv.setBuffer(buffer); break;
[patch] fix bug 10124 (XHTML export of some symbols)
While testing imagemagick 7 (more on that later) I stumbled upon bug 10124 as well. It is a simple typo where LyX outputs / instead of . OK for 2.2.0? Georgdiff --git a/src/mathed/MathMacro.cpp b/src/mathed/MathMacro.cpp index e01f7c2..9fe6e15 100644 --- a/src/mathed/MathMacro.cpp +++ b/src/mathed/MathMacro.cpp @@ -1008,7 +1008,7 @@ void MathMacro::mathmlize(MathStream & os) const docstring const xmlname = d->macro_->xmlname(); if (!xmlname.empty()) { char const * type = d->macro_->MathMLtype(); - os << '<' << type << "> " << xmlname << " /<" + os << '<' << type << "> " << xmlname << " '; return; }
enhancing search: make it find everything; including source
Currently it seems quite difficult to get the search function to really find everything that might be in a lyx-document. One example: Open a new document, language is set to English. Enter a word enclosed in smart quotes. Change document language to German with the corresponding smart quotes. Enter a word enclosed with smart quotes. Enter a third word, this time enclosing it with direct quotes (Opt-^ / Opt-2) This results in the following source: ``word'' ,,word`` \quotedblbase word\textquotedblleft{} When you open the search panel and enter the key-combo used for smart-quotes you will get the "ascii-quote" sign and will not find anything. When entering the direct German closing quote, you will only find \textquotedblleft{}, but not ``. The ‘smart’-quotes are invisible to search? So while in the editor, one and the same character representation should be found when searching for it. (Being aware of the diffreent means to achieve it.) (btw: entering `` into the search panel renders it inoperable? This is on OS X: the input obviously waits for a second compose character that the acent goes to and doesn’t treat this as a backtick. Nevertheless, the search button ist dead and when you switch to the document and back to the search panel one of the `’s is gone. As a workaround entering space and deleting that right away reactivates the button.) This is aggravated in old, grown, evolved, revised or collaborated on documents. But I think this could be generalized. It seems to me that it applies to many more use cases, when searching for anything that is not alphabetical text. How can I find instances of direct formatting; e.g. LyX’s italics; set directly so in contrast to defined through ‘logical markup’? How can I search for ERT? (The text in those can be found, not necessarily like ‘the next box’) How can I find graphics, other insets or indeed most of the stuff from the insert-menu? How can I find environments that are not represented in the outline view (i.e.: the navigate-menu could be fuller populated: next language, next footnote etc.)? This looks like quite a list, of course. (Assuming the above documents something more than my ignorance) But wouldn’t it be a treat to start it by enhancing the source view with a find-in-source facility? greetings Mike
Re: Python 2 in release notes
José Matos wrote: > On Monday, May 9, 2016 9:46:01 PM WEST Scott Kostyshak wrote: >> Georg or José, please feel free to make changes to the RELEASE-NOTES >> regarding Python if you think it would make things more clear. >> >> Scott > > I think that Georg's formulation is clear and more correct than what we > have now. Actually it was not correct either, since building LyX works with python 3. I just committed a hopefully better version at 8d4236bd1d95. Georg