Created attachment 165943 [details]
Example file

Yes, more or less the same as bug 105352... however love to point out the discomfort with the current implementation (and showing the symptoms)

But there is no solution except breaking other workflows that might be more common.

(In reply to Heiko Tietze from comment #3)
> But there is no solution except breaking other workflows that might be more
> common.

Hold on :-). Assume you did expect that already. I understand that behavior changes can be little tricky. So yes, cautious is required. So no don't solve things at the first best request. 

However, they their might be someone body relying on it is as such not really convincing.. Someone changed the default anchoring to :-). Didn't hear a bleep. They whole paragraph anchoring included in selection.. nobody noticed.. Restructuring dialogs? How did you survive that?

So not going 'accept' a general comment on could break possibly break workflows.. That's bit simply excuse to avoid hairy topic.

They current case pretty obviously 'breaking workflow' if it's up to me (which you didn't explicitly deny or admit). So would love to now you're opinion. If this is fits you're model (or not). 

If yes; we disagree on that.. if not, I can point my argument there :-)

FWIW: it's always the formatting at the end of the line causing 'issues'. It's the case here. The copy/paste topic (bug 105352). And I even tend to assume bug 135907.

Related to this specific bug. Fix could be limited to cut/paste (i think). I can think of a situation where this becoming worse compared the current implementation. I can really not thing of someone wanting the formatting of the end of the line. Or even multi-paragraph moving up.

(In reply to Telesto from comment #4)
> So would love to now you're opinion.

The described issue is clear and I would also expect the original layout after pasting. However, since this boils down how DF is handled I disagree (we discussed whether or not to continue the formatting to the left or right somewhere else).

> Related to this specific bug. Fix could be limited to cut/paste...

Doubt that. We must avoid (obvious) special situations where users cannot grasp the underlying mechanism. And introducing special behavior has always the danger of ignoring other corner cases.

(In reply to Heiko Tietze from comment #5)
> (In reply to Telesto from comment #4)
> > So would love to now you're opinion.
> 
> The described issue is clear and I would also expect the original layout
> after pasting. However, since this boils down how DF is handled I disagree
> (we discussed whether or not to continue the formatting to the left or right
> somewhere else).

That 'left/right' is indeed true. However, the whole topic isn't debated properly. Mostly ending in the introduction of the faceless, anonymous user (or group of users; the angry mob) who will hunt you the rest of you're live. 

The 'other reports' are all 'encountering'. hopefully not duplicates.. where it's the same thing (that's what it looks like).

> 
> > Related to this specific bug. Fix could be limited to cut/paste...
> 
> Doubt that. We must avoid (obvious) special situations where users cannot
> grasp the underlying mechanism. And introducing special behavior has always
> the danger of ignoring other corner cases.

Those are my lines :-). I'm indeed disliking resolving special cases (or doing it case by case basis). Problem is I don't oversee the variables at work.
Nor if this can be solved at one place in the code. The anchoring selecting behavior is still not totally in line with the model M. Stahl described. Keep finding flaws here an there (and there are already numerous solved).

Currently I would still opt for set formatting to begin of the line (cut paste & backspace). Instead of using the formatting at the end. Which would mean b*b* backspace.. would end up in non-bold (current bold) too.

I don't think this specific 'example' being an acceptable loss (it's a change in behavior; that for sure). 
--

However I'm really dislike going to the impasse situation which obviously never will be 'resolved' by itself. I'm more a proponent of the "Utilitarianism" view. 

So if we (a certain audience; not we both) agree this would be in general a better solution, this should in principle be implemented. 

Of course starting with an impact assessment. If we would want a change here.. How would the problem is (is this practical limited to cut/paste). Or should different scenario's taken into account.

So the first question is where see the developer the opportunity to make the change to get the desired result (while being consistent in usage over the line). Or at minimum feeling naturally (so it might be some theoretical difference.. but pragmatically/practically no issue)

---
Next step would be getting some feedback from the public. So blog post. We see problem A from our perspective. We see solution X from our perspective. Which would also result XYZ. What do you think. So we are as open as possible. We don't get full user base. We never will.. but say we tried to be open (not an obscure bug tracker thingy). We could throw it at local community's to discuss.. (and lets see what those people think)

--
If that's cleared the next step would be building a proof of concept (so build with the change implemented). Separate build (or master build; with bunch of room to test; what I call the Justin L approach). Assuming that this not being a $ 100.000,- topic.

