Issue 76054 - Cut-Paste/Modify style/drag of paragraph selection expected to preserve styles and not modify anything outside of selection
Summary: Cut-Paste/Modify style/drag of paragraph selection expected to preserve style...
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: OOo 2.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-03 13:12 UTC by alonbl
Modified: 2013-02-07 22:32 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
testcase: document with instructions (9.78 KB, application/vnd.sun.xml.writer)
2007-04-11 12:38 UTC, cno
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description alonbl 2007-04-03 13:12:13 UTC
Hello,

I guess someone already filed this... But I could not find it...

OO text selection is very strange.

For example write four lines of text, then select the first line by going to 
its start pressing <Shift><Down>, the first line is selected as expected.
Now change the style to "Heading 1", you will notice that this affect the 
first two lines, this is unexpected.

Now,
Revert line#2 to "Default style".

Select the first line which is now in "Heading 1" style, by going to its start 
pressing <Shift><Down>.

Press <Delete> key. You will notice that the second line becomes "Heading 
1"... This is unexpected too.

There are a lot of more examples... This behavior is different from any other 
word processor I used, and it makes the work in OO uneasy, since after each 
copy-paste you need to fixup the text that is changed, or you need to select 
the text until the newline marker, and then remove it manually.
Comment 1 michael.ruess 2007-04-03 13:46:34 UTC
Reassigned to SBA.
Comment 2 Mathias_Bauer 2007-04-03 20:19:32 UTC
The difference is that "SHIFT-DOWN" not only marks the whole line but also moves
the cursor to the next line. This is not specific to Writer but also happens in
the text engines of Calc, Draw and Impress.

This is definitely an intended behavior so changing this can't be named a
defect, it's an enhancement. 

I can understand your motivation for this request but I'm not sure if we want to
change our handling of "SHIFT-DOWN" and what side effects this might cause. So
it will take some time to think about it. 

It would be nice to find out if we already got similar requests. If we never got
any complaints about this behavior in several years I would tend to think that
this is more a matter of taste than a real problem. But let's see.

Stefan, can you do a little research about this?
Comment 3 alonbl 2007-04-03 21:10:20 UTC
Hello,

Thank you for addressing this so fast!

Just wanted to note...
Where the cursor is is irrelevant... Only the selection is.

So pressing <Shift><Down> selects the line including the <CR> or 
end-of-paragraph marker.

It DOES NOT select anything at the line where the cursor is located, thus any 
affect on this line is unexpected.

Only the selected region should be handled...

I think Microsoft behavior in this regard is the most correct.

I can write many sequences that do not work as expected.

Another one:

1. Open a new document.
2. Write six lines "Line 1", "Line 2", .... "Line 6".
3. Modify the style of "Line2" to "Heading 1".
4. Turn on the none printable character view.
5. Tripple click Line#3, you will notice that the text is selected but the 
<CR> is not.
6. Press <Ctrl>X, you will notice that the text is deleted but not the <CR> -- 
UNEXPECTED.
7. Press <Ctrl>Z
8. Go to beggining of Line#3, press <Shift><Down> then <Ctrl>X, you will 
notice Line#4 style is modified -- UNEXPECTED.
9. Press <Ctrl>Z
10. Tripple click Line#3, drag selection to beggining of Line#5, you will 
notice that the paragraph is not kept, it is added to the beginning of Line#5 
and the style is lost -- UNEXPECTED.
11. Press <Ctrl>Z
12. Go to beggining of Line#3, press <Shift><Down> then drag it to the 
beginning of Line#5, you will notice that Line#4 style is modified -- 
UNEXPECTED.

So no matter what I am doing unexpected behavior with paragraph selection is 
performed.

I believe this behavior makes many people go crazy with the application... I 
was very surprized not to find an existing report.

Thank you again.
Comment 4 alonbl 2007-04-03 22:52:41 UTC
Oh... Just realized...

Since you said this is intended behavior, maybe I just need some instructions 
of how to move a paragraph from one place in the document to another place, 
without modifying its style and without affecting any other paragraph...

Maybe I just missing something... And OO have some unique sequence for this.

Thanks!
Comment 5 cno 2007-04-04 22:10:03 UTC
Hello Abonnl,
I found only small part of the behavior different in the beginning. 
But adapted very fast and do like it now - of course.
Pls look at http://documentation.openoffice.org or users@openoffice.org for tips
and support.

About your steps:
Your description is not OK. Heading one must be applied to line#3.
Furthermore, all the behavior is OK, when you realise that the paragraph-style
is copied/cut/pasted with the paragraph mark.

Comment 6 cno 2007-04-04 22:15:10 UTC
added as cc
Comment 7 alonbl 2007-04-04 22:50:45 UTC
Well... I am not looking for support... I know the behavior is incorrect... :)

