OO.o Word processor basic bug: same bug since years!

[rm53]

Since the earliest versions StarOffice, OpenOffice and variants (NeoOffice) all suffer from some basic flaws which IMHO render them useless for real text processing needs.
Most important: Incorrect handling of paragraph properties (which should be stored in the paragraph symbol, the mirrowed "P").
You can reproduce this error very easily:
- start a new text doc
- write five (or so) paragraphs of text
- set the first, third, ... paragraphs to be style "Heading 1"
then:
- cut the complete third paragraph (the heading)
*** error1: the fourth paragraph suddenly is of style "Heading 1", but obviously it should be unchanged (style "Standard" or what it was).
- paste the contents of the clipboard
*** error2: the fourth paragraph is still formatted incorrectly. Obviously cutting then pasting the same object at the same place should be a no-op!

These behaviors make editing documents like gambling. You never know what happens to your formatting when cutting, moving or deleting parts of the text.

Further flaws include the absence of a line selection tool/cursor in the left margin of text, and some other minor things.
Could somebody take care of such really basic word processing features?
The OpenOffice software family has thousands of features, each new version brings more, but the most important things remain as buggy as they always were... why?

[OPENSTEP]

Well, the best place to start filing design bugs against that portion of OOo is the word processing project of OOo itself:

http://sw.openoffice.org/

That's the one that the Sun StarOffice designers will read. Here we're mostly Mac guys and haven't been changing the underlying design of the program....yet Not enough time

If it's something that's been there for that long, though, I suspect it may just be the preference of the designer who originally made StarOffice. Frankly, I'd love to get the application to the point where we can plug in different behaviours and interfaces (e.g. match FullWrite, Mac Word 5.1, etc.). Dan's been thinking about how to execute Camino style interfaces...that wouldn't solve fundamental things like the line selection/editing style, however, so perhaps we need to think a little bit deeper?

ed