On 6/9/19 17:56, Richard Kimberly Heck wrote:
On 9/6/19 11:48 AM, Daniel wrote:
On 5/9/19 13:46, Jean-Marc Lasgouttes wrote:
Le 05/09/2019 à 06:54, Daniel a écrit :
Can't test currently and I am not sure I understand correctly what
the patch does. But as far as I do, I don't think I like it. If I
understood you correctly, I can replicate the behavior of the patch
in stable LyX by inserting the inset and setting the surrounding
paragraph to Standard. But this is not intended in some cases. For
example, in order to keep description labels together, I use a label
inset that does nothing but surround the containing content with
brackets {}. So, set a paragraph to Description, enter the label
text, mark it and insert the label inset. But with your patch this
will reset the description to plain, right?
This is exact, but note that the behavior will not happen if you
insert your magic inset first and type into it afterwards. Moreover,
the patch will be tweaked to not touch layouts if the collapsible
inset forces plain layout, which I guess your label inset does (it
should anyway).
So my position is
1/ I am OK with a patch which changes the default font of note insets
2/ BUT we should be aware that this will hide a real bug (and not a
mere annoyance) that is that the layout surrounding the inset in your
example at the top of this thread should not be there. We should be
grateful for the inset to tell us that, not propose to shot the
messenger ;)
So I would like to go forward with some changes of how layouts are
set/transferred when inserting insets, regardless of the cosmetic
changes in display.
I am not convinced yet that changing the surrounding layout is the
right thing to do.
First, it seems good to get the same effect independent of the order
of inserting inset and setting layout.
Second, aren't there cases where one wants to have an inset embedded
in a non-standard layout? If so, the user might have to reset the
layout even if it was set as desired before inserting the inset.
I think there's some confusion about the issues here.
The 'surrounding layout' problem is actually more general. Suppose you
have a section, with header and associated text. Select the whole thing
and make it a branch. It will not do what you want. We really do need to
change the 'outside' layout in this case. (I think there might be a bug
about this, and I have done some work on the problem.)
I never used branches. So maybe that is why I never came across the
problem and cannot evaluate the benefits over the costs correctly.
The other issue is the font displayed within notes. JMarc is worried
about the case where the note is the only thing in the section heading
(say). I think you and I are more worried about the case where there are
other things in the section heading, but the font of the note ends up
looking too big. I see JMarc's point: There's no visual indication in
the text that we're in a section. But I also see our point: I want to
put notes in section headings sometimes, and it's annoying that they are
so huge.
I see. One intermediate solution would be to inherit the font only for
the first paragraph. Then my example case would still come out right in
that it will preview what the text looks like if the inset is dissolved.
And one could add smaller notes, at least at the end of a section
heading, by leaving the first line empty. Maybe not perfect but IMO a
clear improvement over the current situation.
Daniel
