Re: [PATCH] three bugfixes

[Guillaume Munch]

Le 20/12/2015 11:28, Jürgen Spitzmüller a écrit :

Am Samstag 19 Dezember 2015, 23:35:15 schrieb Guillaume Munch:

I tested the patch and it does not solve the reported problem. As I
understand it, it only loads the user preamble from the parent document.
In my test document, \upharpoonright is still not defined because the
macros are still not validated, and \texorpdfstring is still not defined
because the hyperref is still not loaded, so the situation is the same
as before the patch.


OK, so further (similar) additions are needed.

But I did not see an example document here or on trac, so it is hard to help.


Let me ask naively, what is the expected difference with unchecking
"Select master document"?


You mean in Document Settings? It assures the document inherits settings from
the master, even if the master buffer is not opened.

Jürgen





Some discussion occurred at http://www.lyx.org/trac/ticket/9868 during 
the ML shortage. From what I understand so far there is a combination of 
several issues:


1. math macros are not properly validated recursively (nothing to do 
with parent/child relationship).
2. one should output either the child's LyX-generated preamble or the 
master's in the preview latex files, but at least one of them (this 
currently fails for hyperref, mathtools and probably other settings).
3. one should have an option to automatically copy the master's settings 
and preamble (or something).


See the bugtracker for more details.


Guillaume

Re: [PATCH] three bugfixes

[Jürgen Spitzmüller]

Am Samstag 19 Dezember 2015, 23:35:15 schrieb Guillaume Munch:
> I tested the patch and it does not solve the reported problem. As I
> understand it, it only loads the user preamble from the parent document.
> In my test document, \upharpoonright is still not defined because the
> macros are still not validated, and \texorpdfstring is still not defined
> because the hyperref is still not loaded, so the situation is the same
> as before the patch.

OK, so further (similar) additions are needed.

But I did not see an example document here or on trac, so it is hard to help.

> Let me ask naively, what is the expected difference with unchecking 
> "Select master document"? 

You mean in Document Settings? It assures the document inherits settings from 
the master, even if the master buffer is not opened.

Jürgen

Re: [PATCH] three bugfixes

[Richard Heck]

On 12/20/2015 09:42 AM, Guillaume Munch wrote:
> Le 20/12/2015 04:43, Richard Heck a écrit :
>> On 12/19/2015 06:35 PM, Guillaume Munch wrote:
>>>
>>> Let me ask naively, what is the expected difference with unchecking
>>> "Select master document"?
>>
>> I assume you mean "Select default master document"?
>>
>>> (apart from the fact that we need to close the master document and
>>> reopen the child after this, which is a bug obviously, and the fact
>>> that the former parent document is forgotten on reopening, making it
>>> unconvenient to re-enable)
>>
>> I don't think it is a bug. I think perhaps you are misunderstanding the
>> purpose of this setting.
>>
>> Having a *default* master makes it the case that, whenever you open this
>> document directly, it causes the default master to be opened, and for
>> the document you are actually opening to be opened as a child (or
>> grandchild, or ) of that document. This makes sense e.g. for files
>> that are chapters of books: When you edit the chapter, you want it to be
>> edited as a chapter of the book, not as a standalone file. Note that
>> this does *not* mean the same file cannot appear as children of other
>> masters. What it means, in effect, is that the file cannot be edited as
>> a standalone document.
>>
>> But there are other files that can function as children of different
>> masters and that one does want to be able to edit as standalone
>> documents. Or a file that is always used as a child but that it doesn't
>> make sense to associate with a default master. An example of the latter
>> from my own use would be a file of math macros I use in various
>> documents.
>>
>> So, with all that said, suppose a default master was previously selected
>> and one decides to remove that setting. Nothing else does *or should*
>> happen at that time. If the document is currently open as a child (which
>> it will be), then it must remain open as a child. The only other option
>> would be automatically to close the current master, and all of its
>> children, and re-open this document standalone. But that would be
>> totally wrong. Simply saying "I don't want this document any longer, by
>> default, to be a child of some other document" can't also mean: Oh, and
>> by the way, please also close the entire document set of which this was
>> a part, and then re-open this one. We aren't saying this document isn't
>> part of that document set, only that it shouldn't by default be
>> considered part of it. The same goes if one were to change what the
>> default master is.
>>
>> I think it is very unclear what to do here. I think it's a good idea of
>> Jurgen's to allow selection of whether to use the master's params or our
>> own. But I'd add that it would also make sense to allow the child's
>> params to be added to the master's. Consider, again, a file of my
>> favorite math macros. Maybe there are modules that need to be used with
>> these, or some preamble code, and one would think one should be able to
>> indicate those in the macro file and have them always be used when that
>> file is used in some other document. I can imagine thinking that this
>> should be the default behavior when a default master is defined, though
>> I'm not sure about that.
>>
>
>
> Yes, all this parent/child relationship seems quite complicated and ad
> hoc. While testing what would happen when a document has two parents, I
> found the following crash: .