There is no way to move a range of paragraphs from one place to another place 
in a document without affecting any other paragraph while keeping the 
selection styles intact....

I will wait for you to confirm this... Or dismiss this bug.

Even if you find a way to do this, I believe that developers should make an 
effort to provide a consistent environment to users... OO has gone a great 
effort to do this... While this behavior is a major exception.
Comment 8 cno 2007-04-05 08:55:36 UTC
Well ... obviously I needed some extra explanation to see your problem. Thanks
for giving that.

I admit, the way it works now is not convenient in all situations.
Moving one paragraph is no problem (Ctrl-Up or -Down, or maybe Ctrl-Shft-Up or
-Down).
Moving a selection of multiple paragraphs only is a problem when the selection
starts with or ends before a paragraph with different style. In that situation,
moving affects the formatting of other paragraphs, which is not OK.
Comment 9 alonbl 2007-04-05 18:08:14 UTC
Thanks!
Imagine you have 1000 page document... You need a lot of time to move a 
paragraph from top to buttom using <Ctrl><Down> :)

We need Cut&Paste solution... Or mouse drag to by sync with the behavior of 
<Ctrl><Arrow>.

BTW: Mouse tripple click should also mark the end-of-paragraph mark, just like 
<Shift><Down>.

So can you please issue type to DEFECT?

Many thanks!
Comment 10 cno 2007-04-05 18:51:36 UTC
I don't have rights to set the issuetype, so someone else has to do.

PS. I never fel over it, nor did I hear complaints from the many people I help
with OOo. So the defect must not be a big problem for most.
PPS. About editing that 1000 page document: at the users-list there will
probably be assistance in training writing skills ;-) 
Comment 11 alonbl 2007-04-05 19:51:40 UTC
Well... I am trying to move into openoffice since version 1.1.
Any none-profit document I write I try to use openoffice.

Since I am also use Hebrew language (RTL), I could start using it seriosly 
since version 2.0, after adding support to LTRM, RTLM in version 2.1 (If I 
remember correctly). Still have a major issue at bug#74659, the same RTL 
document is not rendered the same in Windows and Linux environment, 
unconfirmed issue of text rendering at bug#74659, and minor issue of special 
Hebrew search issue at bug#74995.

The issue we discuss was known since I begun using it, I always thought it 
will be corrected at next version...

But after a year or so, I thought enough-is-enough... Maybe you just not aware 
of this one. I was very surprised that you are not.

I guess there are many more people who are aware of this issue... But maybe 
some have more patience :)
Comment 12 lohmaier 2007-04-06 10:37:10 UTC
alonbl, your logic is flawed.
> Where the cursor is is irrelevant... Only the selection is.

We're talking about paragraph styles in this issue, so following your logic,
selecting one single word in a paragraph or just positioning the cursor in a
paragraph and applying a paragarph style should do nothing. This surely is not
what the user would expect.

and wrt changing shift down behaviour:
<shift>+<down> does not only work when at the beginning of a line, but also when
the cursor is somewhere in the middle. Changing the behaviour would mean to
implement some obscure logic to handle to two different behaviours. Again having
the app doing different things just because the cursor is at a slightly
different position is not what the user expects. The app must behave consistently.

And to your list of "unexpected" behaviour: Ask other users and they will tell
you some different story.

To move a paragraph, you can just use <ctrl>+<alt>+<up/down>

And your 1000 pages counter: Then you probably don't want to move a single
paragraph, but whole chapters, and then you can use the navigator...
Comment 13 alonbl 2007-04-06 17:23:35 UTC
> alonbl, your logic is flawed.
>> Where the cursor is is irrelevant... Only the selection is.
Well... I wish it was my logic...
It seems the logic of every other application...

> We're talking about paragraph styles in this issue, so following your logic,
> selecting one single word in a paragraph or just positioning the cursor in a
> paragraph and applying a paragarph style should do nothing. This surely is 
not
> what the user would expect.

You got it totally wrong!!!
If the user does not select ANYTHING then:
1. Modifying style modify the style of the whole paragraph.
2. Modifying font/character attribute is modification to future characters.
3. If you like some more examples just tell me... I can write a complete 
algorithm.

If the user SELECT/MARK a region, what we call "selection"
1. Modifying style modify all the paragraphs in the selection.
2. Modify font/character attribute is modification of the exact selection.
3. again...

So... Nothing is flawed here... BTW: Please refer to other applications as 
well.

If the user copy/cut selection, no part of the document should be modified. 
(Edge condition: If the user cut a selection in a middle of paragraph up-to 
and including end-of-paragraph mark, the remaining paragraph text should 
remain as a paragraph)

