Re: change loading of packages to address #9884 or revert or nothing?

[Guenter Milde]

On 2015-12-17, Jean-Marc Lasgouttes wrote:
> Le 17/12/2015 08:05, Guenter Milde a écrit :
>> Why not:

>>4. use option hyperfootnotes=false for hyperref
>>   (either in the \usepackage call or via \hypersetup).

>> Comment 10 http://www.lyx.org/trac/ticket/9884#comment:10
>> says that this is the workaound proposed by the footmisc authors.
>> It would replace footnote hyperlinking by hyperref with footnote
>> hyperlinking by footmisc.

> I do not think that footmisc does footnote hyperlinking.

You are right. 

We will have to live with the incompatibility :-(

Günter

Re: #9717: "Insert regular expression" menu is always visible

[Guillaume Munch]

Le 17/12/2015 23:07, Scott Kostyshak a écrit :

On Thu, Dec 17, 2015 at 10:31:49PM +, Guillaume Munch wrote:


Here's a better solution.


If the previous conversation covers the same topic and you tested,
please put it in.

Scott



Done

Re: [PATCH] three bugfixes

[Scott Kostyshak]

On Thu, Dec 17, 2015 at 04:43:32PM +, Guillaume Munch wrote:

> As for the long term, maybe we could have an option "Copy the master
> preamble" in the document properties dialog in the future, and have this
> preamble also validated against the macros that are included from master.

I would personally like this (ie for my own use). I don't use macros,
but I often find the child-master preamble behavior unintuitive.

I wonder if either of the following would make sense:

1. have a checkbox "Copy the master preamble" in the LaTeX preamble pane
of document settings, which would grey out the text area box.

2. have a radio button with options for "use child preamble only", "use
master preamble only", "prepend master preamble", "append master
preamble".

Option 2 would be more general.

Scott


signature.asc
Description: PGP signature

Re: #9717: "Insert regular expression" menu is always visible

[Scott Kostyshak]

On Thu, Dec 17, 2015 at 10:31:49PM +, Guillaume Munch wrote:

> Here's a better solution.

If the previous conversation covers the same topic and you tested,
please put it in.

Scott


signature.asc
Description: PGP signature

Re: _lyx2lyx tests failing

[Scott Kostyshak]

On Thu, Dec 17, 2015 at 11:49:28AM +0100, Kornel Benko wrote:
> Am Donnerstag, 17. Dezember 2015 um 05:38:54, schrieb Scott Kostyshak 
> 
> > On Thu, Dec 17, 2015 at 09:41:08AM +0100, Kornel Benko wrote:
> > > 
> > > The file 'development/mathmacros/testcases_master_child.lyx' is a zipped 
> > > file.
> > > Removing from tests. 
> > 
> > I see. Thanks.
> > 
> > All lyx2lyx tests pass now for me with Richard's patch.
> > 
> > Scott
> 
> Maybe a better solution would have been to rename testcases_master_child.lyx 
> to testcases_master_child.zip.

I would say do as you think best. My first reaction is that renaming to
.zip (maybe testcases_master_child.lyx.zip would be even better?) would
make it easier to understand. Not sure if it's worth the time. Your
call.

Scott


signature.asc
Description: PGP signature

Re: #9717: "Insert regular expression" menu is always visible

[Guillaume Munch]

Le 17/12/2015 22:06, Guillaume Munch a écrit :

Le 17/12/2015 21:45, Scott Kostyshak a écrit :

On Thu, Dec 17, 2015 at 08:42:50PM +, Guillaume Munch wrote:


Scott probably meant to link to http://www.lyx.org/trac/ticket/9717.

Scott's patch was meant to let us see the contents of greyed-out
(disabled) Submenus, but had the side-effect of always showing the
OptSubmenus too, so there was no more distinction between the two
(apart
in the odd case of an empty OptSubmenu).

The "patch" (just a code sketch written in the browser) amounts to the
attached, the logic of which I am more convinced with now. So I lied
in the other message, my last patch for 2.2.0 is this one.


Seems sensible, though I did not have time to test.



Ok, I'll be waiting for +1.


I had tested so I think combined with Richard's "Seems sensible (in
theory)" we have a +1.