The multi-parent problem has caused crashes before. I'll have a look at
this one.

Richard

Re: [PATCH] three bugfixes

[Guillaume Munch]

Le 20/12/2015 11:28, Jürgen Spitzmüller a écrit :

Am Samstag 19 Dezember 2015, 23:35:15 schrieb Guillaume Munch:

I tested the patch and it does not solve the reported problem. As I
understand it, it only loads the user preamble from the parent document.
In my test document, \upharpoonright is still not defined because the
macros are still not validated, and \texorpdfstring is still not defined
because the hyperref is still not loaded, so the situation is the same
as before the patch.


OK, so further (similar) additions are needed.

But I did not see an example document here or on trac, so it is hard to help.


I added test documents here: . I am 
not pushing for a solution to be found before 2.2.0, since it seems to 
require discussions. Thanks for your help so far.


Guillaume

Re: [PATCH] three bugfixes

[Guillaume Munch]

Le 20/12/2015 04:43, Richard Heck a écrit :

On 12/19/2015 06:35 PM, Guillaume Munch wrote:


Let me ask naively, what is the expected difference with unchecking
"Select master document"?


I assume you mean "Select default master document"?


(apart from the fact that we need to close the master document and
reopen the child after this, which is a bug obviously, and the fact
that the former parent document is forgotten on reopening, making it
unconvenient to re-enable)


I don't think it is a bug. I think perhaps you are misunderstanding the
purpose of this setting.

Having a *default* master makes it the case that, whenever you open this
document directly, it causes the default master to be opened, and for
the document you are actually opening to be opened as a child (or
grandchild, or ) of that document. This makes sense e.g. for files
that are chapters of books: When you edit the chapter, you want it to be
edited as a chapter of the book, not as a standalone file. Note that
this does *not* mean the same file cannot appear as children of other
masters. What it means, in effect, is that the file cannot be edited as
a standalone document.

But there are other files that can function as children of different
masters and that one does want to be able to edit as standalone
documents. Or a file that is always used as a child but that it doesn't
make sense to associate with a default master. An example of the latter
from my own use would be a file of math macros I use in various documents.

So, with all that said, suppose a default master was previously selected
and one decides to remove that setting. Nothing else does *or should*
happen at that time. If the document is currently open as a child (which
it will be), then it must remain open as a child. The only other option
would be automatically to close the current master, and all of its
children, and re-open this document standalone. But that would be
totally wrong. Simply saying "I don't want this document any longer, by
default, to be a child of some other document" can't also mean: Oh, and
by the way, please also close the entire document set of which this was
a part, and then re-open this one. We aren't saying this document isn't
part of that document set, only that it shouldn't by default be
considered part of it. The same goes if one were to change what the
default master is.

I think it is very unclear what to do here. I think it's a good idea of
Jurgen's to allow selection of whether to use the master's params or our
own. But I'd add that it would also make sense to allow the child's
params to be added to the master's. Consider, again, a file of my
favorite math macros. Maybe there are modules that need to be used with
these, or some preamble code, and one would think one should be able to
indicate those in the macro file and have them always be used when that
file is used in some other document. I can imagine thinking that this
should be the default behavior when a default master is defined, though
I'm not sure about that.




Yes, all this parent/child relationship seems quite complicated and ad
hoc. While testing what would happen when a document has two parents, I
found the following crash: .


Guillaume

Re: [PATCH] three bugfixes

[Guillaume Munch]

Le 19/12/2015 13:54, Jürgen Spitzmüller a écrit :

Am Donnerstag 17 Dezember 2015, 16:43:32 schrieb Guillaume Munch:

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?


Yes, I probably thought that this was the case (although it was not the
intended fix; the intended fix was to load the global/master macro definitions)


I miss what is the
effect of just setting is_child.


It adds the information to the output routine that the currently output buffer
functions as a child. The output routine then suppresses some output that
makes no sense for children. See the use of is_child in the source.

It also decides to use master params rather than params where appropriate.
To load the master preamble, one further addition would be necessary. See
attached patch. But as JMarc says, this change will not please everybody.


I tested the patch and it does not solve the reported problem. As I
understand it, it only loads the user preamble from the parent document.
In my test document, \upharpoonright is still not defined because the
macros are still not validated, and \texorpdfstring is still not defined
because the hyperref is still not loaded, so the situation is the same
as before the patch.




Do you have an opinion about changing
this line of yours with my patch?


I would prefer using the is_child parameter instead.


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.


A proper solution would be the option to select between two modes: Inherit
params from master or keep own params. In some documents, both modes make
sense at different times.


