Apache OpenOffice (AOO) Bugzilla – Issue 76054
Cut-Paste/Modify style/drag of paragraph selection expected to preserve styles and not modify anything outside of selection
Last modified: 2013-02-07 22:32:48 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.
Reassigned to SBA.
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?
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.
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!
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.
added as cc
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.
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.
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!
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 ;-)
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 :)
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...
> 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... :)
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.
> 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.
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?
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.
Apologies for being (little) impolite/rude, alon. But indeed, using less words will be a delight, IMO. Cor
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!
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?
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?
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.
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
Created attachment 44344 [details] testcase: document with instructions
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.