We have a +1! It's in!

But, I just noticed that there is a similar issue with the Edit > Math
OptSubmenu. My patch did not fix this case, because its submenus are
always enabled now, the OptSubmenu believes that it has some enabled
elements, while it truly does not.





Here's a better solution.
>From 5674684e53d5092ee2589db7e8dc2ba151a26dae Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Thu, 17 Dec 2015 22:26:50 +
Subject: [PATCH] Hide OptSubmenus (#9717) (for real this time)

Amend 6cc69343 and d449e7e6. See the latter for the rationale behind this
change.
---
 src/frontends/qt4/Menus.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/frontends/qt4/Menus.cpp b/src/frontends/qt4/Menus.cpp
index 1076144..ea32aac 100644
--- a/src/frontends/qt4/Menus.cpp
+++ b/src/frontends/qt4/Menus.cpp
@@ -419,7 +419,7 @@ void MenuDefinition::addWithStatusCheck(MenuItem const & i)
 if ((cit->kind() == MenuItem::Command
  || cit->kind() == MenuItem::Submenu
  || cit->kind() == MenuItem::Help)
-&& (!i.optional() || cit->status().enabled())) {
+&& cit->status().enabled()) {
 	enabled = true;
 	break;
 }
@@ -1771,7 +1771,7 @@ void Menu::Impl::populate(QMenu & qMenu, MenuDefinition const & menu)
 		else if (m->kind() == MenuItem::Submenu) {
 			QMenu * subMenu = qMenu.addMenu(label(*m));
 			populate(*subMenu, m->submenu());
-			subMenu->setEnabled(m->status().enabled());
+			subMenu->setEnabled(!subMenu->isEmpty());
 		} else {
 			// we have a MenuItem::Command
 			qMenu.addAction(new Action(QIcon(), label(*m),
-- 
2.1.4

Re: #9717: "Insert regular expression" menu is always visible

[Guillaume Munch]

Le 17/12/2015 21:45, Scott Kostyshak a écrit :

On Thu, Dec 17, 2015 at 08:42:50PM +, Guillaume Munch wrote:


Scott probably meant to link to http://www.lyx.org/trac/ticket/9717.

Scott's patch was meant to let us see the contents of greyed-out
(disabled) Submenus, but had the side-effect of always showing the
OptSubmenus too, so there was no more distinction between the two (apart
in the odd case of an empty OptSubmenu).

The "patch" (just a code sketch written in the browser) amounts to the
attached, the logic of which I am more convinced with now. So I lied
in the other message, my last patch for 2.2.0 is this one.


Seems sensible, though I did not have time to test.



Ok, I'll be waiting for +1.


I had tested so I think combined with Richard's "Seems sensible (in
theory)" we have a +1.



We have a +1! It's in!

But, I just noticed that there is a similar issue with the Edit > Math 
OptSubmenu. My patch did not fix this case, because its submenus are 
always enabled now, the OptSubmenu believes that it has some enabled 
elements, while it truly does not.

Re: #9717: "Insert regular expression" menu is always visible

[Scott Kostyshak]

On Thu, Dec 17, 2015 at 08:42:50PM +, Guillaume Munch wrote:

> >>Scott probably meant to link to http://www.lyx.org/trac/ticket/9717.
> >>
> >>Scott's patch was meant to let us see the contents of greyed-out
> >>(disabled) Submenus, but had the side-effect of always showing the
> >>OptSubmenus too, so there was no more distinction between the two (apart
> >>in the odd case of an empty OptSubmenu).
> >>
> >>The "patch" (just a code sketch written in the browser) amounts to the
> >>attached, the logic of which I am more convinced with now. So I lied
> >>in the other message, my last patch for 2.2.0 is this one.
> >
> >Seems sensible, though I did not have time to test.
> >
> 
> Ok, I'll be waiting for +1.

I had tested so I think combined with Richard's "Seems sensible (in
theory)" we have a +1.

Scott


signature.asc
Description: PGP signature

Re: [PATCH] three bugfixes

[Guillaume Munch]

Le 17/12/2015 15:15, Richard Heck a écrit :

On 12/17/2015 08:10 AM, Jean-Marc Lasgouttes wrote:

Le 17/12/2015 03:40, Guillaume Munch a écrit :

Dear list


Here are three small bugfixes, all of which are quite straightforward
(and none change the file format):

1) Limit the size of navigation menus for performance, which I was
speaking about to Jean-Marc somewhere on the bug tracker. This solves
the corner case described in the commit.

This seems OK to me.


Agreed.




2) Work around bug #9841. See . I
could test that git does not complain of a merge conflict anymore in the
described situation.