Lets try , lets see if this would be workable. Or if we encounter major blow backs. Which needs fixing again.. or causing to reconsider the original idea (as it won't work as predicted/expected). So got becoming worse 

This ideally again with blog/ throw it at local community (as we discussed earlier bla.. now we have proof of concept. Please try and let us know what you think.

---
If that's going well too. we getting to the point of Release Notes. After careful and long deliberation we decided to make a change in DF logic.
This to deal with XYZ. This will cause changes in cases like DEF. We think it's overall for the better.

Comments, bugs reports etc are still welcome. (Re)evaluation of the change will take place after 4 months (after final release) at UX with the feedback received.

If you have issues with new behavior, please report, hold on to LibreOffice stable and wait for the re-evaluation.. 

This more transparent compared MS will ever be. And give expression to be open of users (community). And not being kept hostage by the (mental present) faceless anonymous user who might object against the change.

Dislike gridlocks.. Of course if developers say - objectively - this isn't realistic because or desired code-wise because of XYZ.. we now also more 

And yes, I do see that such a change might introduce some regressions; however not really new (see my regression fixed list). So let's not pretend this never happens on other occasions :-)

(In reply to Heiko Tietze from comment #5)
> However, since this boils down how DF is handled I disagree

Heiko, where can I get informations "how DF is handled"? I could only find [1], but without a deeper understanding of DF I would also expect the results Telesto expects. (I must admit, I haven't read all comments in detailed.


[1] https://help.libreoffice.org/7.2/en-US/text/shared/guide/undo_formatting.html?&DbPAR=WRITER&System=WIN

We discuss the same questions again and again. Mike explained on several tickets how it works, not just DF but styles in general.

> 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).

> 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.

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


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.

Maybe it's a question of documentation ("What's a paragraph?", "In what situation will DF/PDF be kept?" etc.) but I doubt users will seek for or understand this without much background knowledge. We rather have to take care of common understanding such as 'continue with the current format', 'don't auto clean any format', 'modification follows the reading direction' etc. Rules that hardly can formalized.

(In reply to Heiko Tietze from comment #8)
> 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.

I understand you POV, but it's always possible that such observations are reported and QA has to decide how to handle it.

> Maybe it's a question of documentation ("What's a paragraph?", "In what
> situation will DF/PDF be kept?" etc.) but I doubt users will seek for or
> understand this without much background knowledge. We rather have to take
> care of common understanding such as 'continue with the current format',
> 'don't auto clean any format', 'modification follows the reading direction'
> etc. Rules that hardly can formalized.

I also understand this POV and I don't think that documentation can or should describe everything.

But I also think, that work on QA will be much easier, if relevant informations are not only hided in previous bug reports but somewhere you have easy access to.

(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.

(In reply to Dieter from comment #9)
> But I also think, that work on QA will be much easier, if relevant
> informations are not only hided in previous bug reports but somewhere you
> have easy access to.

You are looking for a requirements engineering tool where _all_ functions are documented and referenced. Ideally with a user story for the reason - and to check later if it still applies. I'd welcome such a tool very much but doubt that our "chaotic" open source development can become formalized. Besides it would be a huge effort to collect all information from the past 30 years.

(In reply to Heiko Tietze from comment #11)
> (In reply to Dieter from comment #9)
> > But I also think, that work on QA will be much easier, if relevant
> > informations are not only hided in previous bug reports but somewhere you
> > have easy access to.
> 
> You are looking for a requirements engineering tool where _all_ functions
> are documented and referenced. Ideally with a user story for the reason -
> and to check later if it still applies. I'd welcome such a tool very much
> but doubt that our "chaotic" open source development can become formalized.
> Besides it would be a huge effort to collect all information from the past
> 30 years.

Don't throw the baby out with the bathwater. It would already help if current topics where 'documented' (which also includes some flashbacks as far someone can dig up). The past is the past. Documentation that is mission impossible. However documenting the current would already needing quite some discipline (and someone explicitly responsible), else it will fail. And in the light of the  "chaotic" open source development... 
However I do share Dieters view that life would be much easier having relevant information.

(In reply to Mike Kaganski from comment #10)
> 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. 

This kind of an issue of case by case (or incident based) bug reporting hitting fundamental questions without a straight forward answer :-). I do observe something I find 'extraordinary' or dislike in certain case.. I would be very pretentious of me saying: this is wrong and should be XYZ if I'm aware that there isn't a single answer and being a complicated topic.

I'm also well aware how delicate the matter of change (of (layout) code) is. Not knowing in advance what will happen if it got changed. If the positive aspect will outweigh the negative (in hindsight) in general. Or they change ends up being a "can of worms.." which hunting the developer for ever ..

OTOH I not big fan of having "status quo" by unknowns. Innovation needs 'radical' change.  
Which ends up in lovely dilemma.  Rock or Hard place: https://c.tenor.com/fDZOE4okO3EAAAAC/homer-simpsons.gif

I illustrate my doubts in the bug report.. I could have bluntly argued this being totally broken. However it doesn't change much. Except someone would point out, well this isn't that simple..

> 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.

I fully agree with steps described here. I really wish this being possible. However I'm stuck at the operationalization aspects. How to inventorize workflows. How to grade the relative importance respectively user experience (and by who) 

Even after all those analysis you might still miss out something (overlooking something; or something like emergence]. 

The assessment in advance brings us only so far (it's surely not a step to be missed, but no panacea either). The ultimate test will always be the actual implementation :-(. However this can again being perceived as experimenting of the back of the end-user.. 

No clue what's the right think to do

Discussion is important but clearly behind the scope of a bug report. So I suggest to close it.

(In reply to Dieter from comment #14)
> Discussion is important but clearly behind the scope of a bug report. So I
> suggest to close it.

I think it's reasonable to do?
* Not sure if there is room for a sleeping bug related to comment 10 point 3?
* Another options is to stag all similar bugs into a meta bug [even as closed bugs]. Simply to make it easier to find those back

No further input to this bug for almoast one year. So let's close it, since it is no longer a proper bug report and it mixes different topics. Discussion in different comments might be important, but should be discussed somewhere else.


(In reply to Telesto from comment #15)
> * Another options is to stag all similar bugs into a meta bug [even as
> closed bugs]. Simply to make it easier to find those back

Feel free to do so. 


=> RESOLVED INSUFFICIENTDATA