If you paste a selection which end with an end-of-paragraph mark, then the 
selection will be pasted will not affect any other text. (Edge condition: If 
the selection is paste in a middle of a paragraph, the beggining of the 
paragraph receives the attributes of the selection).

<snip>

> And to your list of "unexpected" behaviour: Ask other users and they will 
tell
> you some different story.

This tells nothing.

> To move a paragraph, you can just use <ctrl>+<alt>+<up/down>

Great... So you forbit user to user Copy/Cut/Paste to do the job... This is 
not a valid approach... Fix the algorithm and you have both ways.

> And your 1000 pages counter: Then you probably don't want to move a single
> paragraph, but whole chapters, and then you can use the navigator...

You know better than users what they do... Well... I must ask you... What if I 
really have the need to move a paragraph and not a complete chapter...? Is it 
too much to ask?

Instead discuss the issue... You tell me not to use selections...
I must say that this is unexpected either... :)
Comment 14 stefan.baltzer 2007-04-10 17:25:45 UTC
SBA: This strongly starts to smell like a collective issue. Especially
"YET-ANOTHER-example of how MS Office does better" makes it a collective issue,
thus INVALID.

Please note that all changes in a central area like text selection will affect
the hundred million users of OOo who happily work with it as it is at times.
Please note that there IS a difference between an issue tracker and a mail
alias. The latter is designed and should be used for discussions. THIS is an
issue tracker. If you disagree, please have a look at issue 1820 and read and
understand it entirely. THAT one is the best example of "how NOT to use an issue
tracker" :-)

So may I get a description of THE ONE thingie to look after, please?

I believe that about 5 lines should be enough to describe incorrect behavior
concerning text selection. If you need more text than this, you should think
about attaching a bugdoc to ease reproduction and comparison with the "expected"
behavior. Give the readers a chance to see what you mean by a handful of easy
clicks, not by "discussing a handbook". Note that "too long to read" is an
aspect that gives issues a fair chance to be "left behind" again and again.

Note: The issues I love most are those where the entire description fits into
the summary.
Comment 15 alonbl 2007-04-10 19:15:10 UTC
> SBA: This strongly starts to smell like a collective issue. Especially
> "YET-ANOTHER-example of how MS Office does better" makes it a collective
> issue, thus INVALID.

Hmmmm.... I guess you consider StarOffice/OpenOffice as a final product...
Nothing to be fixed.... I think it is far from this... And I am willing to help
you guys.
You copied much of MS Office... So why stop here?

> Please note that all changes in a central area like text selection will affect
> the hundred million users of OOo who happily work with it as it is at times.

It is just like you spend all your life lifting heavy load... You are very happy
and not aware that there can be easier life... One day someone comes and take
that load from you... And then you realize how easy life can be...

Let's assume you have hundred million users.... Are they actually happy? Every
time they Cut-Paste a selection or triple click and drag, they need to correct
the source (optionally remove extra new-line, fix styles) and the target (fix
styles). So they are doing much hard work only in order to move a selection.

Wouldn't be happier if you take this load from them?

> Please note that there IS a difference between an issue tracker and a mail
> alias. The latter is designed and should be used for discussions. THIS is an
> issue tracker. If you disagree, please have a look at issue 1820 and read and
> understand it entirely. THAT one is the best example of "how NOT to use an
> issue tracker" :-)

In place of giving a positive example, you give a negative example... No
progress can be achieved.

I handle users my-self in bugzilla, offering support for smartcard related
issues, OpenVPN issues and Gentoo Linux.
So I know what belongs where.

This issue is a BUG, yes... I did not said it explicitly before... This is a BUG
not an ENHANCEMENT or INVALID.

I waited for something like two years before I opened this one, and because this
is a BUG I opened a ticket in issue tracker.

I did not expect that the response would be "Hay, simply don't use Cut-Paste and
you will be happy".

> So may I get a description of THE ONE thingie to look after, please?

Summary modified, I hope you are happy.
I, when playing the role of upstream, modify the description and content once I
understand what the user require, since I accept that user not always know to
find the root cause of an issue.

> I believe that about 5 lines should be enough to describe incorrect behavior
> concerning text selection. If you need more text than this, you should think
> about attaching a bugdoc to ease reproduction and comparison with the 
> "expected" behavior. Give the readers a chance to see what you mean by
> a handful of easy
> clicks, not by "discussing a handbook". Note that "too long to read" is an
> aspect that gives issues a fair chance to be "left behind" again and again.

This is exactly what I have done in comment#0, comment#3.
If you do not like the description you can tell me what you don't understand so
I will improve the description.
At lease cornouws did understand what the problem is... So I am not totally
wrong here.

> Note: The issues I love most are those where the entire description fits into
> the summary.

I wish every problem in the world was simple enough... But the reality is that
most problems are complex. Even if one can write a single sentence, others will
not be able to understand it.