I understand it is our only short term solution, although such tricks
are only bandaids.


Also fine for now, and this bandaid might be good enough.



Thanks, it's in.

Re: #9717: "Insert regular expression" menu is always visible

[Guillaume Munch]

Le 17/12/2015 15:02, Richard Heck a écrit :

On 12/16/2015 10:35 PM, Guillaume Munch wrote:

Le 17/12/2015 03:00, Richard Heck a écrit :

On 12/16/2015 08:30 PM, Scott Kostyshak wrote:

On Fri, Dec 11, 2015 at 06:40:17PM +, Guillaume Munch wrote:

Le 11/12/2015 18:27, Richard Heck a écrit :

Hide it.

I was not proposing to do the fix though. I only relayed Scott's
question.

Guillaume came up with a fix:
https://www.mail-archive.com/search?l=mid&q=565C63E3.3020102%40posteo.de


I tested it and in limited testing it seemed to work well (fixed the
issue under discussion and didn't appear to change anything else).

However, neither of us knows whether the patch is the correct way to do
things. Does anyone feel like taking a look?


Post it.

rh



Scott probably meant to link to http://www.lyx.org/trac/ticket/9717.

Scott's patch was meant to let us see the contents of greyed-out
(disabled) Submenus, but had the side-effect of always showing the
OptSubmenus too, so there was no more distinction between the two (apart
in the odd case of an empty OptSubmenu).

The "patch" (just a code sketch written in the browser) amounts to the
attached, the logic of which I am more convinced with now. So I lied
in the other message, my last patch for 2.2.0 is this one.


Seems sensible, though I did not have time to test.



Ok, I'll be waiting for +1.

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 12/12/2015 09:47, Enrico Forestieri a écrit :

On Sat, Dec 12, 2015 at 12:34:47AM +, Guillaume Munch wrote:

Le 11/12/2015 22:47, Enrico Forestieri a écrit :

On Fri, Dec 11, 2015 at 06:52:19PM +, Guillaume Munch wrote:


• Defect: The following character (parbreak separator) is not a line
   break (the symbol is misleading). Obtained with Enter Enter Enter.


It breaks a line and introduces a blank line afterwards. Here an
unobtrusive symbol is required (because it is also used for other
reasons explained in the removed documentation) and it is not simple
deciding what to use.


Well in that case I find obtrusive that it looks so close to a usual and
common linebreak inset.


Initially, I used a different color, but this was also criticized...
As I said, any suggestion is welcome, but see below.


I thought that using the same symbol you find on
the Enter key could convey this info. The symbol is heavier than the
line break symbol and easily distinguishable from it.


I agree that after having learned about it, I could distinguish them.
This is going to confuse users nevertheless.


Any change is going to confuse initially. Then one gets accustomed to it.


Of course when there is a change one must get accustomed to it. But I
was speaking of the fact that it is a symbol already used, which is
worse.




You are welcome to propose suggestions.


Yes. I suggest something that conveys the meaning, rather than the
output in the LaTeX source. What is the meaningful purpose of this new
separator? As I understand it at the moment, a variation on the
horizontal bar of the plain separator would be better.


Take into account that this symbol is also going to be output at the
end of (possibly many) lines (where previously LyX was outputting a blank
line), maybe in between of enumeration environments or the likes, so that
a horizontal bar would be very obtrusive (at least to me). Moreover, I
think it would cause still major confusion, as this could be exchanged as
an environment separator (while this would be his function only when it is
alone on a line).


Do you mean that you expect the parbreak separator to be used often on
purpose, instead of a plain separator, not just as the result of a
conversion 2.1 -> 2.2 ?

Maybe I just fail to see its purpose and in particular why it is more
important than the plain separator.


This symbol is essentially representing a latex blank
line and I find its actual shape the best way to convey this concept. For
example, this is how a blank line would be represented in a word processor
when you ask to also show non-printable characters.


This makes no sense to me. In a word processor this symbol would
represent a new line in the final output, and this corresponds to the
new line inset in LyX.

What about a shortened plain separator lowered to the baseline with a
small bar on the end, in other words:
* A bottom right corner ⌟ but elongated (notice that this is Unicode 1.1
and could therefore be used directly, but misses the "elongated" part)
* Something similar to the caracters ⨼ or ⏗ but lowered to the baseline
(and bigger)
* What we have now, without the arrow head, thicker, and down to the
baseline.

Attached is a mock-up using the ⌟ character (what I am actually thinking
of is a bit wider to remind of the plain separator). (Notice that it
would be nice as well to hide the paragraph mark when appropriate.)




What you just explained above is important and deserves to be explained in
the NewInLyX22 wiki as well, IMO. You did more than rework the separators.


Yes, I know. But it takes time and you say "I will do that later", then
you forget it... ATM, I have really no time and even writing this reply
is taking too much of it...


I wrote something very rough based on your explanations at
, do not hesitate to correct it.




• Defect: I do not understand (as a user) the difference with the
   plain separator obtained with Alt+P Enter (which looks better IMO):


The plain separator is simply a separator that does not introduce a
blank line in the output. This is complementary to the parbreak one,
which should take the place of the old separator environment that
introduced a blank line after itself. So, in the places where you
were using the separator environment, you should use the parbreak
separator if you want a blank line afterwards, otherwise you can use
the plain separator (see the removed documentation).


I saw what it did to the output very well. But I don't understand where
I would need this (I'll have a look at the explanations in the
documentation) but more importantly I don't understand why this is so
important that it must be bound to Enter.


Discoverability. Bounding it to Enter, you cannot miss it.


But you just said that the reason for having a "non-obtrusive" symbol
instead of a horizontal line was that it was going to be used at the end
of certain lines, and now you are telling me that the only way to
intro

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 14/12/2015 12:27, Jean-Marc Lasgouttes a écrit :

Le 14/12/2015 12:05, Guillaume Munch a écrit :

You're right, see now second patch attached. It's a fairly simple
change, only adding some information to Georg's displayColAlign(), in
addition to some mechanical refactoring and disabling of horizontal
alignment buttons which were wrongly enabled. See the new commit log.


Thanks for the patches. A couple remarks:
- in switches it would be better to avoid using default:. This way, when
adding a new hull type, we'll get a warning for each un-handled case and
we'll have to think about the right value.


I agree, and thanks for the information. I never know what I am allowed
to expect from c++ compilers, so I tend to imitate the style I find in
the LyX sources...


- if defaultColAlign and defaultColSpace are broken in some way, the
least we shell do is add a FIXME in the source. Deciding what to do with
them would be even better.


Yes: are these data used in output formats different from LaTeX (e.g. 
LyXHTML)? Then we should add a FIXME. Otherwise they are useless and we 
can remove them.



Guillaume

Re: [PATCH] three bugfixes

[Guillaume Munch]

Le 17/12/2015 15:13, Richard Heck a écrit :

On 12/17/2015 08:10 AM, Jean-Marc Lasgouttes wrote:

Le 17/12/2015 03:40, Guillaume Munch a écrit :

3) Use the parent's preamble to preview the child. See
. I could test that the previews in
my child document display correctly now.

