Re: Insets and Apply

[Richard Kimberly Heck]

On 1/9/21 9:58 PM, Thibaut Cuvelier wrote:
> On Sun, 10 Jan 2021 at 03:46, Richard Kimberly Heck  > wrote:
>
> I've recently fixed two bugs, #3964 and #10030, both of which  have to
> do with the behavior of "Apply" in our dialogs. If you insert a
> citation
> (say) and then hit Apply, then if you hit OK you get another one. The
> problem is (was) that the dialog is not connected to the newly created
> inset. So I've made it so that now the dialog IS connected to the
> new inset.
>
> But there is a side-effect. Suppose you insert a citation and hit
> apply,
> and now you move the cursor somewhere else. The dialog is STILL
> connected to the inset. So if you wanted to insert a new citation in a
> new place, you would have to close the dialog and then re-open it. The
> reference dialog is explicitly designed not to exhibit this
> behavior, so
> (a comment says) you can easily insert multiple references.
>
> I'm a bit unsure what we want to do here. Should we disconnect the
> dialogs on cursor movement perhaps? Then they can remain open and
> won't
> act strangely.
>
>
> I already thought this behaviour was kind of strange. The other option
> could be to close the window on cursor moves. I think it would be
> easier to understand from a user point of view, as the disconnection
> would have a UI feedback, even though it might really annoy quite a
> few users.

It would help that the dialog would reset when disconnected. I.e., the
citation dialog would no longer show any citations as having been
selected, etc.

Riki



-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Insets and Apply

[Thibaut Cuvelier]

On Sun, 10 Jan 2021 at 03:46, Richard Kimberly Heck 
wrote:

> I've recently fixed two bugs, #3964 and #10030, both of which  have to
> do with the behavior of "Apply" in our dialogs. If you insert a citation
> (say) and then hit Apply, then if you hit OK you get another one. The
> problem is (was) that the dialog is not connected to the newly created
> inset. So I've made it so that now the dialog IS connected to the new
> inset.
>
> But there is a side-effect. Suppose you insert a citation and hit apply,
> and now you move the cursor somewhere else. The dialog is STILL
> connected to the inset. So if you wanted to insert a new citation in a
> new place, you would have to close the dialog and then re-open it. The
> reference dialog is explicitly designed not to exhibit this behavior, so
> (a comment says) you can easily insert multiple references.
>
> I'm a bit unsure what we want to do here. Should we disconnect the
> dialogs on cursor movement perhaps? Then they can remain open and won't
> act strangely.


I already thought this behaviour was kind of strange. The other option
could be to close the window on cursor moves. I think it would be easier to
understand from a user point of view, as the disconnection would have a UI
feedback, even though it might really annoy quite a few users.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Insets and Apply

[Richard Kimberly Heck]

I've recently fixed two bugs, #3964 and #10030, both of which  have to
do with the behavior of "Apply" in our dialogs. If you insert a citation
(say) and then hit Apply, then if you hit OK you get another one. The
problem is (was) that the dialog is not connected to the newly created
inset. So I've made it so that now the dialog IS connected to the new inset.

But there is a side-effect. Suppose you insert a citation and hit apply,
and now you move the cursor somewhere else. The dialog is STILL
connected to the inset. So if you wanted to insert a new citation in a
new place, you would have to close the dialog and then re-open it. The
reference dialog is explicitly designed not to exhibit this behavior, so
(a comment says) you can easily insert multiple references.

I'm a bit unsure what we want to do here. Should we disconnect the
dialogs on cursor movement perhaps? Then they can remain open and won't
act strangely.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Simplify checking whether files are controlled by SVN and GIT.

[Scott Kostyshak]

On Sat, Jan 09, 2021 at 10:38:22PM +0100, Jean-Marc Lasgouttes wrote:
> Le 09/01/2021 à 18:14, Scott Kostyshak a écrit :
> > No bonus points given because it's a good point. It would be more clean and 
> > might actually make a noticeable difference in terms of speed. I haven't 
> > particularly noticed slowness because of the VC code (although the previous 
> > code that redirected output to a file might have caused slowness because of 
> > IO?) but I wouldn't be a surprised. It might also open up more extensions 
> > to the VC code in the future. That said, I don't have the time to look into 
> > it now.
> 
> I would be more interested in having a nice interaction with a running
> python instance to speed up all our python scripting needs. Would that be
> doable?