If you like close it as INVALID... It will serve no one, people will continue to
mess up with their Cut-Paste/Drag sequences and be happy since they don't know
better.

I will be happy you try the sequences I posted and acknowledge that the BUG do
exists, and make more millions of users happy with your product.
Comment 16 cno 2007-04-10 19:22:12 UTC
Hi,

I agree alonbl uses far too much words.
However, if I write (Apr 5 07:55:36):
"Moving a selection of multiple paragraphs only is a problem when the selection
starts with or ends before a paragraph with different style. In that situation,
moving affects the formatting of other paragraphs, which is not OK."
... that must be understandable?
Comment 17 alonbl 2007-04-10 20:46:37 UTC
Thank you cornouws.
Although I think the source cause is wrong handling of end-of-paragraph-mark in
selection... Which reflect the way cut-paste-drag is performed.
But I don't wish to bother you all with too many words again... If you solve
cornouws description, I will be happy to file more bugs on more conditions.
Comment 18 cno 2007-04-10 21:10:28 UTC
Apologies for being (little) impolite/rude, alon.
But indeed, using less words will be a delight, IMO.
Cor
Comment 19 alonbl 2007-04-10 21:19:59 UTC
cornouws: This is OK... My English is not so great so I may use too many/wrong
words.
As long as the discussion is technical, and a progress being made I am happy!

I just don't understand the place for "political" responses on issues which are
purely technical.

Well... I will be quite now... I hope you can be this issue representative... So
I won't make too many people angry and this issue will be resolved.

Thanks everyone!
Comment 20 Mathias_Bauer 2007-04-11 07:28:42 UTC
I'm still not through with thinking but at least currently my belief is that the
behavior is intentional and should stay as it is.

SHIFT-DOWN also selects a line end 
SHIFT-END selects the line without the line end

This makes sense: "DOWN" moves the cursor down one line, "END" moves the cursor
to the end of the line. "SHIFT" expands the selection.

So you have both options; even if it may be not what users of other applications
expect it's easy to grasp and has an understandable logic. As Stephan mentioned,
we should respect the expectations of users already used to the current behavior
as long as this is not considered to be totally strange. And I doubt that it is.

A good thing also is that the application exactly tells the user what happens:
if the line end is selected together with the text, the cursor is blinking in
the next line. 

Stephan, I assume that you didn't find any prior complaints about this?
Comment 21 alonbl 2007-04-11 08:59:53 UTC
I promissed to be quite... But I cannot.
> A good thing also is that the application exactly tells the user what
> happens:
> if the line end is selected together with the text, the cursor is blinking 
> in the next line. 

What this have to do with the fact that OO modify style of the lines outside 
of the selection?
Where the cursor is is irrelevant when a selection is made.

Maybe you did not reproduce the problem, may I further help? Do you need more 
sequences?

BTW: If you are so worry about current users response, maybe they just don't 
report, as I did for about two years? Maybe a survey can be sent to your 
greatest users?
Comment 22 Mathias_Bauer 2007-04-11 11:24:30 UTC
This is where your misunderstanding starts: if you use SHIFT-DOWN the selection
touches the second paragraph and so this paragraph is selected wrt. paragraph
attributes. As Christian pointed out, if you just put the cursor in front of the
second line (without selecting the first one) the whole paragraph is affected if
you changed a paragraph attribute.

So if you press "DOWN" and then select a paragraph style the style of the second
paragraph (the one where the cursor is placed) is changed. I hope you won't tell
us that this is wrong.

If you had pressed "SHIFT-DOWN" instead *also* the style of the first one is
changed. But of course nothing changes wrt. the second paragraph, the one where
the cursor now is placed.

This looks very logical to me.
Comment 23 cno 2007-04-11 12:36:56 UTC
Hi Mathias,
Yes, the selection procedure is logic.
However, is some situations, the result of moving a selection is not OK.
Apparantly, not many people/situations suffer from this, I think. Anyway, I had
to try my best to understand Alon's problem.
I've created a small document with instructions. Pls see attachment.
Cor
Comment 24 cno 2007-04-11 12:38:19 UTC
Created attachment 44344 [details]
testcase: document with instructions
Comment 25 stefan.baltzer 2007-04-11 17:01:46 UTC
SBA: Thanks for the bugdoc. It eases understanding this issue more than
yet-another-thousand-words could have. And the summary now reflects the problem.
Good. 

I agree that "technically correct" vs. "intuitive for all" still waits for a
"perfect" solution here.

Again: Too much words hinder processing issues! At least it steals time from all
those who have to read it THROUGH to get the point. And it raises the odds that
a "cross-reader" will miss the most important sentence of the entire description
and thus coming to a "non-satisfying conclusion".  

Reassigned to requirements.