I can predict that this will cause a regression for some user who relies
on the old behavior.
Personally, I use child documents for creating either a set of slides or
handouts from the same document (hand made solution based on foiltex).
Master and child are quite distinct things here. Assuming that the child
document preamble should not be taken in account, is just annoying a
different set of users (not yet me AFAICS).


Yes, I agree that this is very delicate. There are related issues when a
child contains different modules from the master, or different other
settings. We really need to figure out better how to manage that entire
situation.




Yet something is wrong: we output macros from the parent document for
preview, but not the packages these macros depend on... Also, in terms
of whether the previews succeed at all, I can think of sensible
situations where the child does not compile but the master does, not the
other way around.

Further, by looking up the origin of the line that I changed, I found
the following ticket and comment by Jürgen:

   http://www.lyx.org/trac/ticket/8445#comment:8

   “I have to add that the downside of this change is that preview won't
   work for documents anymore which are children but have their own
   preamble stuff which is necessary for the preview (i.e. documents
   used as standalone documents but with their masters open). We have
   to decide for either master settings or child settings here. This is
   a rather arbitrary decision. With source preview, we allow both (via
   a checkbox "master perspective").

   However, I think that the change is most sensible given what users
   probably expect, and it strikes me overkill to introduce a toogle
   between the two perspectives here as well.”

