[Libreoffice-bugs] [Bug 137125] DF Formatting moving around in unexpected way with copy/paste

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=137125

--- Comment #10 from Mike Kaganski <mikekaganski at hotmail.com> ---
(In reply to Heiko Tietze from comment #8)
> > 2. CTRL+A -> Heading number not included in selection... dubious
> The number comes from the chapter numbering, there is nothing to select (and
> delete or modify).

Correct. The number of a numbering is some decoration created by program, not a
typed content that can be freely edited; the same way as e.g. borders. One
would not expect paragraph *borders* to be "selected" when selecting paragraph
text. But indeed one would expect them to be copied as the paragraph attributes
nevertheless. No problem here, except for "I would like it so, that's how I
feel it".

> > 3. CTRL+X -> Heading number comes yellow (dubious)
> We neither want to clear the PS nor loose the PDF. Similar topic was what
> happens when a text has different DF and you delete/add characters.

I suppose that it's something for discussion. The operation is cutting across
different paragraphs; and the end result is combining the properties of the
first and the last ones. It is unclear to me in what circumstances that is the
wanted behavior. I would assume that we need to either keep the start point
formatting, or the end point (no preference personally), but not a mix.

In case when we start and end in the middles of text runs, we likely should
create a text run break with the change of formatting from what was at start
point to what was at the end point. As to paragraph formatting in this case, I
would still believe that it must only keep only one of the property sets -
either start, or the end, but not both.

> > 4. CTRL+V -> Last line becomes centered (dubious)
> Admittedly unclear.

We have some code to apply the current properties to the pasted text's last
line; and I seem to remember commits ~recently regarding that. So this could
even be changing across versions - with a potential to bibisect and learn why
from the affecting commit's message.

> How can we handle any of these reports? First of all, it's a very artificial
> scenario without a good use case. Then it describes one observation where
> generalization is quite difficult ("never center last line of paste text",
> "never change formatting on paste"...). And last but not least we have three
> topics in one report.

Totally agree. The idea of "let me do random stuff and invent expectations" is
questionable; many specifics of behavior are introduced to benefit *specific*
workflows, that deemed important enough; indeed, any behavior that looks
natural in one workflow could be inconvenient in another. So every report
should not be "Expected Results: No clue if correct ... I suggest ... I assume
..." without any evidence that this would be useful, but a discussion of a
specific case where this is breaking one's real workflow. And then, after
investigating why is this behavior is introduced initially (if that was
intentional, of course), the discussion would be about comparison of the
workflows, their relative importance, and user experience.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210915/480afb8d/attachment.htm>