Insets Can Appear in Places Where They Are Invalid

[Richard Heck]

Some insets should not be able to appear in section headings. An example is the
URL flex inset, but LyX will also allow you to put a table or float in a section
heading (!). Prohibiting the user from inserting such objects shouldn't be too
hard, but there is another issue: Changing the layout could cause the object to
appear without its having been inserted in the usual way. So we'd need to do
that kind of check really to fix this.

[Uwe Stöhr]

\url must not be used in footnotes, section headings, and indexes. The fix would
be simply to disallow that users can create it in these environments.

I won't find the time to fix this, but perhaps another one could do this - it
shouldn't be too difficult.

another issue: Changing the layout could cause the object to
appear without its having been inserted in the usual way.

We should handle this case as we already do for document class changes. For
example when you are using labeling in a koma-script class and change the class
to another one LyX resets the environment to Standard and displays a message.
For our cases here, we should do the same but shift the things below the changed
environment, that means that the table or URL appears below but unchanged.

[Juergen Spitzmueller]

Subject: Re: Insets Can Appear in Places Where They Are Invalid

\url must not be used in footnotes, section headings, and indexes. The fix
would be simply to disallow that users can create it in these environments.

Please not. \url works very well in those contexts for me, except for very
rare cases.

[Vincent van Ravesteijn]

* #3826 has been marked as a duplicate of this bug. *

[Vincent van Ravesteijn]

More examples:

• don't allow to insert environments in section headings (bug #3826).

• do not allow to insert e.g. Index List as a label in a description environment. In this case, we should start a new "Standard" paragraph IMHO, whenever the user wants to insert an Index List (bug #5937).

[Danilo Piazzalunga]

LyX document with URL in section heading

[Danilo Piazzalunga]

The URL inset causes trouble only when pdf_bookmarks is on (hyperref package with bookmarks=true). Attached a test document created with LyX 1.6.1.

[Richard Heck]

LyX 2.0.8 is released, so all 2.0.x bugs are being retargeted to 2.1.x. If this is your bug, please check whether the 2.1.x milestone makes sense and, if not, remove it.

[Uwe Stöhr]

related bugs: #7116, #9313

[Scott Kostyshak]

Floats in paragraphs (#7779).

[Scott Kostyshak]

Comments/greyed outs in sections (#4180).

[Scott Kostyshak]

#4180 marked as duplicate (but we should make sure the specific case there is fixed).

[Scott Kostyshak]

#2528 (child docs in author) ?

[Scott Kostyshak]

Several insets in mathed (#704).

[Richard Heck]

Moving all 2.1.x bugs to 2.2.x. Feel free to triage....

[Richard Heck]

Newlines in figures (#8281).

[Scott Kostyshak]

Replying to skostysh:

Comments/greyed outs in sections (#4180).

These are now allowed ([4e9e9881/lyxgit]), thanks to our cprotect feature.

[Scott Kostyshak]

A centralized mechanism for handling inset conflicts might also simplify some code. For example, grep for inDescriptionItem in src/Text3.cpp.

[Richard Kimberly Heck]

#7779: LyX allows floats in headers (e.g., Paragraph).

[Juergen Spitzmueller]

Even floats in headers (#7779) are now allowed as of [768c9a552e895b44/lyxgit].

I think we should now revisit this ticket and see what's left. I suggest to open separate tickets for those (or reopen the closed counterparts) and close this one as fixedinmaster.

[Scott Kostyshak]

Do you think we should also provide a mechanism for disabling combinations that are not supported? e.g. what about a layout tag specifying which layouts a specific layout should not be contained in; and similarly a separate layout tag specifying which layouts a specific layout should not contain. I'm sure things can get complicated (e.g. perhaps inset1 generally should not be put in inset2, but if inset1 is contained in inset3 and inset3 is included in inset1, it's OK), but since this issue comes up so often perhaps it's a start?

[Juergen Spitzmueller]

But what is left? AFAICS these:

• #2528 (child docs in author)
• Several insets in mathed (#704).
• Newlines in figures (#8281).

I don't see how these can be fixed with one and the same approach. #2528 might be about pasting the inset to the author par, but #704 is about menu lfun disabling and #8281 about paragraphs not being merged on paste. I don't see how it helps us to collect all these rather different bugs in one ticket.

[Scott Kostyshak]

Replying to spitz:

But what is left?

I would imagine a lot. For example, should it be allowed to put a bibliography inside a figure caption? A float inside itemize options? A table inside an "Institute Mark" ? A table inside a Frame Title? By providing a tag for layouts to be able to say stuff like "this inset cannot be placed inside any type of float" or "this inset cannot contain any float", or "this inset cannot contain any environment", this could be one way. Otherwise, we need separate code to catch inserting vs. pasting, and custom layouts would not be able to provide safeguards.

I don't see how these can be fixed with one and the same approach.

Perhaps one approach cannot cover everything, but it might catch a lot.

[Juergen Spitzmueller]

But still this ticket is way too general.

We have separate bugs:

• Copying insets or layouts to context where they are not allowed
• Switching insets types to types that are not allowed in the context
• Enabling inset insertion via lfun in contexts where they are not allowed

I'd rather file separate tickets for these separate task. This general ticket has lead to the marking of other tickets as duplicates which are completely separate issues.

[Scott Kostyshak]

Makes sense. We might want to break this general ticket into separate general tickets related to the categories that you mentioned. I just would prefer not to have separate tickets of a problem that could be solved in a general way. We just need to find the middle path that is adequate. As for what is the largest general category that would share a common solution, I don't know. The categories you mentioned are fine with me.

[lasgouttes]

This has been added to the Context META bug #6156.

[Richard Kimberly Heck]

#2528 is a version of this.

[Richard Kimberly Heck]

Another version is #6147.

The other tickets are not dupes, but cases of this one. It does seem to me like a quite general fix is needed here, too. This will not be an inset-by-inset task. Though I do agree with Jürgen that a proper fix involves the three elements he mentions.

All of these seem to be a format change, since we surely don't want to hardcode the list of what's allowed where. And there's no way this happens for 2.4.0.

[racoon]

#12699 is a version of this.

[Juergen Spitzmueller]

Another subcase: #13040