Martin Vermeer wrote:
On Wed, 30 Aug 2006 14:31:05 +0200 Helge Hafting <[EMAIL PROTECTED]>
wrote:
From reading the related bug reports 2093 and 2671, I know there is
some problems with branches & lists. This is about branch stuff that
can
be done, but in an unnecessarily cumbersome and surprising way.
I write multilingual documents, where each list item is in two
languages. The document should be printable in either language
separately, or with both visible at the same time. In all cases the
numbering should be the same, so people can reference numbers when
discussing. This works, as "standard" paragraphs can be embedded in an
enumeration paragraph.
Creating such a document is currently fraught with oddities though.
Lets
say I start with:
1 One
2 Two
3 Three
Now I find I need this in two languages. So I start by adding an
"english" branch, mark everything inside "one", and uses
insert->branch->english.
Expected result:
1 Branch english: One
2 Two
3 Three
Instead, I get:
1: Branch english: (a) One
2 Two
3 Three
As you see, I got an enumeration embedded inside an enumeration. What a
surprise! The same happens in PDF/DVI output. This is easily fixed by
going into the branch and setting the paragraph type there to
"standard". Such a manual fix should be unnecessary though.
For more silliness, try:
1. One
Std. par. embedded in "one"
2. Two
3. Three
Now mark the two paragraphs 'one' and 'Std. par. embedded in "one"',
then insert->branch->english
The result looks strange. There is the above mentioned problem, as
well
as a strange empty embedded paragraph after the inserted branch. It can
all be fixed up to what I intended, but such fixing should not be
necessary. Insert->branch is supposed to work - it should not create
oddities on screen. And inserting an active branch around marked text
should always be a no-op as far as output is concerned.
Lyx already supports my desired layout, it is just the insert->branch
operation that stumbles.
Helge Hafting
This problem is much more genersl than branches. It was reported earlier on the
list: selecting text in a itemise/enum pararaph, and inserting a textinset
around it, will produce a item/enum paragraph inside the inset.
I agree it needs fixing, but how? This is sensible behaviour when putting an
nset around several item/enum paras. But not in this case.
How to make the distinction and produce sensible behaviour in both (all) cases?
The problem is the creation of "enumerate inside enumerate",
and similar for other things nesting effects, such as bullets
and all of the numbered stuff (sectioning, captions, . . . )
This is what must be avoided, and there are two simple ways:
When something (branch, box, etc) is inserted so that a list
paragraph is "split" (i.e. we get a list environment both
on the outside and the inside) then one of those
list environments must be reset to standard. This will avoid the
surprise nesting in all cases.
Then to consider what environment (outer or inner) to reset.
Turning the inside of the box to "standard" always:
Perfect for my particular case, but will wreck lists in
your case of marking several items.
Turning the outside of the box to "standard" always:
Will work for multiple items, will avoid nesting for
my case, but I will have to do some paragraph changing
so I won't get extra items when printing both languages of
at the same time. This is acceptable to me.
There is another troublesome case, if the "branch" doesn't
go around all of the list item, just a single word. In this case,
resetting the outer environment is wrong.
So I propose this:
* Inserting a branch/box around part of a list item/section/caption,
reset the interior to "standard". Being a list item / section / caption
is then taken care of by the outer environment. In this case, the
user is clearly boxing or making conditional a word/phrase inside
the environment.
* Inserting a branch/box around a whole list item/section/caption,
reset the now empty outer environment to "standard", as the
user clearly is sticking the list/section/caption itself in a box/branch.
This will also work well for the case when multiple items gets boxed.
The "weird selection" problem:
We will still be in trouble if the user starts selection in the middle
of a list item (or section header), continue selection over several
paragraphs, and then inserts a box/branch. But the action
is somewhat meaningless, and the lyx does not support
that kind of branch at this time anyway.
For branches, this can be worked around by first selecting the
half paragraph and apply the branch, then selecting the
other paragraphs and putting a branch inset around them.
This could be automated for maximum userfriendliness,
applying "bold" and such already works fine over weird selections.
The action is truly meaningless for boxes - it is
almost geometrically impossible to draw a box around part of
a list item as well as the following list item. It can be done when
the first item spans several lines, or have an embedded std. paragraph
at the end - it is still a very weird layout.
For maximum userfriendlyness, let lyx add several branches
when "branch" is applied over a weird selection. Just like
"bold" works over such a selection. LyX should ideally
refuse to insert a box under such circumstances, rather
than making a weird box. But then, "garbage in - garbage
out" might be ok too. Someone trying to box such a selection
aren't thinking straight. Few would feel limited by this.
Helge Hafting
