Re: Crash in findadv
On Sun, Oct 14, 2018 at 04:58:51PM -0400, Scott Kostyshak wrote: > On Sun, Oct 14, 2018 at 08:48:33PM +0200, Kornel Benko wrote: > > Am Sonntag, 14. Oktober 2018 10:59:08 CEST schrieb Scott Kostyshak > > : > > > On Sun, Oct 14, 2018 at 08:11:19AM +0200, Kornel Benko wrote: > > > > > > > I agree. OTOH, I need it while debugging. Do you know how to trick the > > > > compiler? > > > > For now, I will remove the routine > > > > > > Maybe this? > > > > > > https://stackoverflow.com/a/3394268/1376404 > > > > > > Scott > > > > Yes, some pragma would be OK. > > > > If I understood correctly > > > > #pragma GCC diagnostic push > > #pragma GCC diagnostic ignored "-Werror" > > > > some unused code > > > > #pragma GCC diagnostic pop > > > > could do it. > > Thanks for fixing it (I just compiled current master without error). I > know it's not fun to spend time fixing something that is not really > broken, but I'm happy to have -Werror back. Compilation with -Werror seems to be broken again at d6cc58f4. Scott signature.asc Description: PGP signature
Re: GUI indicator for a command environment
On 10/18/18 2:01 PM, Paul A. Rubin wrote:
> On 10/17/18 7:09 PM, Richard Kimberly Heck wrote:
>> On 10/17/18 2:35 PM, Paul A. Rubin wrote:
>>> On 10/17/18 11:24 AM, Richard Kimberly Heck wrote:
On 10/17/18 9:30 AM, Paul A. Rubin wrote:
> On 10/16/18 10:24 PM, Andrew Parsloe wrote:
>> On 17/10/2018 4:47 a.m., Paul A. Rubin wrote:
>>> Dear devs,
>>>
>>> I'm struggling to cobble together a module supporting the
>>> pseudocode features of the algorithmicx package. As a
>>> disclaimer, I'm trying to avoid flex insets and stick to
>>> environments as much as possible, because there's less mousery
>>> switching an environment than insert an inset.
>>>
>>> Right now, I'm tripping over the for block, which it implements
>>> by two LaTeX commands: \For{} and \EndFor. I can
>>> treat those as command styles and get the correct output, but
>>> the GUI is confusing to the user because nothing displays in the
>>> line ending the loop (it looks like a blank line to the user)
>>> and the condition appears in the starting line with no visible
>>> prefix (so it looks like any random statement in the algorithm,
>>> unless you notice what the environment select box is displaying.
>>>
>>> So what I'm looking for right now is a way to display a
>>> tag/prefix/symbol at the start of a command style that appears
>>> in the GUI but /not/ in the compiled output. The "handle" for an
>>> inset would be fine, as would something like a bullet that was
>>> GUI-only. Can this be done with the current layout/module system?
>>>
>>> TIA,
>>> Paul
>> Is this what you are wanting (from Customization manual 5.3.7)?
>> (I experimented with this a couple of years ago, so my memory of
>> the exact effect is somewhat hazy.)
>>
>> Andrew
>>
>> |LabelType|
>> [|/No_Label/, Manual, Static, Above,
>> Centered, Sensitive, Enumerate,
>> Itemize, Bibliography|]
>>
>> |Static|
>> means the label is simply what is declared as
>> |LabelString|. This will be displayed “inline”, at the
>> beginning of the paragraph. If the |LatexType| is
>> |Environment|, then it will be displayed only in the
>> first paragraph of any sequence of paragraphs with the
>> same |Style|.
>> |Above| and |Centered|
>> are special cases of |Static|. The label will be printed
>> above the paragraph either at the beginning of the line
>> or centered.
>>
>>
>>
>>
>>
>> Virus-free. www.avast.com
>>
>>
>>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> Thanks for the reply, but no, that doesn't work. With a command
> type style (and combined with a LabelString argument) it does not
> seem to do anything in either the GUI or the output. I tried it
> with an environment, and I believe the label string showed up in
> the output but not the GUI. (I would have to double-check that.)
Try this in Local Layout (to test):
Format 66
Style ForLoop
LatexType Command
LabelType Static
LabelString "ForLoop: "
EndLabelType Static
Margin Static
LeftMargin "ForLoop: "
LabelFont
Color red
Series bold
EndFont
EndLabelString " EndForLoop"
LatexName forloop
End
The margin always throws me off. If it's wrong, the label is off
screen to the left.
You could also try "LabelType Above" and remove the margin stuff.
Riki
>>> Thanks Riki! That at least gets me headed in the right direction. I
>>> don't know why I wasn't getting the label string to display before
>>> -- maybe because I failed to specify the Margin, LeftMargin or
>>> LabelFont? (I did specify LabelType and LabelString, with no luck.)
>>>
>>> The margin business is going to be interesting. Your code has the
>>> correct left margin when select the ForLoop style from the
>>> environment list, but when I nest it (inside an algorithmicx
>>> environment) the label moves to the left (I would have expected
>>> right) and blows the left margin. I expect that an exhaustive try of
>>> all choices will eventually find one that works.
>>
>> It would not surprise me if there were a bug here about margin
>> handling. Can you send an MWE? Put any new layout code into Local Layout.
>>
>> Riki
>>
>>
> I think the attached MWE shows what I was talking about. (At least, it
> does for me.) To avoid requiring any special packages, I'm using the
> quote environment as a surrogate for the algorithmic environment
Re: Confusing layout list filter
On 10/18/18 3:54 AM, Daniel wrote: > On 2018-10-17 18:30, Richard Kimberly Heck wrote: >> On 10/17/18 12:02 PM, Daniel wrote: >>> On 17/10/2018 17:11, Richard Kimberly Heck wrote: > > [...] > I've fixed all this in master. It'll go to 2.3.3, if all is well. Riki >>> >>> Thanks! I am looking forward to what filter you opted for. >> >> Just consecutive letters, anywhere in the string. Probably I should >> update it a bit to allow the user to enter regular expressions that >> won't be messed with. So then one could enter e.g. "^sec" to get quickly >> to "section". The question is how exactly to do this. I was thinking to >> do it vi-like, and have "/" activate "regex mode", as we might put it. >> So you'd enter "/^sec" to get quickly to "section". But maybe that's >> overthinking it, and we could just have some character mean: Only search >> at the start of the string. So then maybe "/sec" works, or "^sec". Of >> course, that would fail if someone made a layout whose name actually >> began with such a character. But then maybe they deserve what they get. > > Seems to me that consecutive letters is good enough. Yes, probably. > Right now one can see what one types from the underlined letters. > Actually, this is already a bit hard to see and I would suggest to do > something less subtle, like using bold font for the highlight rather > than underline. I think that would also look cool. Definitely. Done. > Apart from this, there is actually yet another behavior of the layout > filter that is confusing or "weird" currently. I am not fully sure > what is going on. For example, in plain standard article, > > 1. Select the Standard layout > 2. Filter the layout list for "sub" > > Result: "Subsection" is selected > > Next, > > 1. Select the Part layout > 2. Filter the layout list again for "sub" > > Result: "Subsection*" is selected > > I don't see a reason why this behavior is helpful. Yes, that is weird, but I think it is must be something built into Qt that I have no idea how to change. Riki
Re: [LyX/2.3.x] Fix caret painting
On Thu, Oct 18, 2018 at 05:20:38PM +0200, Jean-Marc Lasgouttes wrote: > Le 14/10/2018 à 05:36, Scott Kostyshak a écrit : > > For some reason, PreviewLoader::Impl::refreshPreviews() is no longer > > called for me. Enrico, can you reproduce? Do you have an idea if the > > code that takes care of the preview regeneration on zoom change could > > have been broken by something? > > Could the culprit be the following commit? I don't think so. I tested the commit before, and I could still reproduce. Scott signature.asc Description: PGP signature
Re: GUI indicator for a command environment
On 10/17/18 7:09 PM, Richard Kimberly Heck wrote:
On 10/17/18 2:35 PM, Paul A. Rubin wrote:
On 10/17/18 11:24 AM, Richard Kimberly Heck wrote:
On 10/17/18 9:30 AM, Paul A. Rubin wrote:
On 10/16/18 10:24 PM, Andrew Parsloe wrote:
On 17/10/2018 4:47 a.m., Paul A. Rubin wrote:
Dear devs,
I'm struggling to cobble together a module supporting the
pseudocode features of the algorithmicx package. As a disclaimer,
I'm trying to avoid flex insets and stick to environments as much
as possible, because there's less mousery switching an
environment than insert an inset.
Right now, I'm tripping over the for block, which it implements
by two LaTeX commands: \For{} and \EndFor. I can
treat those as command styles and get the correct output, but the
GUI is confusing to the user because nothing displays in the line
ending the loop (it looks like a blank line to the user) and the
condition appears in the starting line with no visible prefix (so
it looks like any random statement in the algorithm, unless you
notice what the environment select box is displaying.
So what I'm looking for right now is a way to display a
tag/prefix/symbol at the start of a command style that appears in
the GUI but /not/ in the compiled output. The "handle" for an
inset would be fine, as would something like a bullet that was
GUI-only. Can this be done with the current layout/module system?
TIA,
Paul
Is this what you are wanting (from Customization manual 5.3.7)? (I
experimented with this a couple of years ago, so my memory of the
exact effect is somewhat hazy.)
Andrew
|LabelType|
[|/No_Label/, Manual, Static, Above,
Centered, Sensitive, Enumerate,
Itemize, Bibliography|]
|Static|
means the label is simply what is declared as
|LabelString|. This will be displayed “inline”, at the
beginning of the paragraph. If the |LatexType| is
|Environment|, then it will be displayed only in the first
paragraph of any sequence of paragraphs with the same |Style|.
|Above| and |Centered|
are special cases of |Static|. The label will be printed
above the paragraph either at the beginning of the line or
centered.
Virus-free. www.avast.com
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Thanks for the reply, but no, that doesn't work. With a command
type style (and combined with a LabelString argument) it does not
seem to do anything in either the GUI or the output. I tried it
with an environment, and I believe the label string showed up in
the output but not the GUI. (I would have to double-check that.)
Try this in Local Layout (to test):
Format 66
Style ForLoop
LatexType Command
LabelType Static
LabelString "ForLoop: "
EndLabelType Static
Margin Static
LeftMargin "ForLoop: "
LabelFont
Color red
Series bold
EndFont
EndLabelString " EndForLoop"
LatexName forloop
End
The margin always throws me off. If it's wrong, the label is off
screen to the left.
You could also try "LabelType Above" and remove the margin stuff.
Riki
Thanks Riki! That at least gets me headed in the right direction. I
don't know why I wasn't getting the label string to display before --
maybe because I failed to specify the Margin, LeftMargin or
LabelFont? (I did specify LabelType and LabelString, with no luck.)
The margin business is going to be interesting. Your code has the
correct left margin when select the ForLoop style from the
environment list, but when I nest it (inside an algorithmicx
environment) the label moves to the left (I would have expected
right) and blows the left margin. I expect that an exhaustive try of
all choices will eventually find one that works.
It would not surprise me if there were a bug here about margin
handling. Can you send an MWE? Put any new layout code into Local Layout.
Riki
An addendum to my MWE: by experimenting, I found that "Margin Manual"
fixes the problem of the ForLoop label breaking the left margin (when
embedded in an algorithm environment but not when out in the open). On
the other hand, I have another LaTeX command style that introduces a
LaTeX command with a single required argument (similar to \dummy in my
MWE). To get the label on that to work, "Margin Manual" was the wrong
choice; I needed "Margin Dynamic". Why the two styles differ in the
margin they need is yet another mystery to me.
Paul
Re: GUI indicator for a command environment
On 10/17/18 7:09 PM, Richard Kimberly Heck wrote:
On 10/17/18 2:35 PM, Paul A. Rubin wrote:
On 10/17/18 11:24 AM, Richard Kimberly Heck wrote:
On 10/17/18 9:30 AM, Paul A. Rubin wrote:
On 10/16/18 10:24 PM, Andrew Parsloe wrote:
On 17/10/2018 4:47 a.m., Paul A. Rubin wrote:
Dear devs,
I'm struggling to cobble together a module supporting the
pseudocode features of the algorithmicx package. As a disclaimer,
I'm trying to avoid flex insets and stick to environments as much
as possible, because there's less mousery switching an
environment than insert an inset.
Right now, I'm tripping over the for block, which it implements
by two LaTeX commands: \For{} and \EndFor. I can
treat those as command styles and get the correct output, but the
GUI is confusing to the user because nothing displays in the line
ending the loop (it looks like a blank line to the user) and the
condition appears in the starting line with no visible prefix (so
it looks like any random statement in the algorithm, unless you
notice what the environment select box is displaying.
So what I'm looking for right now is a way to display a
tag/prefix/symbol at the start of a command style that appears in
the GUI but /not/ in the compiled output. The "handle" for an
inset would be fine, as would something like a bullet that was
GUI-only. Can this be done with the current layout/module system?
TIA,
Paul
Is this what you are wanting (from Customization manual 5.3.7)? (I
experimented with this a couple of years ago, so my memory of the
exact effect is somewhat hazy.)
Andrew
|LabelType|
[|/No_Label/, Manual, Static, Above,
Centered, Sensitive, Enumerate,
Itemize, Bibliography|]
|Static|
means the label is simply what is declared as
|LabelString|. This will be displayed “inline”, at the
beginning of the paragraph. If the |LatexType| is
|Environment|, then it will be displayed only in the first
paragraph of any sequence of paragraphs with the same |Style|.
|Above| and |Centered|
are special cases of |Static|. The label will be printed
above the paragraph either at the beginning of the line or
centered.
Virus-free. www.avast.com
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Thanks for the reply, but no, that doesn't work. With a command
type style (and combined with a LabelString argument) it does not
seem to do anything in either the GUI or the output. I tried it
with an environment, and I believe the label string showed up in
the output but not the GUI. (I would have to double-check that.)
Try this in Local Layout (to test):
Format 66
Style ForLoop
LatexType Command
LabelType Static
LabelString "ForLoop: "
EndLabelType Static
Margin Static
LeftMargin "ForLoop: "
LabelFont
Color red
Series bold
EndFont
EndLabelString " EndForLoop"
LatexName forloop
End
The margin always throws me off. If it's wrong, the label is off
screen to the left.
You could also try "LabelType Above" and remove the margin stuff.
Riki
Thanks Riki! That at least gets me headed in the right direction. I
don't know why I wasn't getting the label string to display before --
maybe because I failed to specify the Margin, LeftMargin or
LabelFont? (I did specify LabelType and LabelString, with no luck.)
The margin business is going to be interesting. Your code has the
correct left margin when select the ForLoop style from the
environment list, but when I nest it (inside an algorithmicx
environment) the label moves to the left (I would have expected
right) and blows the left margin. I expect that an exhaustive try of
all choices will eventually find one that works.
It would not surprise me if there were a bug here about margin
handling. Can you send an MWE? Put any new layout code into Local Layout.
Riki
I think the attached MWE shows what I was talking about. (At least, it
does for me.) To avoid requiring any special packages, I'm using the
quote environment as a surrogate for the algorithmic environment and a
dummy LaTeX function as a surrogate for the actual for block code.
Paul
mwe.lyx
Description: application/lyx
Re: [LyX/2.3.x] Fix caret painting
Le 14/10/2018 à 05:36, Scott Kostyshak a écrit : For some reason, PreviewLoader::Impl::refreshPreviews() is no longer called for me. Enrico, can you reproduce? Do you have an idea if the code that takes care of the preview regeneration on zoom change could have been broken by something? Could the culprit be the following commit? I remember thinking that I did not understand how this stuff worked but that the new code was obviously correct :) JMarc commit a31d3dc67dce9655bee9f1b0a2bc2188d7d97453 Author: Jean-Marc Lasgouttes Date: Thu Sep 14 15:50:30 2017 +0200 Compute metrics when graphics is updated Remove the old schedule_redraw_ mechanism that was only useful because of our synchronous drawing code. Now that actual painting is scheduled instead of forced, it becomes pointless. Rename WorkArea::redraw(bool) to scheduleRedraw(bool), to show that the drawing is not done right away. In GuiView::updateInset, call scheduleRedraw(true), so that metrics are correctly computed (this was the whole point of the exercise).
Re: InsetScript Font Size
Le 18/10/2018 à 12:58, Daniel a écrit : On 18/10/2018 02:36, Richard Kimberly Heck wrote: The font in superscripts and subscripts looks to me to be the same size as that of the normal text, when it ought to be smaller. I had a look into this, and I can't see where the font size is set. Help? (We set the font STYLE here, but where is that supposed to make a difference?) Riki There is also some extra space before and after super- and subscript... This is a separate issue which requires a rewrite of the inset frame drawing code. JMarc
Re: InsetScript Font Size
Le 18/10/2018 à 02:36, Richard Kimberly Heck a écrit : The font in superscripts and subscripts looks to me to be the same size as that of the normal text, when it ought to be smaller. I had a look into this, and I can't see where the font size is set. Help? (We set the font STYLE here, but where is that supposed to make a difference?) Riki This information is used by FontInfo::realSize(), which is called by the font loader. I am not sure why it does not work. JMarc
Re: InsetScript Font Size
On 18/10/2018 02:36, Richard Kimberly Heck wrote: The font in superscripts and subscripts looks to me to be the same size as that of the normal text, when it ought to be smaller. I had a look into this, and I can't see where the font size is set. Help? (We set the font STYLE here, but where is that supposed to make a difference?) Riki There is also some extra space before and after super- and subscript... Daniel
Re: Confusing layout list filter
On 2018-10-17 18:30, Richard Kimberly Heck wrote: On 10/17/18 12:02 PM, Daniel wrote: On 17/10/2018 17:11, Richard Kimberly Heck wrote: [...] I've fixed all this in master. It'll go to 2.3.3, if all is well. Riki Thanks! I am looking forward to what filter you opted for. Just consecutive letters, anywhere in the string. Probably I should update it a bit to allow the user to enter regular expressions that won't be messed with. So then one could enter e.g. "^sec" to get quickly to "section". The question is how exactly to do this. I was thinking to do it vi-like, and have "/" activate "regex mode", as we might put it. So you'd enter "/^sec" to get quickly to "section". But maybe that's overthinking it, and we could just have some character mean: Only search at the start of the string. So then maybe "/sec" works, or "^sec". Of course, that would fail if someone made a layout whose name actually began with such a character. But then maybe they deserve what they get. Seems to me that consecutive letters is good enough. Right now one can see what one types from the underlined letters. Actually, this is already a bit hard to see and I would suggest to do something less subtle, like using bold font for the highlight rather than underline. I think that would also look cool. However, if you want to go further and allow for regex, then maybe the current drop down list style should be changed as well since the typed in regex could not be visualized that way. So, I would suggest a combo box, i.e. a drop-down list with an editable one-line textbox. When typing, the drop down list opens and shows the matches. There may also be a couple of follow up obstacles. For example, one would then also have to find a way to deal with selection. Is there a way to preselect an item in the list (that is then selected by pressing return or so) without overwriting what has been typed into the text box? Apart from this, there is actually yet another behavior of the layout filter that is confusing or "weird" currently. I am not fully sure what is going on. For example, in plain standard article, 1. Select the Standard layout 2. Filter the layout list for "sub" Result: "Subsection" is selected Next, 1. Select the Part layout 2. Filter the layout list again for "sub" Result: "Subsection*" is selected I don't see a reason why this behavior is helpful. (But as I said, I don't get the structure at all here.) I think it would be better to select the first match from the top of the list, i.e. independent of what is currently selected. So one would always get the same result when filtering (as long as no new layouts are added). For completeness: Alternatively, the first item after the currently selected item should be selected, so that, for example, when Part* is selected Subsection* would be selected rather than Subsection. But I don't think the benefits of this approach are worth the costs (not only implementation wise but usage wise). And notice that this is also not what is going on currently in LyX. Daniel