I am confused now because it seems to be saying that outputting the
master preamble was already the intended meaning after the fix to 8445.
Jürgen, is this correct or am I misinterpreting? I miss what is the
effect of just setting is_child. Do you have an opinion about changing
this line of yours with my patch?


As for the long term, maybe we could have an option "Copy the master
preamble" in the document properties dialog in the future, and have this
preamble also validated against the macros that are included from master.


Guillaume

Re: _lyx2lyx tests failing

[Richard Heck]

On 12/16/2015 06:31 PM, Scott Kostyshak wrote:
>
> By the way, Richard are you able to run the tests? You can just build
> with CMake:
> # better to build from a separate build directory. Then instead of '.'
> # give the path to the repo.
> cmake . && make
> and then run with
> ctest -R "lyx2lyx"

I never have used cmake, I don't think.

Richard

Re: [PATCH] three bugfixes

[Richard Heck]

On 12/17/2015 08:10 AM, Jean-Marc Lasgouttes wrote:
> Le 17/12/2015 03:40, Guillaume Munch a écrit :
>> Dear list
>>
>>
>> Here are three small bugfixes, all of which are quite straightforward
>> (and none change the file format):
>>
>> 1) Limit the size of navigation menus for performance, which I was
>> speaking about to Jean-Marc somewhere on the bug tracker. This solves
>> the corner case described in the commit.
> This seems OK to me.

Agreed.

>
>> 2) Work around bug #9841. See . I
>> could test that git does not complain of a merge conflict anymore in the
>> described situation.
> I understand it is our only short term solution, although such tricks
> are only bandaids.

Also fine for now, and this bandaid might be good enough.

Richard

Re: [PATCH] three bugfixes

[Richard Heck]

On 12/17/2015 08:10 AM, Jean-Marc Lasgouttes wrote:
> Le 17/12/2015 03:40, Guillaume Munch a écrit :
>> 3) Use the parent's preamble to preview the child. See
>> . I could test that the previews in
>> my child document display correctly now.
> I can predict that this will cause a regression for some user who relies
> on the old behavior.
> Personally, I use child documents for creating either a set of slides or
> handouts from the same document (hand made solution based on foiltex).
> Master and child are quite distinct things here. Assuming that the child
> document preamble should not be taken in account, is just annoying a
> different set of users (not yet me AFAICS).

Yes, I agree that this is very delicate. There are related issues when a
child contains different modules from the master, or different other
settings. We really need to figure out better how to manage that entire
situation.

Richard

Re: _lyx2lyx tests failing

[Richard Heck]

On 12/17/2015 05:38 AM, Scott Kostyshak wrote:
> On Thu, Dec 17, 2015 at 09:41:08AM +0100, Kornel Benko wrote:
>> The file 'development/mathmacros/testcases_master_child.lyx' is a zipped 
>> file.
>> Removing from tests. 
> I see. Thanks.
>
> All lyx2lyx tests pass now for me with Richard's patch.

Pushed then.

Richard

Re: #9717: "Insert regular expression" menu is always visible

[Richard Heck]

On 12/16/2015 10:35 PM, Guillaume Munch wrote:
> Le 17/12/2015 03:00, Richard Heck a écrit :
>> On 12/16/2015 08:30 PM, Scott Kostyshak wrote:
>>> On Fri, Dec 11, 2015 at 06:40:17PM +, Guillaume Munch wrote:
 Le 11/12/2015 18:27, Richard Heck a écrit :
