The following List-related items are still broken in Beta 43:
CTRL-ALT-Up Arrow (or Down Arrow) - moves select line up or down respectively in the list, but inserts a blank line in the process . The wonkiness gets more wonky as you continue to move bullets around like this. Blank spaces, weird hightlights, etc.
If you SHIFT-TAB (or CTRL-ALT-Left Arrow) one too many times, rather than just stopping at bullet level 1, the bullet disappears, and the bulleted list is discontinued. Scrivener should ignore any further left arrow presses once the bullet is at level one, leaving the bulleted list intact. This would be consistent with MS Word behavior.
I tried submitting a bug report on this but I was redirected to this forum. I think it’s related to the problems people are reporting in this thread. Here’s my full bug report, including steps to reproduce.
Product: Scrivener (2.9.0.28 beta)
Platform: Windows (Windows 10 1909)
Bug description:
When copying and pasting list elements (e.g. bullet list), tab stops and indent levels aren’t properly maintained.
Steps to reproduce:
In a new document, create a bullet list and type something in. Copy the text. Hit to go to a new list entry. Paste. The bullet disappears and the pasted text shows up as normal (non-list) text.
Also: Create a list with two entries. Indent the second line. Highlight and copy the second line’s text. Create a third line and paste the text. An extra blank line is incorrectly inserted before the pasted text. Now change the indent level of the pasted text by moving the cursor to the beginning and hitting . Now the indent between the bullet and the text has gotten larger. Now hit to increase the indent. The line will be incorrectly indented further in than previous single-indent list items.
Expected behavior: when pasting text that was copied from a list, it should either paste with the same indents and tab stops as where it’s being pasted or as the place it was copied from. Currently it’s creating entirely new formatting, with no obvious way to reset everything to a single set of tab stops for the sake of list formatting consistency
Additional comments:
This makes lists extremely frustrating and close to useless. The error will compound with more copies and pastes, leading to a less and less consistently formatted list. I’ve ended up having to move the list I was creating into OpenOffice, because I know it will be formatted correctly there. I’d really rather keep it in Scrivener, but until this problem is fixed I won’t be able to do that.
Good to know it’s not just me. Open up a document after saving and you’ll have the same problem adding to perfectly fine lists from before. Really frustrating.
Maybe we need to make this a separate post because I’m not sure it’s a bug being tracked?
I wasn’t sure whether it was a new bug or not and deserved its own tracking. Looks like it’s not gone and deserves a new post perhaps. I’ll make a video and put it up.
The following Bullet / List-related items are still broken in Release Candidate 2:
CTRL-ALT-Up Arrow (or Down Arrow) - moves select line up or down respectively in the list, but inserts a blank line in the process . The wonkiness gets more wonky as you continue to move bullets around like this. Blank spaces, weird highlights, etc.
If you SHIFT-TAB (or CTRL-ALT-Left Arrow) one too many times, rather than just stopping at bullet level 1, the bullet disappears, and the bulleted list is discontinued. Scrivener should ignore any further left arrow presses once the bullet is at level one, leaving the bulleted list intact. This would be consistent with MS Word behavior.
The following are new bugs I discovered with RC2:
SHIFT-TAB on existing bullet item, after getting to leftmost position, will then act like you’re pressing TAB, pushing unbulleted text back to the right.
Changing bullet style on existing list item sometimes doesn’t work
Bullet style at given indent level not retained on future bullets at that same indent level
Changing an existing bullet style on an item in a multi-item list changes the style of the bullets on a different level, often (always?) instead of changing the style of the line you’re currently on.
Sometimes pressing TAB on a new bullet actually moves it to the left instead of the right
Reporting back earlier than expected (I couldn’t wait to test!)
Happy to report that many of the issues I reported are solved. Yay!
There remains at least one unsolved bug, one new bug, and I have one suggestion at this point in testing:
Remaining bug – CTRL+ALT+[UP/DOWN] ARROW still inserts a blank row. This problem is magnified the more you move a bullet around with this keystroke
New bug – sometimes using CTRL+ALT+UP ARROW results in an effect like hitting PAGE UP, except that the cursor doesn’t move like it does with a PAGE UP. Nothing happens with the existing bullet when this happens. I’m not sure why this doesn’t happen all of the time. It also may occur with DOWN ARROW (like a PAGE DOWN), but I haven’t tested long enough to determine that yet.
A suggestion – The visual appearance for the List dropdown is different than the other dropdowns on the same row of the UI. I would suggest making the dropdown the same visual style, matching background, selection color, and selecting the entire row of the dropdown rather than just the selection bullet.
Another thing I noticed when looking at the UI that relates to this: the Style dropdown includes both highlighting and a check mark as a selection “bullet”, whereas the other dropdowns on the row (Font, Font Size, etc.) just have highlighting and no bullet. It seems to me having them all consistent would be more…consistent.
That’s it for now, but I’ll do more extensive testing. I’m so thrilled to see bullets and lists getting some love. My teaching and presenting will be so much easier, and I can abandon MS Word for multilevel lists!
and 2) are tricky, but we will try to make it work.
The Bullets combo box is matching the decoration and style of the surrounded buttons, so that it does not look like it stands alone in the desert. The combo box bullets checkmark is something we are aware and we will try to adjust down the road.
Thanks, Tiho. Anything you can do on 1) and 2) would be appreciated, as without these, using Scrivener to develop a presentation or teaching outline is laborious at best, unusable at worst. So much of presenting and teaching involves reorganization of the material, and pushing it around vertically with these keystrokes, in the same way we’re able to now horizontally with the same keystrokes, is crucial.
Reporting back on vertical Move of bullets (with CTRL-ALT-UP ARROW [DOWN ARROW]) in RC4:
I’m so thrilled to see that this feature has been added! Thanks so much for working on this. You’ve no idea how much of a game-changer this will be for me. It’s my number one feature desire for Scrivener 3!
There remain some bugs with this feature, and I’m listing them in order of usability impact / priority:
More often than not, vertical bullet move operations near bottom of editor window shifts the line with the cursor on it out of view. You must then scroll down in the window to see what happened / where you are.
After using CTRL-ALT-UP ARROW [DOWN ARROW], you must manually deselect text before LEFT ARROW / RIGHT ARROW (or TAB / SHIFT-TAB) operations will work to move bullets left or right. Once text is deselected, sometimes a subsequent left or right move also requires a second keypress before Scrivener responds.
Sometimes vertical moves still insert blank lines. I haven’t yet determined what situations cause this. I’ve noticed this when returning to the middle of a list (bullets above and below) and attempting move, but it’s not consistent. It also may be related to when a list has a blank line in the middle of it (using SHIFT-ENTER to insert the blank line)
Sometimes bullets are dropped during vertical move
Sometimes bullets appear at bottom of the list. This may be related to (4) above.
Turning off bullets and turning them back on resets any customized bullet styles in the current list. This is an easy mistake to make if, when attempting to hit the dropdown arrow on the Lists button on the toolbar, you accidentally click on the button itself. Toggling the List button off/on should not respect the bullet customization of the current list
Selecting more than one bullet and attempting to move (up/down, or left/right) doesn’t work. In MS Word, selecting multiple lines with bullets and then moving them will move them all, including respecting the multi-level indentation of the selected bullets.
Thanks again, Scrivener team, for giving bullets and lists some TLC. It’s going to transform my workflow for presentations and teaching. I’m hoping to avoid using MS Word altogether for teaching outlines and stay exclusively in Scrivener.
-All reported issues from above post on RC4 remain in RC5
-In addition, I discovered another bug. Moving bullets vertically with CTRL-ALT-UP (or down) ARROW sometimes flattens the multi-level indent of bullets above and below. For instance, I may have a multi-level list with four levels. Moving a bullet up and down flattens the above and below bullets to, for instance, level two.
To complicate things a little more for Tiho, Bullet Point are even more broken when used within TABLES.
CTRL-ALT-UP (or down) ARROW on empty bullet points within Tables SHUTS DOWN Scrivener.
To recreate:
Create Basic 2 x3 table, then add an empty bullet point > press CTRL-ALT-UP (or down) ARROW (sometimes it takes multiples presses)
If you create Bullet Point before creating Table, that Bullet Point gets stuck. Pressing Bullet Point Button just adds another Bullet 1mm from the Previous one. The only way to delete it is if you completely delete all table.
This problem is still here too. Sometimes TAB will intend once, sometimes it will DOUBLE that.
OP here, reporting back on bugs with vertical move of bullets (with CTRL-ALT-UP ARROW [DOWN ARROW]) in RC6:
SO EXCITED to see such great progress on this key feature for those of us who work in outlines, presentations, etc!
Four of the bugs I reported in an earlier post are resolved (yay!). The following List/Bullets bugs remain with RC6:
After using CTRL-ALT-UP ARROW [DOWN ARROW], you must manually deselect text before LEFT ARROW / RIGHT ARROW (or TAB / SHIFT-TAB) operations will work to move bullets left or right. Once text is deselected, sometimes a subsequent left or right move also requires a second keypress before Scrivener responds.
If you move an existing bullet vertically to the top or bottom of the window and continue moving it, the window doesn’t scroll to keep the cursor visible on the screen.
Turning off bullets and turning them back on resets any customized bullet styles in the current list. This is an easy mistake for a user to make if, when attempting to hit the dropdown arrow on the Lists button on the toolbar, you accidentally click on the button itself. Toggling the List button off/on while in a list should respect the current bullet customization of that list.
Selecting more than one bullet and attempting to move (up/down, or left/right) doesn’t work. In MS Word, selecting multiple lines with bullets and then moving them will move them all, including respecting the multi-level indentation of the selected bullets.
Bullets will occasionally do the “cha cha” when shifting left or right with CTRL-ALT-LEFT/RIGHT. For instance, trying to shift the bullet to the right, the first press will sometimes shift it to the left, and subsequent presses will then shift it right. Maybe this is an Easter Egg?
Scrivener for Windows team, my deepest thanks for giving attention to the Lists feature. It’s truly going to transform my teaching and speaking in a way Scriv 1.x couldn’t.
[]All bugs reported in my above post on RC6 still exist in RC8
[]NEW with RC7 and RC8- Moving bullets up and down is now flattening the multi-level structure as the seleted bullet moves through it.
CTRL-ALT-[UP, DOWN, LEFT, or RIGHT ARROW] functionality is completely removed in RC9. I hope this is because it’s being worked on and not because the feature is being removed entirely from Scrivener 3?
(1) It is perfectly right thing that functionality working wrong was removed—hopefully until not later than the next release.
(2) Some minor technical problems, less notable, but seemingly connected with some persistent and more fundamental error, are still present in Lists.
If you press Enter to create a new numbered entry, and then press Ctrl+V to paste some text, and there is no any symbol in the newly created entry, i.e. the cursor is on the end-of-line position, then pasting will remove numbering. What is more, Ctrl+Z will be unable to restore the document to the previous state (i.e. the one before pasting).
