Re: Behavior of overset inset creation on selection
On Tue, Nov 06, 2018 at 07:23:19AM -1000, Jean-Marc Lasgouttes wrote: > Le 06/11/2018 à 07:19, Scott Kostyshak a écrit : > > Tested and it works well! I tested a few different "Frame decorations". > > I also tested writing "x" in math mode, selecting it and then writing > > "\cases". Now the cursor is put in the second box of cases, and I think > > that is nice. I like it! > > I've got to finish it, then. OK, let me know if there's anything you want me to test. > Another feature: when one inserts \hat over "x", the cursor will be outside > of the newly created inset. Nice! I like that. Scott signature.asc Description: PGP signature
Re: Behavior of overset inset creation on selection
Le 06/11/2018 à 07:19, Scott Kostyshak a écrit : Tested and it works well! I tested a few different "Frame decorations". I also tested writing "x" in math mode, selecting it and then writing "\cases". Now the cursor is put in the second box of cases, and I think that is nice. I like it! I've got to finish it, then. Another feature: when one inserts \hat over "x", the cursor will be outside of the newly created inset. JMarc
Re: Alignment of section titles in KOMA classes for RTL
Le 05/11/2018 à 06:29, Richard Kimberly Heck a écrit : On 11/4/18 2:49 PM, Guy Rutenberg wrote: Hi, In the regular document classes, if a document's main language is Hebrew, than alignment in LyX's display of section titles is context-dependent (right if Hebrew, left otherwise). In the Koma classes (for example KOMA-Script article) it does not work that way. See ticket https://www.lyx.org/trac/ticket/11365 JMarc
Re: Behavior of overset inset creation on selection
On Mon, Nov 05, 2018 at 09:59:04PM -1000, Jean-Marc Lasgouttes wrote: > Le 05/11/2018 à 05:43, Scott Kostyshak a écrit : > > > Please try the attached and tell me if you like it. > > > > For me it doesn't make much of a difference for the use case I > > mentioned. I now get the attached screenshot with those steps. Either > > with this patch or without this patch, I need to click (or move with > > cursor) on the box above "=" to enter "def" to get my desired output. > > I indeed forget to test the initial use case. It was not working as > intended. > > Try this pair of patch instead. The first one changes several classes so > that cell 0 is he 'main' cell. This makes many things simpler IMO. > > The second patch is the one which does the requested change. Tested and it works well! I tested a few different "Frame decorations". I also tested writing "x" in math mode, selecting it and then writing "\cases". Now the cursor is put in the second box of cases, and I think that is nice. I like it! Thanks, Scott signature.asc Description: PGP signature
Re: Debugging question
Am Montag, 5. November 2018 18:14:03 CET schrieb Kornel Benko :
> Am Montag, 5. November 2018 11:20:33 CET schrieb Richard Kimberly Heck
> :
> > On 11/4/18 5:35 AM, Kornel Benko wrote:
> > > I am hunting an error, which only shows if I disable the debug output.
> > > So, using '-dbg find', there is no error, the findadv routines work OK.
> > >
> > > Without this, the outcome is surprising.
> > > For instance open a file with some text in English and some in another
> > > languages.
> > >
> > > In findadv deselect 'igmore format'
> > > use regex '.+' and set the lang of regex to English
> > >
> > > Now, sometimes, not the whole English part is found.
> > > The following search will find the remaining (or again only a part of the
> > > remaining) and so on.
> > >
> > > The question is: What the hell is going on here? The code is the same,
> > > only the debug output changes the behaviour.
> > > Also debugging is difficult, because the wrong behaviour does not
> > > appear consistently.
> >
> > That makes it sound like some kind of race condition. Are we doing
> > background processing here somewhere?
>
> According to outputs of the debugger, yes. Plenty. But I thought,
> the reason was QT.
>
> > Riki
>
> For me it looks like some variables are not initialized correctly in calls to
> TeXOnePar().
> Indication to this is the following behavior:
> 1.) Start searching for bold strings (no ignore format)
> \textbf{\regexp{.+\endregexp{}}
> 2.) After a while (many string found and correct) there is a too short match,
> then the next and so on.
>
> Later, starting anew on the position where the wrong matches previously
> started, all matches are OK at first,
> and the wrong matches are coming at another position.
>
> But NEVER seen under gdb or if the debug 'find' is in effect.
>
> Kornel
SOLVED.
Apparently the error was in my code, 1 variable not initialized.
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: Policy for breaking compilation with -Werror
Am Montag, 5. November 2018 23:52:03 CET schrieb Jean-Marc Lasgouttes : > Le 05/11/2018 à 23:10, Kornel Benko a écrit : > > I will try, but I fear I do not understand. > > If the variables are global, does that mean that they are accessible from > > anywhere? > > I'd prefer them to be private. > > > > Or, if it is not too much work, could you do the change? > > I will try to propose something. > > JMarc > Thanks Jean-Marc. Kornel signature.asc Description: This is a digitally signed message part.
Re: Policy for breaking compilation with -Werror
Le 05/11/2018 à 23:10, Kornel Benko a écrit : I will try, but I fear I do not understand. If the variables are global, does that mean that they are accessible from anywhere? I'd prefer them to be private. Or, if it is not too much work, could you do the change? I will try to propose something. JMarc
Re: Policy for breaking compilation with -Werror
Am Montag, 5. November 2018 22:05:26 CET schrieb Jean-Marc Lasgouttes : > Le 04/11/2018 à 22:15, Kornel Benko a écrit : > > Am Sonntag, 4. November 2018 14:50:00 CET schrieb Jean-Marc Lasgouttes > > : > >> Kornel, what if setIgnoreFormat() was renamed to set()? Then calling > >> IgnoreFormats::set() is not really worse than your setIgnoreFormat() > >> helper? > > > > It is not meant as a convenient debugging function. I was hoping to use > > this function > > from a dialog where one would set ignoring options. > > I stand corrected, then. > > > Please no. We need exactly the same data for all subsequent matches. I > > prefer > > to not recreate them each time. And if we recreate it, we need another set > > of static vars > > for initialization ... this makes no sense for me. > > So what you are describing is a global variable. I think it is better in > general to get rid of the static specifiers and declare a global > function of this type. Yes, that was the intent ... apparently I failed. > Then you should make sure that your function setIgnoreFormat is declared > outside of the big anonymous namespace. This means that the class itself > should be declared outside of the namespace. I will try, but I fear I do not understand. If the variables are global, does that mean that they are accessible from anywhere? I'd prefer them to be private. Or, if it is not too much work, could you do the change? > JMarc Kornel signature.asc Description: This is a digitally signed message part.
Re: Policy for breaking compilation with -Werror
Le 04/11/2018 à 22:15, Kornel Benko a écrit : Am Sonntag, 4. November 2018 14:50:00 CET schrieb Jean-Marc Lasgouttes : Kornel, what if setIgnoreFormat() was renamed to set()? Then calling IgnoreFormats::set() is not really worse than your setIgnoreFormat() helper? It is not meant as a convenient debugging function. I was hoping to use this function from a dialog where one would set ignoring options. I stand corrected, then. Please no. We need exactly the same data for all subsequent matches. I prefer to not recreate them each time. And if we recreate it, we need another set of static vars for initialization ... this makes no sense for me. So what you are describing is a global variable. I think it is better in general to get rid of the static specifiers and declare a global function of this type. Then you should make sure that your function setIgnoreFormat is declared outside of the big anonymous namespace. This means that the class itself should be declared outside of the namespace. JMarc