> Hide it.
 I was not proposing to do the fix though. I only relayed Scott's
 question.
>>> Guillaume came up with a fix:
>>> https://www.mail-archive.com/search?l=mid&q=565C63E3.3020102%40posteo.de
>>>
>>>
>>> I tested it and in limited testing it seemed to work well (fixed the
>>> issue under discussion and didn't appear to change anything else).
>>>
>>> However, neither of us knows whether the patch is the correct way to do
>>> things. Does anyone feel like taking a look?
>>
>> Post it.
>>
>> rh
>>
>
> Scott probably meant to link to http://www.lyx.org/trac/ticket/9717.
>
> Scott's patch was meant to let us see the contents of greyed-out
> (disabled) Submenus, but had the side-effect of always showing the
> OptSubmenus too, so there was no more distinction between the two (apart
> in the odd case of an empty OptSubmenu).
>
> The "patch" (just a code sketch written in the browser) amounts to the
> attached, the logic of which I am more convinced with now. So I lied
> in the other message, my last patch for 2.2.0 is this one.

Seems sensible, though I did not have time to test.

rh

Re: [PATCH] three bugfixes

[Jean-Marc Lasgouttes]

Le 17/12/2015 03:40, Guillaume Munch a écrit :
> Dear list
> 
> 
> Here are three small bugfixes, all of which are quite straightforward
> (and none change the file format):
> 
> 1) Limit the size of navigation menus for performance, which I was
> speaking about to Jean-Marc somewhere on the bug tracker. This solves
> the corner case described in the commit.

This seems OK to me.

> 2) Work around bug #9841. See . I
> could test that git does not complain of a merge conflict anymore in the
> described situation.

I understand it is our only short term solution, although such tricks
are only bandaids.

> 3) Use the parent's preamble to preview the child. See
> . I could test that the previews in
> my child document display correctly now.

I can predict that this will cause a regression for some user who relies
on the old behavior.
Personally, I use child documents for creating either a set of slides or
handouts from the same document (hand made solution based on foiltex).
Master and child are quite distinct things here. Assuming that the child
document preamble should not be taken in account, is just annoying a
different set of users (not yet me AFAICS).

What would make sense IMO would be to output both preambles in this
case. But it requires some care to get right. Or to remember in what
mode the document was output last time (child only or child+master).

JMarc

Re: change loading of packages to address #9884 or revert or nothing?

[Jean-Marc Lasgouttes]

Le 17/12/2015 08:05, Guenter Milde a écrit :
> Why not:
> 
>4. use option hyperfootnotes=false for hyperref
>   (either in the \usepackage call or via \hypersetup).
> 
> Comment 10 http://www.lyx.org/trac/ticket/9884#comment:10
> says that this is the workaound proposed by the footmisc authors.
> It would replace footnote hyperlinking by hyperref with footnote
> hyperlinking by footmisc.

I do not think that footmisc does footnote hyperlinking.

JMarc

Re: [LyX/master] autotests: Sort and review patterns for test categorization and labeling.

[Kornel Benko]

Am Donnerstag, 17. Dezember 2015 um 12:49:13, schrieb Guenter Milde 