That does sounds like a good idea, so as to avoid overhead of separate
processes. I have no idea if it's doable, but I like your strategy:
whenever José proposes something time-consuming, I will reframe it into
having to do with Python and shoot it back to him :)

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Simplify checking whether files are controlled by SVN and GIT.

[Jean-Marc Lasgouttes]

Le 09/01/2021 à 18:14, Scott Kostyshak a écrit :

No bonus points given because it's a good point. It would be more clean and 
might actually make a noticeable difference in terms of speed. I haven't 
particularly noticed slowness because of the VC code (although the previous 
code that redirected output to a file might have caused slowness because of 
IO?) but I wouldn't be a surprised. It might also open up more extensions to 
the VC code in the future. That said, I don't have the time to look into it now.


I would be more interested in having a nice interaction with a running 
python instance to speed up all our python scripting needs. Would that 
be doable?


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Add move constructor and move assignment operator for FileName class

[Jean-Marc Lasgouttes]

Le 09/01/2021 à 22:13, Yuriy Skalko a écrit :

Yes, only these 3.

Seems like this is caused by `getIcon` calls in 
DynamicMenuButton::updateTriggered (called on every toolbar update, that 
happens on every key press). And `getIcon` doesn't just return icon from 
some cache, but directly checks the file on disk. I'm not sure how to 
fix it the right way.


I see, I'll take a look. It is probably not necessary to call getIcon at 
all.


Now almost full update of GUI state update (dialogs, toolbars, 
statusbar) is done in GuiView::restartCaret that is called in several 
places in GuiApplication::processKeySym. It will be great to implement 
more fine-grained control of the GUI update.


Frankly, I am not at ease at all with the way things get updated. I do 
not understand the Qt mechanisms well enough. If you feel like trying to 
understand it, please do. Be warn though that we are in a working but 
fragile situation now, changes will lead to a rough ride but it is 
probably worth the cost.


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Add move constructor and move assignment operator for FileName class

[Yuriy Skalko]

Also I noticed that these files are accessed on every keypress (even
on navigating document with arrows):

lib/images/undo.svgz
lib/images/textstyle-apply.svgz
lib/images/paste.svgz

Is it *really* necessary?



It would be because of getStatus, I suspect, though I'm not sure why the
files would be accessed. Maybe because the toolbar items are being
enabled/disabled? But surely that only need happen if there's been a change.

Riki




Only these files?

JMarc


Yes, only these 3.

Seems like this is caused by `getIcon` calls in 
DynamicMenuButton::updateTriggered (called on every toolbar update, that 
happens on every key press). And `getIcon` doesn't just return icon from 
some cache, but directly checks the file on disk. I'm not sure how to 
fix it the right way.


Now almost full update of GUI state update (dialogs, toolbars, 
statusbar) is done in GuiView::restartCaret that is called in several 
places in GuiApplication::processKeySym. It will be great to implement 
more fine-grained control of the GUI update.



Yuriy

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Add move constructor and move assignment operator for FileName class

[Jean-Marc Lasgouttes]

Le 09/01/2021 à 10:41, Yuriy Skalko a écrit :
Also I noticed that these files are accessed on every keypress (even on 
navigating document with arrows):


lib/images/undo.svgz
lib/images/textstyle-apply.svgz
lib/images/paste.svgz

Is it *really* necessary?


Only these files?

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

LyX 2.3.6.2 Update for OSX Only

[Richard Kimberly Heck]