Let me ask naively, what is the expected difference with unchecking 
"Select master document"? (apart from the fact that we need to close the 
master document and reopen the child after this, which is a bug 
obviously, and the fact that the former parent document is forgotten on 
reopening, making it unconvenient to re-enable)

Re: [PATCH] three bugfixes

[Richard Heck]

On 12/19/2015 06:35 PM, Guillaume Munch wrote:
>
> Let me ask naively, what is the expected difference with unchecking
> "Select master document"?

I assume you mean "Select default master document"?

> (apart from the fact that we need to close the master document and
> reopen the child after this, which is a bug obviously, and the fact
> that the former parent document is forgotten on reopening, making it
> unconvenient to re-enable)

I don't think it is a bug. I think perhaps you are misunderstanding the
purpose of this setting.

Having a *default* master makes it the case that, whenever you open this
document directly, it causes the default master to be opened, and for
the document you are actually opening to be opened as a child (or
grandchild, or ) of that document. This makes sense e.g. for files
that are chapters of books: When you edit the chapter, you want it to be
edited as a chapter of the book, not as a standalone file. Note that
this does *not* mean the same file cannot appear as children of other
masters. What it means, in effect, is that the file cannot be edited as
a standalone document.

But there are other files that can function as children of different
masters and that one does want to be able to edit as standalone
documents. Or a file that is always used as a child but that it doesn't
make sense to associate with a default master. An example of the latter
from my own use would be a file of math macros I use in various documents.

So, with all that said, suppose a default master was previously selected
and one decides to remove that setting. Nothing else does *or should*
happen at that time. If the document is currently open as a child (which
it will be), then it must remain open as a child. The only other option
would be automatically to close the current master, and all of its
children, and re-open this document standalone. But that would be
totally wrong. Simply saying "I don't want this document any longer, by
default, to be a child of some other document" can't also mean: Oh, and
by the way, please also close the entire document set of which this was
a part, and then re-open this one. We aren't saying this document isn't
part of that document set, only that it shouldn't by default be
considered part of it. The same goes if one were to change what the
default master is.

I think it is very unclear what to do here. I think it's a good idea of
Jurgen's to allow selection of whether to use the master's params or our
own. But I'd add that it would also make sense to allow the child's
params to be added to the master's. Consider, again, a file of my
favorite math macros. Maybe there are modules that need to be used with
these, or some preamble code, and one would think one should be able to
indicate those in the macro file and have them always be used when that
file is used in some other document. I can imagine thinking that this
should be the default behavior when a default master is defined, though
I'm not sure about that.

Richard

Re: [PATCH] three bugfixes

[Jürgen Spitzmüller]

Am Donnerstag 17 Dezember 2015, 16:43:32 schrieb Guillaume Munch:
> 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?

Yes, I probably thought that this was the case (although it was not the 
intended fix; the intended fix was to load the global/master macro definitions)

> I miss what is the
> effect of just setting is_child. 

It adds the information to the output routine that the currently output buffer 
functions as a child. The output routine then suppresses some output that 
makes no sense for children. See the use of is_child in the source.

It also decides to use master params rather than params where appropriate.
To load the master preamble, one further addition would be necessary. See 
attached patch. But as JMarc says, this change will not please everybody.

> Do you have an opinion about changing
> this line of yours with my patch?

I would prefer using the is_child parameter instead.

> 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.

A proper solution would be the option to select between two modes: Inherit 
params from master or keep own params. In some documents, both modes make 
sense at different times.

Jürgen

