[LH4050][LH4233] Continued problems with Lists / Bullets - moving up/down and changing indent [RC1]

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:

1. CTRL-ALT-Right Arrow moves text to the right, but not the bullet.

2. 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.

3. 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.

4. 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:

• Open an existing document with an existing list
• Hit enter to create a new bullet point item
• Hit tab to indent it once.

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.

• Hit delete to move the bullet back

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:

1. 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.

2. 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.

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:

1. 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.

2. 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:

3. 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.

4. Changing bullet style on existing list item sometimes doesn’t work

5. Bullet style at given indent level not retained on future bullets at that same indent level

6. 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.

7. Sometimes pressing TAB on a new bullet actually moves it to the left instead of the right

How are the bullet lists working for you in the latest RC3, guys? Let me know, if you still face issues, which make the bullets hard to use for you.

Hi Tiho. So excited to try out these new improvements! I’ll give them a whirl this afternoon and report back.

Thanks for all of your effort to bring Scriv 3 for PC to life.

Craig

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:

1. 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

2. 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.

3. 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!

Craig

Thanks, Craig!

1. and 2) are tricky, but we will try to make it work.

2. 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!

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.

Thanks again…I’m cheering you on!

Craig

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:

1. 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.

2. 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.

3. 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)

4. Sometimes bullets are dropped during vertical move

5. Sometimes bullets appear at bottom of the list. This may be related to (4) above.

6. 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

7. 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.