Created attachment 182290 [details] file with bad tab response In tabBad.odt, put cursor at beginning-of-line (position 0), ● hit Tab: cursor moves to indent at 6.4 mm; aaa moves to tab stop with underline as fill character from 6.4 mm to 12.7 mm: cursor is at 6.4 mm, not at 12.7 mm, where aaa is. ● hit arrowRight: cursor moves to indent at 6.4 mm, where aaa is; now, hit Tab: cursor and aaa move to tabStop at 12.7 mm, with (as expected) fill character from 6.4 mm to 12.7 mm. This inconsistent, bizarre behaviour, with partial filling from indent at 6.4 mm to tabStop at 12.7 mm, could be avoided if the Tab key ignored indents and led to tabStops only. Conclusion: Tab key should ignore indents and (as its name implies) respond to tabStops only. tabBag.odt behaves correctly because there is a tabStop at the indent (at 6.4 mm).
Created attachment 182291 [details] file with good tab response
I confirm the described behaviour, but for me behaviour is consistent: tab key should insert an new tab until the next tab stop while right arrow just moves the cursor to the right. So we have two different keys with two different functions and different results are expected. But I also see one question: Why should tab key include jumping to indent (as it does at the moment)? For me this is a valid question. TorrAB, do yopu agree so that we can reduce bug to that question and ask design-team? => NEEDINFO
(In reply to Dieter from comment #2) > I confirm the described behaviour, but for me behaviour is consistent: tab > key should insert an new tab until the next tab stop while right arrow just > moves the cursor to the right. So we have two different keys with two > different functions and different results are expected. > > But I also see one question: Why should tab key include jumping to indent > (as it does at the moment)? For me this is a valid question. > > TorrAB, do you agree so that we can reduce bug to that question and ask > design-team? > => NEEDINFO Yes. This was my conclusion: Tab key should ignore indents and respond only to tabStops.
(In reply to TorrAB from comment #3) > Yes. This was my conclusion: Tab key should ignore indents and respond only > to tabStops. So let's ask Design-Team for further input and decision.
If this enhancement would affect layout of older documents, I wouldn't support it.
I cannot compile the STR into a meaningful bug report or proposal for improvement. And the sample document has quite many modifications to the default. In general and as Dieter commented, the tab key inserts a tab (with attributes set in paragraph style). Going forth and back per arrow key should (and does) go to the position before and after the tab. So I don't see an issue.
(In reply to Heiko Tietze from comment #6) > the sample document has quite many modifications to the default. ● Does Writer get confused by many modifications? How many? > > I don't see an issue. ● You might see it with the new document, tabs6.odt: *Elements AA, BB, BC, HH and DD conform to specs and user expectations; *CC looks like BB and DD but was obtained by hitting the TabKey twice —unexpected. If TabKey had ignored the indent, a single TabKey hit would have entered a Tab filled by underline beginning at the left margin (according to hangingIndent definition), like AA or BC.
Created attachment 182670 [details] file with various tabs and indents.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Heiko Tietze from comment #6) > I cannot compile the STR into a meaningful bug report or proposal for > improvement. Steps: 1. Create a paragraph with an indent 2. Place cursor at beginning of paragraph and press tab-key Actual result: Cursor position at indend Proposal Cursor position at first tab But working on this, I've also detected bug 151203. Perhaps it might be responsible for some trouble decribed here.
(In reply to Dieter from comment #10) > 1. Create a paragraph with an indent > 2. Place cursor at beginning of paragraph and press tab-key > > Actual result: > Cursor position at indend > > Proposal > Cursor position at first tab Inserts a tab for me and places the cursor behind the arrow respectively keeps it in front of the text.
(In reply to Heiko Tietze from comment #11) > Inserts a tab for me and places the cursor behind the arrow respectively > keeps it in front of the text. Yes, but cursor position is at indent position and not at position of first tab stop.
*** Bug 151203 has been marked as a duplicate of this bug. ***
Created attachment 182898 [details] Screencast (In reply to Dieter from comment #10) > Steps: > 1. Create a paragraph with an indent > 2. Place cursor at beginning of paragraph and press tab-key > > Actual result: > Cursor position at indend When I enter a literal tab, the cursor is placed after this character.
We discussed the topic in the design meeting. Issue is that tabs always adopt the indentation for the first line, like 5cm indent, tab = 5cm. However, this convenience feature works only until the tab stop is defined. If, for example, the tab stop is set to 1cm it will not take the indentation. It happens only if no particular tab stop is defined. I see no use case where this _feature_ breaks the workflow. On the contrary it is very convenient for beginners to "indent per tab". So my take here is WF/NAB. If you disagree please reopen. We would have to define a tab stop on the default PS, which likely results in trouble in other scenarios.
Created attachment 183926 [details] file with indent and tabStop
(In reply to Heiko Tietze from comment #15) ● ‘It happens only if no particular tab stop is defined.’ False; it happens also if a particular tab stop is defined beyond the indent. ● ‘It is very convenient for beginners to "indent per tab"’ Why would a beginner (or you) expect the cursor to obey an indent that does not even apply to the current line, where the FirstLineIndent is negative? In tabBal.odt, the 1st TabKey hit gives a ‘normal’ tab, because the cursor stops at the indent; only the 2nd TabKey hit gives the underlined tab; but this underlined tab begins at the indent, not at the margin, where the line begins.
This example is again overly complex. Please define STR like: use PS "Text Body", change attribute X to Y, apply <Foo> to paragraph. To repeat the conclusion, if no tab stop is defined it uses the indentation, which makes sense to me. You are free to challenge this and to suggest alternative. If you reopen, please add your expectation.
tab3.odt (attached) may look ‘overly complex’ because it involves 4 paragraph styles, but each one is simple: one tabStop. Comments are included. "indent per tab" is not ‘very convenient for beginners’ (Compare CCtabbed and DD.); rather, it'a bizarre, ill-conceived, unexpected complication of a very simple action: Go-to-tabStop My expectations? Hit a TabKey and get a filled tab from the beginning-of-line to the next tabStop, in any paragraph style. And this is impossible with HangingIndent if the tabStop is beyond the indent.
Created attachment 183966 [details] file with filled tabStops in 4 different paragraph styles