> On 2015-12-17, Kornel Benko wrote:
> > Am Donnerstag, 17. Dezember 2015 um 06:57:10, schrieb Guenter Milde 
> > 
> >> On 2015-12-17, Kornel Benko wrote:
> >> >> commit 1e06e83e309585186844659c05d7fc63d73185f5
> >> >> Author: Günter Milde 
> >> >> Date:   Thu Dec 17 00:33:44 2015 +0100
> >> >> autotests: Sort and review patterns for test categorization and
> >> >> labeling.
> 
> >> > 1.) Please revert. It is impossible to check the changes.
> >> >  I always try to make as little change as possible.
> 
> >> > 2.) Why are the Sublabel: commented?
> 
> >> They are commented in order to keem the changes as little as possible.
> 
> ...
> 
> >> How could we proceed?
> 
> > In the meantime I checked too. All tests would be executed as before,
> > so I am relieved. I think, it is good idea to collect according to
> > fail-reason.
> 
> There is one change, thoug regarding Taiwanese: it is now handled analogue to
> Korean, i.e. moved to ignoredTests.
> 
> > 1.) Changing comments
> > I have no problems here, because you are the expert.
> > 2.) Sorting
> > No problem from my side, I appreciate it.
> > 3.) Changing the regular expressions
> > Again, no problem
> 
> > The problem I have, is that all 3 tasks are done in 1 step.
> 
> Should the now reverted commit be splitted, too or is it OK to re-revert?
> 
> > I would start with 1.)
> > next commit 3.)
> > next commit 2.)
> 
> I'd prefer to do these steps together but split the changes by
> "topic", as this fits better into my workflow, i.e. 
> 
> 1. Sort patterns regarding Math
> 2. adapt comments for these patterns
> 3. adapt the regexp to be 
> - most simple
> - accurate (searching for one problem)

OK

> and then commit this in one step, the next could be Spanish with Luatex,
> say...
> 
> > And allow labels again.
> 
> As 4th step?

From the start on.

> (I only commented my new labels. The "tentative" sub-label "chemgreek" was
> removed in the sorting process, as half of the entries were wrong.)

That's OK, it was there only as an example anyway.

> Günter

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] autotests: Sort and review patterns for test categorization and labeling.

[Guenter Milde]

On 2015-12-17, Kornel Benko wrote:
> Am Donnerstag, 17. Dezember 2015 um 06:57:10, schrieb Guenter Milde 
> 
>> On 2015-12-17, Kornel Benko wrote:
>> >> commit 1e06e83e309585186844659c05d7fc63d73185f5
>> >> Author: Günter Milde 
>> >> Date:   Thu Dec 17 00:33:44 2015 +0100
>> >> autotests: Sort and review patterns for test categorization and
>> >> labeling.

>> > 1.) Please revert. It is impossible to check the changes.
>> >I always try to make as little change as possible.

>> > 2.) Why are the Sublabel: commented?

>> They are commented in order to keem the changes as little as possible.

...

>> How could we proceed?

> In the meantime I checked too. All tests would be executed as before,
> so I am relieved. I think, it is good idea to collect according to
> fail-reason.

There is one change, thoug regarding Taiwanese: it is now handled analogue to
Korean, i.e. moved to ignoredTests.

> 1.) Changing comments
>   I have no problems here, because you are the expert.
> 2.) Sorting
>   No problem from my side, I appreciate it.
> 3.) Changing the regular expressions
>   Again, no problem

> The problem I have, is that all 3 tasks are done in 1 step.

Should the now reverted commit be splitted, too or is it OK to re-revert?

> I would start with 1.)
> next commit 3.)
> next commit 2.)

I'd prefer to do these steps together but split the changes by
"topic", as this fits better into my workflow, i.e. 

1. Sort patterns regarding Math
2. adapt comments for these patterns
3. adapt the regexp to be 
- most simple
- accurate (searching for one problem)

and then commit this in one step, the next could be Spanish with Luatex,
say...

> And allow labels again.

As 4th step?

(I only commented my new labels. The "tentative" sub-label "chemgreek" was
removed in the sorting process, as half of the entries were wrong.)

Günter

Re: _lyx2lyx tests failing

[Kornel Benko]

Am Donnerstag, 17. Dezember 2015 um 05:38:54, schrieb Scott Kostyshak 

> On Thu, Dec 17, 2015 at 09:41:08AM +0100, Kornel Benko wrote:
> > 
> > The file 'development/mathmacros/testcases_master_child.lyx' is a zipped 
> > file.
> > Removing from tests. 
> 
> I see. Thanks.
> 
> All lyx2lyx tests pass now for me with Richard's patch.
> 
> Scott

Maybe a better solution would have been to rename testcases_master_child.lyx to 
testcases_master_child.zip.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: _lyx2lyx tests failing

[Scott Kostyshak]