> Guillaume
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index eac9821..aba52a9 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -1858,7 +1858,9 @@ void Buffer::writeLaTeXSource(otexstream & os,
 		listParentMacros(parentMacros, features);
 
 		// Write the preamble
-		runparams.use_babel = params().writeLaTeX(os, features,
+		BufferParams const & bparams = runparams.is_child
+			? masterParams() : params();
+		runparams.use_babel = bparams.writeLaTeX(os, features,
 			  d->filename.onlyPath());
 
 		// Japanese might be required only in some children of a document,

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: [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: [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: [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: [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

[PATCH] three bugfixes

[Guillaume Munch]

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.

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

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

Ok to push in?

This finally empties my to-do list for 2.2.0. But I'll surely still be
around part of the time to provide tests and feedback before the release.


Sincerely
Guillaume
>From 6bafba48e06ea242f5e8d5ec8fd1fe94d07b0cf5 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Wed, 16 Dec 2015 16:34:54 +
Subject: [PATCH] Limit the size of navigation menus for performance.

After d5a5fbb8, as indicated in the commit log, it remained to make sure that
the sub-menus of the navigation menu showing the TOCs are generated in a delayed
fashion, to avoid corner cases regarding performance when documents have very
lengthy tocs (e.g. in a document with 1000 sections it takes a few hundreds
milliseconds for the menu to be refreshed). But this idea actually requires
substantial changes to the way menus are computed, so it is not for now.

In the meanwhile, I reintroduce a max size for menus, after which it is cut
off. This differs from the one that I removed at d5a5fbb8 in two ways: 1) if
there are more items than the max size, then we still show something instead of
nothing, 2) we allow ourselves to rely on qt's scrollable menus and therefore
allow bigger menus than before the above commit. The philosophy is that it is
better to show something than nothing, that it's better to show a scrollable
menu than to cut the menu to fit the screen, and that beyond a certain size the
scrollable menu becomes useless anyways.
---
 src/frontends/qt4/Menus.cpp | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/frontends/qt4/Menus.cpp b/src/frontends/qt4/Menus.cpp
index b75221b..7757b0d 100644
--- a/src/frontends/qt4/Menus.cpp
+++ b/src/frontends/qt4/Menus.cpp
@@ -354,7 +354,7 @@ public:
 	void expandFloatListInsert(Buffer const * buf);
 	void expandFloatInsert(Buffer const * buf);
 	void expandFlexInsert(Buffer const * buf, InsetLayout::InsetLyXType type);
-	void expandToc2(Toc const & toc_list, size_t from, size_t to, int depth);
+	void expandToc2(Toc const & toc_list, size_t from, size_t to, int depth, string toc_type);
 	void expandToc(Buffer const * buf);
 	void expandPasteRecent(Buffer const * buf);
 	void expandToolbars();
@@ -1217,10 +1217,18 @@ void MenuDefinition::expandFlexInsert(
 }
 
 
+// Threshold before we stop displaying sub-items alongside items
+// (for display purposes). Ideally this should fit on a screen.
 size_t const max_number_of_items = 30;
+// Size limit for the menu. This is for performance purposes,
+// because qt already displays a scrollable menu when necessary.
+// Ideally this should be the menu size from which scrollable
+// menus become unpractical.
+size_t const menu_size_limit = 80;
 
 void MenuDefinition::expandToc2(Toc const & toc_list,
-		size_t from, size_t to, int depth)
+size_t from, size_t to, int depth,
+string toc_type)
 {
 	int shortcut_count = 0;
 
@@ -1250,6 +1258,7 @@ void MenuDefinition::expandToc2(Toc const & toc_list,
 		}
 	} else {
 		size_t pos = from;
+		size_t size = 1;
 		while (pos < to) {
 			size_t new_pos = pos + 1;
 			while (new_pos < to && toc_list[new_pos].depth() > depth)
@@ -1264,16 +1273,22 @@ void MenuDefinition::expandToc2(Toc const & toc_list,
 		label += QString::number(++shortcut_count);
 }
 			}
+			if (size >= menu_size_limit) {
+FuncRequest f(LFUN_DIALOG_SHOW, "toc " + toc_type);
+add(MenuItem(MenuItem::Command, "...", f));
+break;
+			}
 			if (new_pos == pos + 1) {
 add(MenuItem(MenuItem::Command,
 		label, FuncRequest(toc_list[pos].action(;
 			} else {
 MenuDefinition sub;
-sub.expandToc2(toc_list, pos, new_pos, depth + 1);
+sub.expandToc2(toc_list, pos, new_pos, depth + 1, toc_type);
 MenuItem item(MenuItem::Submenu, label);
 item.setSubmenu(sub);
 add(item);
 			}
+			++size;
 			pos = new_pos;
 		}
 	}
@@ -1314,7 +1329,7 @@ void MenuDefinition::expandToc(Buffer const * buf)
 		submenu.add(MenuItem(MenuItem::Command, qt_("Open Outliner..."), f));
 		submenu.add(MenuItem(MenuItem::Separator));
 		// add entries
-		submenu.expandToc2(* cit->second, 0, cit->second->size(), 0);
+		submenu.expandToc2(*cit->second, 0, cit->second->size(), 0, cit->first);
 		MenuItem item(MenuItem::Submenu, guiName(cit->first, buf->params()));
 		

Re: [PATCH] three bugfixes

[Richard Heck]

These look good, but I'd like an opportunity to study them before them
are committed. I'll try to get to that tomorrow. Time is tight right
now, due to end of semester. And we are trying to sell one house and buy
another during the holiday season, which is not easy.

Richard


On 12/16/2015 09:40 PM, Guillaume Munch wrote:
> 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.
>
> 2) Work around bug #9841. See . I
> could test that git does not complain of a merge conflict anymore in the
> described situation.
>
> 3) Use the parent's preamble to preview the child. See
> . I could test that the previews in
> my child document display correctly now.
>
> Ok to push in?
>
> This finally empties my to-do list for 2.2.0. But I'll surely still be
> around part of the time to provide tests and feedback before the release.
>
>
> Sincerely
> Guillaume