1. Make an ordered list with 2 items. 2. Place cursor at beginning of each list item, press Tab. 3. For first item, use Bullet and Numbering bar to promote level 4. Use Shift-Tab, with cursor at beginning of first item. Results: - For first item, Actual result (for Tab and Shift-Tab): List level remains the same, but all list items are moved over by one tab. Expected result: List level is increased (for Tab) and decreased (for Shift-Tab). - For second item, Actual and expected result: list level is increased. Tested with 7.2.5 and 7.4.0.0.alpha. Question: Is "first item" results expected, but undocumented behavior? In which case, maybe a <note> should be added about this at: https://help.libreoffice.org/7.4/en-US/text/swriter/guide/insert_tab_innumbering.html
One of the hidden features and by design. Do you see need to change it beyond inconsistency?
1. Tools > Chapter Numbering - Number (None) (for levels 1-9) Tab increasing indent, does not change level for headings after the first level one heading. Shift+Tab does not work at all. 2. Tools > Chapter Numbering - Number (1,2,3...) (for levels 1-9) Tab increases level, without changing indent after first instance. Shift+Tab decreases level This behavior is either not documented. Inconsistency between with and without numbers seems wrong.
But you see the convenience aspect, do you? One is to indent the paragraph the other to demote the list level.
(In reply to Heiko Tietze from comment #1) > One of the hidden features and by design. Needs documentation. Also https://help.libreoffice.org/7.4/en-US/text/swriter/04/01020000.html, which is inaccurate for Tab in the case where the heading (no matter what level) is the first in the document. > Do you see need to change it beyond inconsistency? Intention of OP was only to find out what should be documented. Can definitely see the convenience. From some experimenting.... How about: a. adding Ctrl+Shift+Tab to indent all headings (regardless of which heading the cursor is located) (this would be, in effect, the current behavior when the cursor is located in the first heading/list item, but now could be achieved from any heading/list item) (and Ctrl+Alt+Shift+Tab to move reduce the indent) b. then Tab and Shift+Tab for the first heading/list item could behave the same as all following heading/list items (i.e., increase/decrease level)
I like the idea. We do have the modifier shift+tab right now to insert a real tab without indenting or demoting the list entry. But Miklos pointed out that the behavior of tab at the first vs. following items is in alignment with Microsoft Word (can confirm for MSO365). The question is whether we want to deviate (+1 from my side).
(In reply to Heiko Tietze from comment #5) > I like the idea. We do have the modifier shift+tab right now to insert a > real tab without indenting or demoting the list entry. Hmm, it seems tab/shift-tab does the indent change for the whole list and ctrl-tab inserts a literal tab. It's indeed annoying that we have no easy way to change the indent of only the first bullet. Perhaps if that would be possible, then it would be less painful to keep in sync with Word? (Google Docs seems to have the same behavior than Word, probably indentionally.) Just speaking for myself, I never wanted to insert a literal tab after a bullet, but I want to change the indent of only the first bullet from time to time.
Seeking clarification... (In reply to Heiko Tietze from comment #5) > We do have the modifier shift+tab right now to insert a > real tab without indenting or demoting the list entry. That is ctrl+tab, no? Need to keep shift+tab for increasing list level. And keep ctrl+tab for adding literal tab Have modified summary to CTRL+shift+tab (if that was wrong, then make a clear summary). (also, ctrl+shift+tab should work to indent the entire list, when the cursor is placed on any list item, not just the first one - therefore the proposal of ctrl+alt+shift+tab to move the shifted list back)
* Shift + tab on the first item decreases the indention * Tab on first item increases the indention * Shift + tab on any item but the first does nothing * Tab on any item but the first demotes the list level * Ctrl + tab on any item including the first inserts a literal tab So indention and level are switched per list position (as known from other tools) while literal tab is switched via modifier key (as usual). I see no way out of the dilemma other than to remove one of the three function. And still vote for a straight-forward solution that does not depend on the list position.
Fine, I personally don't have a strong opinion on this. Just don't be surprised if the angry mob appears, asking why we broke compat with GDocs/MSO here and demands a revert. :-) I agree that there is value in not special-casing the first bullet (if you don't know this behavior from GDocs/MSO, then it is surprising).
Seeking for more input. Option a): Keep it as it for compatibility Option b): Drop _indentation_ from keyboard supported functions, use tab/shift+tab on all items for demote/promote, and keep ctrl+tab to insert a literal tab Option c): Drop the possibility for _literal tabs_ and use tab/shift tab for demote/promote and ctrl+tab/shift+ctrl+tab for indent/outdent I think not supporting demote/promote per keyboard is no option.
(In reply to Heiko Tietze from comment #8) > I see no way out of the dilemma other than to remove one of the three > function. What is the dilemma you see?
(In reply to sdc.blanco from comment #11) > What is the dilemma you see? To run three different types (indent, promote, insert) of commands (in total five; int/outdent, promote/demote, insert) with one key (tab) plus accelerators (ctrl/shift, alt is not an option) in a consistent way (without using some random modifier like the list position).
(In reply to Heiko Tietze from comment #12) > (In reply to sdc.blanco from comment #11) > > What is the dilemma you see? Thanks for clarification. Could something like Ctrl+space (with cursor at beginning of list item) be used for introducing literal tab)? For option c) in comment 10, a question about the proposal for ctrl+tab/shift+ctrl+tab: Would those key combinations in/outdent the entire list, independent of the cursor position in the list? (If so, then this seems like the best option, because then can shift lists from any item position, plus can increase/decease list level of first item from keyboard, which is not possible at present. Only "loss" would inserting tab at beginning. If an alternative key combination is not accepted, then cut+paste might be the only way to do this.)
(In reply to sdc.blanco from comment #13) > Could something like Ctrl+space (with cursor at beginning of list item) be > used for introducing literal tab)? This would introduce another inconsistency with space to enter a literal tab. > For option c) in comment 10, a question about the proposal for > ctrl+tab/shift+ctrl+tab: Would those key combinations in/outdent the entire > list, independent of the cursor position in the list? That's the point. The list position is not a modifier anymore and all functions work the same wherever started. > Only "loss" would inserting tab at beginning. If an alternative key > combination is not accepted, then cut+paste might be the only way to do > this.) You can enter a space then tab and delete the leading space finally. But who needs a literal tab before the text?
(In reply to Heiko Tietze from comment #14) > You can enter a space then tab and delete the leading space finally. But who > needs a literal tab before the text? If "insert literal tab" gets dropped, then I will add this "explanation" about how to make a Tab as part of [1] (see bug 141128) and update [2]. (btw, [2] asserts that, depending on the window manager, Alt+Tab can insert a literal tab. Is that wrong?) [1] https://help.libreoffice.org/7.4/en-US/text/swriter/guide/insert_tab_innumbering.html [2] https://help.libreoffice.org/7.4/en-US/text/swriter/04/01020000.html
Patch submitted at https://gerrit.libreoffice.org/c/core/+/134856
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ba2c5e05319181aa00357d66ba2fbaba20231bd3 Resolves tdf#146762 - Consistency for list indent and level shortcuts It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to sdc.blanco from comment #15) > If "insert literal tab" gets dropped, then I will add this "explanation" > about how to make a Tab as part of [1] (see bug 141128) and update [2]. Literal tab has been droppend, please update the help. Maybe it's a good idea to add how to insert a tab now (should be avoided as DF and preferably done per the list style but could be achieved via copy/paste). > (btw, [2] asserts that, depending on the window manager, Alt+Tab can insert > a literal tab. Is that wrong?) Alt+Tab and Ctrl+Tab are handled in the same way. edtwin.cxx #2147 case KEY_TAB | KEY_MOD1: case KEY_TAB | KEY_MOD2: ... Usually the OS eats alt+tab before we can do anything. But you may configure differently. Since 90% are Windows users, where it might be difficult to change the task switcher shortcut, I would omit this information from the help. And ultimately remove the code too.
Created attachment 180796 [details] Current and proposed help section on Tab in list paragraphs and heading Attached is a screenshot of the current help and the proposed help for the different Tab key combinations when the cursor is in a list paragraph or chapter heading. 1. The current shows Windows key combinations, the proposed shows Mac key combinations. (the user gets the combination according to the OS). 2. Presumably it is not possible to control the size of the "alignment" increase/decrease when Ctrl+Tab and Ctrl+Shift+Tab. (If I have presumed incorrectly, then I could mention how to change the size in the documentation). https://gerrit.libreoffice.org/c/help/+/135981 (otherwise -- the patch that changes the behavior of the Tab key with headings and lists works well -- a definite improvement imo)
(In reply to Heiko Tietze from comment #18) > Literal tab has been droppend, please update the help. Maybe it's a good > idea to add how to insert a tab now (should be avoided as DF and preferably > done per the list style but could be achieved via copy/paste). https://gerrit.libreoffice.org/c/help/+/135988
(In reply to sdc.blanco from comment #19) > 2. Presumably it is not possible to control the size of the "alignment" To my knowledge not, the step is likely hard-coded.
I think that depends on the list. The tab just increases e.g. level 1 to level 2, and then the list decides the amount of left indent, which is typically smaller for level 1 and larger for level 2. If you start a new document, then the UI gives you an "automatic" list, with effectively hard-coded values. But if you use the styles sidebar to go with a named list, then you can customize the left indents there, which is not really hard-coded.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/ccf86626a70ee1c7c3b0f3b94a4406328b8116fe tdf#146762, tdf#141128 correction for new tab insert behavior
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/dc1fab4011de88f60e5b8e6a3269971046e25c11 tdf#146762 update Tab key variations in lists and chapter headings
Seth Chaiklin committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/help/commit/d188c4d9e6f35d85346157dd2842890d452738e5 tdf#146762, tdf#141128 correction for new tab insert behavior
Seth Chaiklin committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/help/commit/3560d178a76ce9a87c53619fb56a4b04ba82fa11 tdf#146762 update Tab key variations in lists and chapter headings
(In reply to Miklos Vajna from comment #22) > I think that depends on the list. The tab just increases e.g. level 1 to > level 2, Thanks Miklos -- the context was lost in Heiko's reply -- my alignment question was about the Ctrl+Tab key. Afaict, it always adds 0,64cm to the alignment indent (regardless of initial settings). Not a complaint, was just checking that there was not an option to set the amount of indent/outdent with Ctrl+(Shift+)Tab, which is what Heiko also believes. But your comment has inspired me to add a link to the "Position" tab as a "related topic" to the guide page about using Tab to change list level.
Thanks for the patch Heiko, I can verify that it works as proposed/expected. And the relevant help pages should be updated now, so I will close this ticket as FIXED.
*** Bug 120917 has been marked as a duplicate of this bug. ***