On Thu, Dec 17, 2015 at 09:41:08AM +0100, Kornel Benko wrote:
> 
> The file 'development/mathmacros/testcases_master_child.lyx' is a zipped file.
> Removing from tests. 

I see. Thanks.

All lyx2lyx tests pass now for me with Richard's patch.

Scott


signature.asc
Description: PGP signature

Re: What is our goal for 2.2 regarding the export tests?

[Guenter Milde]

On 2015-12-17, Kornel Benko wrote:
> Am Donnerstag, 17. Dezember 2015 um 01:25:35, schrieb Scott Kostyshak 
> 
>> A big thanks to Kornel and Günter for all of their work on the export
>> tests. These will catch regressions and make us more confident in our
>> releases going forward.

...

>> What is a reasonable expectation of the output of 'ctest' with the
>> following?

>>   -DLYX_ENABLE_EXPORT_TESTS=ON

> Yesterday I had 0 failures with the command
>   #ctest -j12 -L export -E "xhtml|lyx16"
> (about 2800 tests)

> Today, after the many changes, I don't know.
These are now reverted.

Generally, as it is quite easy to invert a test or mark it as unreliable,
the goal should be 0 test-failures.

No test-failures means that all export-failures are recognized as one of

* correct fail (e.g. TeX limitations prevent export to a certain format)

* tolerable (e.g. failures for "exotic" documents with non-default output
  format)
  
* unreliable (e.g. failures due to non-standard requirements, failures
  depending on local configuration, "erratic" behaviour (dependong on phase
  of the moon)
  
* TODO item (e.g. LyX bugs that wait for someone to fix them or
  test-failures that still need proper categorization)

It does not mean that there are no bugs or errors.

Günter

Re: _lyx2lyx tests failing

[Kornel Benko]

Am Mittwoch, 16. Dezember 2015 um 18:31:06, schrieb Scott Kostyshak 

> On Wed, Dec 16, 2015 at 09:03:48AM -0500, Richard Heck wrote:
> > On 12/14/2015 03:48 PM, Georg Baum wrote:
> > > Jean-Marc Lasgouttes wrote:
> > >
> > >> Le 13/12/2015 17:10, Richard Heck a écrit :
> > >>> On 12/13/2015 04:28 AM, Georg Baum wrote:
> >  Richard Heck wrote:
> > 
> > > Patch.
> >  Why is font_math not required? In current master it is always written,
> >  and if this was not required in former versions, then there should be
> >  some lyx2lyx step to add it (like for \use_xetex). The other change
> >  looks good.
> > >>> I can do it the other way, i.e., have it added in lyx2lyx. But the
> > >>> lyx2lyx code does not otherwise seem to demand it. Nor does LyX itself, 
> > >>> which will default to "auto" if it's not set.
> > > OK, I was not aware of that when I wrote the lyx2lyx code.
> > >
> > >> I think we try to avoid relying on default values, because they may
> > >> change.
> > > Indeed. Actually I do not care very much, so skipping the warning in 
> > > lyx2lyx 
> > > would be fine with me as well, but if this is done, then it should be 
> > > done 
> > > for all font settings, since they are all optional in LyX.
> > 
> > I guess I agree with JMarc in the end: It should have been set
> > explicitly in the conversion to 440. This is easy enough to do.
> > 
> > New patch attached. OK?
> 
> Tested and works well. It fixes four of the five tests that were
> failing. One test still fails (but it was failing before your patch
> also and appears to be a separate error):
> 
> 4615/4645 Testing: _lyx2lyx/mathmacros/testcases_master_child

The file 'development/mathmacros/testcases_master_child.lyx' is a zipped file.
Removing from tests. 

> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: beamer workflow

[Jürgen Spitzmüller]

2015-12-17 1:28 GMT+01:00 Guillaume Munch :

> In fact, it is as if a more appropriate feature to enclose a frame was a
> custom inset, instead of a custom paragraph style with nesting. At the
> very least it sounds like an issue that requires some more thinking and
> some choices to make...
>

We seriously considered this, but the custom inset has too mucu drawbacks
(for instance when it comes to outliner reordering).

Please refer to the archives, I do not have time now to elaborate.

Jürgen



>
>
> Guillaume
>
>
>