A change in LyX 2.3.6.1 broke the use of SyncTeX with OSX (bug #12063).
This was due to inconsistencies in our underlying Qt libraries. Thus, a
new version fixing that problem has been released. Please see our
download page

https://www.lyx.org/Download

for links to the new binaries.


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Tab binding: outline-in before depth-increment

[Scott Kostyshak]

On Sat, Jan 09, 2021 at 06:20:37PM +0100, Kornel Benko wrote:
> Am Sat, 9 Jan 2021 12:07:06 -0500
> schrieb Scott Kostyshak :
> 
> > On Sat, Jan 09, 2021 at 09:06:56AM +0100, Jürgen Spitzmüller wrote:
> > > Am Freitag, dem 08.01.2021 um 20:32 -0500 schrieb Scott Kostyshak:  
> > > > It would be nice to get someone else's feedback (Jürgen?) before you
> > > > work on it. I see a few possibilities:
> > > > 
> > > > 1. A tag that does not allow layouts to nest other layouts of the
> > > > same
> > > >    type.
> > > > 
> > > > 2. A tag that does not allow a layout to be nested at all.
> > > > 
> > > > 3. A tag that is similar to the "AutoNests" tag, where we can list
> > > > all
> > > >    of the layouts that a layout should not nest (or should not be
> > > > nested by?).
> > > > 
> > > > (3) is the most general so my initial guess is that's the way to go.
> > > > I
> > > > like your name for the tag that you proposed earlier,
> > > > ProhibitNesting.  
> > > 
> > > NeverNestedBy with "none" indicating a layout cannot be nested at all?
> > > The analog function is AutoNestedBy (not AutoNests), and I suppose most
> > > of the code can just be copied.  
> > 
> > That name is fine with me. I think I slightly prefer the sound of
> > "ProhibitNestingBy". I guess "NeverNestedBy" is more a property of the
> > underlying LaTeX mechanism (e.g., "a section is never nested in another
> > section") and "ProhibitNestingBy" is more a property of LyX's layout
> > feature (e.g., "LyX will prohibit the user from nesting a section in
> > another section"). I'm not familiar with the layout code, so whatever
> > you and Riki think is more consistent is fine with me.
> > 
> > Also, it takes me a little while to parse "never nested by none", but
> > would it make more sense for "never nested by *all*" to mean a layout
> > that cannot be nested at all?
> > 
> > Scott
> 
> Or by *any* ?

Good idea, that does sound better than "all".

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Tab binding: outline-in before depth-increment

[Kornel Benko]

Am Sat, 9 Jan 2021 12:07:06 -0500
schrieb Scott Kostyshak :

> On Sat, Jan 09, 2021 at 09:06:56AM +0100, Jürgen Spitzmüller wrote:
> > Am Freitag, dem 08.01.2021 um 20:32 -0500 schrieb Scott Kostyshak:  
> > > It would be nice to get someone else's feedback (Jürgen?) before you
> > > work on it. I see a few possibilities:
> > > 
> > > 1. A tag that does not allow layouts to nest other layouts of the
> > > same
> > >    type.
> > > 
> > > 2. A tag that does not allow a layout to be nested at all.
> > > 
> > > 3. A tag that is similar to the "AutoNests" tag, where we can list
> > > all
> > >    of the layouts that a layout should not nest (or should not be
> > > nested by?).
> > > 
> > > (3) is the most general so my initial guess is that's the way to go.
> > > I
> > > like your name for the tag that you proposed earlier,
> > > ProhibitNesting.  
> > 
> > NeverNestedBy with "none" indicating a layout cannot be nested at all?
> > The analog function is AutoNestedBy (not AutoNests), and I suppose most
> > of the code can just be copied.  
> 
> That name is fine with me. I think I slightly prefer the sound of
> "ProhibitNestingBy". I guess "NeverNestedBy" is more a property of the
> underlying LaTeX mechanism (e.g., "a section is never nested in another
> section") and "ProhibitNestingBy" is more a property of LyX's layout
> feature (e.g., "LyX will prohibit the user from nesting a section in
> another section"). I'm not familiar with the layout code, so whatever
> you and Riki think is more consistent is fine with me.
> 
> Also, it takes me a little while to parse "never nested by none", but
> would it make more sense for "never nested by *all*" to mean a layout
> that cannot be nested at all?
> 
> Scott

Or by *any* ?

Kornel


pgpF0zy29szeZ.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Simplify checking whether files are controlled by SVN and GIT.

[Scott Kostyshak]

On Sat, Jan 09, 2021 at 09:12:19AM +, José Abílio Matos wrote:
> On Saturday, January 9, 2021 5:12:45 AM WET Scott Kostyshak wrote:
> > Sounds good. If anyone knows a good approach, please feel free to merge it
> > into the patch and commit. Or describe the approach and I'll implement it.
> > 
> > Scott
> 
> Not necessarily what you want to hear, and clearly overkill in this context, 
> but using libgit2 or one of its c++ wrappers is one idea. :-)
> 
> I think that I earn bonus points for the useless tip of the day. :-D

No bonus points given because it's a good point. It would be more clean and 
might actually make a noticeable difference in terms of speed. I haven't 
particularly noticed slowness because of the VC code (although the previous 
code that redirected output to a file might have caused slowness because of 
IO?) but I wouldn't be a surprised. It might also open up more extensions to 
the VC code in the future. That said, I don't have the time to look into it now.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Tab binding: outline-in before depth-increment

[Scott Kostyshak]

On Sat, Jan 09, 2021 at 09:06:56AM +0100, Jürgen Spitzmüller wrote:
> Am Freitag, dem 08.01.2021 um 20:32 -0500 schrieb Scott Kostyshak:
> > It would be nice to get someone else's feedback (Jürgen?) before you
> > work on it. I see a few possibilities:
> > 
> > 1. A tag that does not allow layouts to nest other layouts of the
> > same
> >    type.
> > 
> > 2. A tag that does not allow a layout to be nested at all.
> > 
> > 3. A tag that is similar to the "AutoNests" tag, where we can list
> > all
> >    of the layouts that a layout should not nest (or should not be
> > nested by?).
> > 
> > (3) is the most general so my initial guess is that's the way to go.
> > I
> > like your name for the tag that you proposed earlier,
> > ProhibitNesting.
> 
> NeverNestedBy with "none" indicating a layout cannot be nested at all?
> The analog function is AutoNestedBy (not AutoNests), and I suppose most
> of the code can just be copied.

That name is fine with me. I think I slightly prefer the sound of
"ProhibitNestingBy". I guess "NeverNestedBy" is more a property of the
underlying LaTeX mechanism (e.g., "a section is never nested in another
section") and "ProhibitNestingBy" is more a property of LyX's layout
feature (e.g., "LyX will prohibit the user from nesting a section in
another section"). I'm not familiar with the layout code, so whatever
you and Riki think is more consistent is fine with me.

Also, it takes me a little while to parse "never nested by none", but
would it make more sense for "never nested by *all*" to mean a layout
that cannot be nested at all?

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Add move constructor and move assignment operator for FileName class

[Richard Kimberly Heck]

On 1/9/21 4:41 AM, Yuriy Skalko wrote:
>> I don't know enough about this stuff to say much. I think this would be
>> worth doing for 2.4.0, as it will probably provide for some speed as
>> well.
>>
>> Riki
>
> Committed at 854c9de.
>
> Also I noticed that these files are accessed on every keypress (even
> on navigating document with arrows):
>
> lib/images/undo.svgz
> lib/images/textstyle-apply.svgz
> lib/images/paste.svgz
>
> Is it *really* necessary?

It would be because of getStatus, I suspect, though I'm not sure why the
files would be accessed. Maybe because the toolbar items are being
enabled/disabled? But surely that only need happen if there's been a change.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Howto modify selection from replace buffer (FindAdv)

[Kornel Benko]

Am Sat, 09 Jan 2021 12:58:16 +0100
schrieb Jürgen Spitzmüller :

> Am Freitag, dem 08.01.2021 um 11:39 +0100 schrieb Kornel Benko:
> > I have problems to _use_ matched substrings in replace-mode.
> > 
> > For instance given regular expression containing some groups, like
> > '()()()'
> > and I want to change the found value to '', so in regex I
> > would write
> > '\3\2\1'
> > 
> > Now the selection contains '\3\2\1', this is selected (in
> > lyxfind.cpp:findAdvReplace())
> > with
> > cap::pasteParagraphList(cur,
> > repl_buffer.paragraphs(),
> >    
> > repl_buffer.params().documentClassPtr(),
> >     bv-  
> > > buffer().errorList("Paste"));  
> >     LYXERR(Debug::FIND, "After pasteParagraphList() cur="
> > << cur << endl);
> >     sel_len = repl_buffer.paragraphs().begin()->size();
> > and then follows
> > bv->putSelectionAt(DocIterator(cur), sel_len, !opt.forward);
> >     bv->processUpdateFlags(Update::Force);
> > 
> > How can I modify the data prior to inserting into buffer ?
> > The values of '\1', '\2', '\3' are known here, but are not used.  
> 
> I think you should write a function similar to changeFirstCase() that
> iterates over repl_buffer and replaces the placeholder in all
> paragraphs. Then the cap::pasteParagraphList() function in question
> should insert the modified paragraph(s).
> 
> I don't know how difficult such a function would be, though.
> 
> Jürgen
> 

Yes, I overseen the LASSERT(repl_buffer.readString(lyx), return 0) statement,
so I was confused.

I can handle it now, but there is one difficulty, I cannot resolve.
The search-buffer and the replace-buffer contain not only strings, but also
the font, colour, size, specs.
ATM, the spec is used from the replace-buffer (only the char-cases are handled
differently)
We need a flag to know what should be done.

Committed at 60980b0e.

The replacement strings are '$$0', '$$1', ... , '$$6'
Number 7, 8, 9 are reserved, because the algorithm eats 3 of them.

Kornel

Kornel


pgpKHIH0z1ZK4.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Virtual meetings

[Jean-Marc Lasgouttes]

Le 9 janvier 2021 10:38:32 GMT+01:00, Abdelrazak Younes  a 
écrit :
>Hey guys,
>
>Long time no see! I will try to join if I am invited, just for the sake of
>seeing your faces :-)

Hi Abdel, 

Of course you are welcome ! 

JMarc

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Howto modify selection from replace buffer (FindAdv)

[Jürgen Spitzmüller]

Am Freitag, dem 08.01.2021 um 11:39 +0100 schrieb Kornel Benko:
> I have problems to _use_ matched substrings in replace-mode.
> 
> For instance given regular expression containing some groups, like
>   '()()()'
> and I want to change the found value to '', so in regex I
> would write
>   '\3\2\1'
> 
> Now the selection contains '\3\2\1', this is selected (in
> lyxfind.cpp:findAdvReplace())
> with
>   cap::pasteParagraphList(cur,
> repl_buffer.paragraphs(),
>    
> repl_buffer.params().documentClassPtr(),
>     bv-
> > buffer().errorList("Paste"));
>     LYXERR(Debug::FIND, "After pasteParagraphList() cur="
> << cur << endl);
>     sel_len = repl_buffer.paragraphs().begin()->size();
> and then follows
>   bv->putSelectionAt(DocIterator(cur), sel_len, !opt.forward);
>     bv->processUpdateFlags(Update::Force);
> 
> How can I modify the data prior to inserting into buffer ?
> The values of '\1', '\2', '\3' are known here, but are not used.

I think you should write a function similar to changeFirstCase() that
iterates over repl_buffer and replaces the placeholder in all
paragraphs. Then the cap::pasteParagraphList() function in question
should insert the modified paragraph(s).

I don't know how difficult such a function would be, though.

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Virtual meetings

[Jürgen Spitzmüller]

Am Sonntag, dem 03.01.2021 um 21:38 +0100 schrieb Pavel Sanda:
> I would suggest we meet Mon 11 Jan, 5pm CET (4pm UTC, 11am EST)
> unless there is a better proposal.

I have another appointment at 6pm, but I'll join until then.

Jürgen



signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Virtual meetings

[Abdelrazak Younes]

On Sun, Jan 3, 2021 at 9:39 PM Pavel Sanda  wrote:

> I would suggest we meet Mon 11 Jan, 5pm CET (4pm UTC, 11am EST) unless
> there is a better proposal.
>
> I could send zoom invitiation if you all are ok with that. Otherwise
> suggest
> your tool and manage the managment side of the meeting.
>

Hey guys,

Long time no see! I will try to join if I am invited, just for the sake of
seeing your faces :-)

Abdel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Add move constructor and move assignment operator for FileName class

[Yuriy Skalko]

I don't know enough about this stuff to say much. I think this would be
worth doing for 2.4.0, as it will probably provide for some speed as well.

Riki


Committed at 854c9de.

Also I noticed that these files are accessed on every keypress (even on 
navigating document with arrows):


lib/images/undo.svgz
lib/images/textstyle-apply.svgz
lib/images/paste.svgz


Is it *really* necessary?


Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Simplify checking whether files are controlled by SVN and GIT.

[José Abílio Matos]

On Saturday, January 9, 2021 5:12:45 AM WET Scott Kostyshak wrote:
> Sounds good. If anyone knows a good approach, please feel free to merge it
> into the patch and commit. Or describe the approach and I'll implement it.
> 
> Scott

Not necessarily what you want to hear, and clearly overkill in this context, 
but using libgit2 or one of its c++ wrappers is one idea. :-)

I think that I earn bonus points for the useless tip of the day. :-D

-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Tab binding: outline-in before depth-increment

[Jürgen Spitzmüller]

Am Freitag, dem 08.01.2021 um 20:32 -0500 schrieb Scott Kostyshak:
> It would be nice to get someone else's feedback (Jürgen?) before you
> work on it. I see a few possibilities:
> 
> 1. A tag that does not allow layouts to nest other layouts of the
> same
>    type.
> 
> 2. A tag that does not allow a layout to be nested at all.
> 
> 3. A tag that is similar to the "AutoNests" tag, where we can list
> all
>    of the layouts that a layout should not nest (or should not be
> nested by?).
> 
> (3) is the most general so my initial guess is that's the way to go.
> I
> like your name for the tag that you proposed earlier,
> ProhibitNesting.

NeverNestedBy with "none" indicating a layout cannot be nested at all?
The analog function is AutoNestedBy (not AutoNests), and I suppose most
of the code can just be copied.

Jürgen


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel