There are many problems still with the Lists / Bullets feature. For now, let me mention a couple:
CTRL-ALT-Right Arrow moves text to the right, but not the bullet
CTRL-ALT-Left Arrow will move the text and the bullet, but the bullet format remains the same (it won’t transform to the bullet style for that given level of indent
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
Thanks for your continued work.
Confirming that this problem is still occurring with RC2.
Reporting this issue continues with Beta 23. I’ve noticed that this post has not been assigned a case number even though this has been present in three successive betas. Is there a reason why?
Thanks for your continued work on Scriv 3 for Windows.
I"m confirming, once again, that the above problem with Lists is occurring in the latest beta (v. 24). This is the fourth successive beta for which I’ve reported this problem without it being assigned a case number, or even receiving an acknowledgement from L&L. Is there some reason for this? I’m trying not to take it personally. 
For those of us who speak, present, and teach for a living, Scrivener’s bullets/lists functionality is indispensable. That makes the problems with these functions more than just a nuisance…they are a productivity barrier that one runs into moment to moment.
Just asking that these features get a little love and attention for this segment of your user base.
Thanks for all of the hard work you’re doing to bring Scriv 3 to life for Windows.
Yeah, please don’t take it personally, there just aren’t enough of us to go around. 
Lists on Windows are a bit fragile in how they work, with the combination of first-line and left indents placing both the bullet and the text. If you repeatedly use the Move Text command (which is just the same as Increase Indent), you will eventually see the bullet shifting, but because of what I’ll fondly call the quirky algorithm for this, it won’t move so as to keep consistent spacing. The move/indent commands are at present really designed for standard blocks of text rather than list.
However! Tab and Shift+Tab at the start of a line will indent/outdent the list item correctly so as to keep the bullet spacing tidy and also adjust the bullet style for levels. These are the shortcuts you want to use when working with lists. (You’re probably already familiar, but the Home key will jump you to the start of the line; very handy here.)
I will meanwhile drop in the suggestion to make the Move commands work more in this fashion when the cursor is in a list, if that’s possible. We may be able to implement it in the future.
The blank line bug isn’t limited to lists (though it seems to manifest more immediately when moving bulleted items) and has been filed.
MM,
Thanks so much for the helpful reply, and putting this “Move commands when a cursor is in a list” on the feature suggestion docket.
Microsoft Word’s multi-level outline keyboard commands work swimmingly like this (SHIFT+ALT+ Arrow Keys), and it would be great for this feature to work similarly with Scrivener’s already-existing keyboard shortcuts for “Move Item…” (CTRL+ALT+Arrow Key).
Thanks again!
Jennifer, that’s really useful advice, besides all the other good things you’ve said.
It likely explains why I keep thinking lists work now, because I have the Tab/Shift-Tab ground into my fingers by other apps.
And it may be why the dev crew kind of misses this so far, because softwareish tools often work this way, one might be aware.
Getting this area to work smoothly .for everyone as they approach it seems a very worthy cause, and no doubt everyone in your quite distributed ‘there’ thinks so also.
Best,
Clive
I found that you can’t get out of Lists/Bullet style. I tried to hit Enter multiple times at the end of the list (as in MS-word, you will get a regular line out of it and start a new style), but the Lists/Bullets here stuck.
I can’t even use the Lists/Bullets dropdown menu to change it to “none” to removes the “Lists/Bullets” style.
I had to discard the document and started a new one because I can not stop or get rid of the Lists/Bullets style.
Should I report this on a different topic as I think this is a different bug?
Thank you so much.
Any update on this? In version 3.1.4 on Mac this bug is still alive…
I was excited to see that Beta 33 lists “Bullet list refinements” as one of the items addressed. 
Unfortunately, the issues I’m having–originally reported in August in this thread–persist:
CTRL-ALT-Right Arrow moves text to the right, but not the bullet.
CTRL-ALT-Left Arrow will move the text and the bullet, but the bullet format remains the same (it won’t transform to the bullet style for that given level of indent. It also frequently messes with the alignment of the bullet when compared to the line above or below.
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.
Indenting with TAB (or SHIFT-TAB) only works when cursor is positioned at the beginning of the line.
Again, I’m really hoping these issues can be addressed, as those of us who teach, present, and speak for a living find these problems make using Scrivener for our work maddening at best, and virtually impossible at worst.
Hoping for some bullet and list love before 3.0 release!
Thanks again for all of your work.
About 4) Tab and Shift-Tab indent only when cursor is at the beginning of the list item. This is expected functionality and Word and Scrivener for Mac work the same.
CTRL-ALT-Left/Right in a list item has been fixed and will be available in the next release.
CTRL-ALT-Up/Down in a list item is unchanged.
I just installed Beta 38 (last version I tested was 36), and the CTRL-ALT-[Arrow Keys] no longer function at all in Lists. I’m hoping that this was done by mistake?
Thanks again for all of your work for those of us running Windows.
In Beta 40, bullet formatting only works for one line on text that has a custom Style applied (prior to selecting bullets from the toolbar button). The applied Style persists following carriage return, but the bullet disappears.
This issue does not appear on text with No Style. Bullets persist after carriage return if no custom Style is applied.
I’m adding this report to this thread as it appears there were other bullet issues recently reported and may be related.
I’m in B40 and I’ve suddenly started having issues with numeric lists.
It seems to work as expected with tab and shift tab the first couple of items added to the list, but then shift tab starts getting wonky and the numbering goes haywire. It looks like it’s setting the style to something new, different, and random.
So, to get the style to go back to the original style, I selected the wonky list item, deleted back until it was on the same line as the previous entry and then hit return expecting it to bring the formatting for the previous line with it, but it sets the style to that weird/different style again.
Yes, default bullet styles are broken for me as well. It won’t follow the preset spacing for existing list style that I’m trying to enter new items into. Instead if I add an item, it wants to tab in twice as far when I hit tab the first time.
To make it work properly I need to write a new item without bullet points, then manually apply the built in bullet point style, then hit tab and it works fine.
I don’t know if this is already included in anyone’s previous reports, so I include it here.
Something is very broken. I don’t know if it’s the ruler or styles or lists, or whether whatever it is gets broken on saving or broken on opening. Here’s what happens:
Witness the bullet point disappear and the cursor move to be the far right of the page. Any text written is now invisible. Hitting tab again will move the cursor to the next line, still on the right, and text remains invisible.
Now witness that the bullet point is on the far right hand side of the screen. Still very broken. If you hit delete again you wind up back on the far left where you were to begin with.
This has been inconsistent. Some lists I’ll add an item to only to find the first tab will take me to the middle of the page for the indented bullet.
My ruler settings haven’t been changed from what they used to be, but this beta is very borked for bullets.
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.
Thanks!
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?
If you’re reporting a new issue, then yes, start a new thread.