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).
I’m having a weird issue in bullet lists but only when using styles. In case it’s related I’m reporting it in this thread.
Case A: No Style
Bullets work as expected.
Case B: Style Applied
When a style is applied (in my case a custom style of Calibri, Regular, 12pt), when I click the bullet toolbar button a bullet is created for the first line. After hitting Enter, the bullet disappears for the second line when I expect a new bullet should be present as is the case when using bullets in text without styles applied.
I’m using Windows 10 Home, fully updated, with Scrivener Version: 2.9.9.11 Beta (1078037) 64-bit - 14 Oct 2020
When a project is saved and re-opened it seems as if bullet placement is forgotten. New sub-items when tabbed in will be placed at the wrong level of indentation. Old or new sub-items when tabbed back will also be placed wrong. This is shown in the picture below.
[attachment=1]buggybullets.png[/attachment]
Sometimes the bullet/list icon type is forgotten altogether. I have a series of solid circles at any indentation and then a series of squares at any indentation, rather than one icon type per level of indentation.
Edit: Sorry, this and my previous post were meant as an update to a different thread. I can’t update the old post above, sorry, but I’ve removed my post from here, see viewtopic.php?f=57&t=61203&p=327772#p327772 instead if you want to see problems with how they indent.
With RC14, I’m excited to see the moving bullets / changing indent features coming along.
CTRL-ALT-SHIFT + [UP, DOWN, LEFT, or RIGHT ARROW] is working with these caveats:
Moving a bullet up or down sometimes flattens any existing multi-level indentation as the moving bullet passes by. Haven’t figured out why it doesn’t do this every time.
Moving text up and down results in text being selected, which needs to be deselected with mouse click or arrow key stroke before text will continue to move.
Multiple bullets can be selected and moved up and down (yay!), but not left or right.
Thanks again for putting energy into this useful feature for those of us who present, teach, etc.
Wow, thank you Tridens for carrying this torch for us. And thank you to the developers, for whom I’m certain this wasn’t easy.
I’ve been away from the forums (and writing) for a couple years now, and I was floored to return and find bullets and lists were still an issue. Holy shit, Microsoft.
But intuitive list controls and beautiful, consistent results are so necessary, and I’m convinced it’ll be worth the wait.
I am using Scrivener 3 Beta, latest. So far no bugs, yet.
My problem: I’m using the tedious Format/ Paragraph/ Increase/Decrease Indents/ and select either Increase Indents or Decrease Indents as I needed.
I looks to customising the toolbar and add the Increase and Decrease Indent buttons in the toolbar, but I don’t see these buttons in the Customising Toolbar dialog. Confusing…
I searched online, no one got any clue, so I searched here, and found this one after hours of searching. Seems like right place to ask my question: I’m wondering when the I/D indents buttons be back soon?
I find I uses the mouse a lot more than anything else. I’m proofreading huge stacks of stuff, editing as I go. The I/D indents buttons would makes my work a lot easier.
Thanks for making Scrivener awesome, everyone, much obliged.
I can confirm I am still having issues with inconsistent list indentation in RC15; when I carry on a list with indentation from an old session, the indentation of the new lines is inconsistent with the old ones, despite not changing any margins.
Hello, I’m adding my voice to this issue. At this point with all the good work to date, this is now my top issue. I haven’t found any good workarounds, but if anyone has anyone has any, I’d appreciate a pointer to them. Given that this is being worked on, I don’t really need a response. My description below is there in case the developers dive into this thread as part of troubleshooting.
I frequently use outlines/bulleted lists in my work and currently it is very difficult to not have my lists get into problems when editing or moving items in the list. It is ultimately unusable and I end up in situationgs where I cannot figure out how to get the list working after issues appear. I often need to scrap and rebuild the list manually. Undo often does not restore the list to its most previous state either. Issues happen so frequently that I don’t even know where to begin in describing the issues. Some of them are documented in others’ posts. When trying to edit my top two are probably: numbered levels can reset to one; alignments of different levels are inconsistent for no apparent reason.
I posted an example of this in action. It has the side effect of sometimes pushing the cursor all the way to the far right and any new character seems to be interpreted only as a new line character. It is difficult to reproduce in a new project. I’m not sure whether this was a new bug or and old bug, I should have just included it here instead. If I come across it again I’ll post another video with ruler and show invisibles activated - but generally I avoid using lists to avoid exactly this issue now.
I’m not sure whether these bug numbers actually are tracking what we’re reporting now or what we reported initially. I also posted in the new forum, not realizing this forum would be kept open for further comment. So if anyone comes looking for clear examples, see the following video for a demonstration of the issue where after re-opening a project, new list items have a different indentation to lists created before closing/re-opening the project.
