I am using Scrivener 3.4 on the Mac and have already reset all settings (deleted the Application Supprt folder in the Library), but the problem persists.
Example:
New file, new scrivening, no settings made
I write in line 1
Heading 1
Text Text Text Text Text Text Text Text Text Text Text Text Text
then I format the lines as ‘Heading 1’, the other I leave as ‘no formatting’
When I close Scrivener and open it again, all formatting is retained and everything is OK.
However, when I format the text like this, the problem occurs:
Heading 1
(Bullet Point) Text Text Text Text Text Text Text Text Text Text Text Text Text
As expected, line 2 starts with a bullet point (still no paragraph style assigned)
If I now close the project and reopen it, line 2 with the bullet points is changed. The paragraph style ‘Heading 1’ is now also assigned to this line. In addition, I now have two bullet points instead of just one.
I came here to report exactly the same issue. Any idea on vaguely when that update might be @AmberV? I have the same issue on a huge (250k words) book which is due for release next month, so I’m wondering whether I try to work around it manually or hold fire for the minute. Thanks!
I’m a long-time Scrivener user who works heavily with lists, mainly numbered and bulleted. Over the years I’ve tried and tried to work with and around the list formatting bugs, but I keep running into the same wall.
Originally, I purchased both the macOS and Windows versions so I could switch between platforms. Unfortunately, I eventually had to stop using the Windows version because going back and forth between platforms broke the formatting even worse. It kinda feels like I can’t even use what I paid for and the features that were advertised to me. Now, even using only macOS, my lists still constantly break when opening projects: numbers duplicate, list formatting is lost, or fonts change randomly.
I’ve even posted about this issue twice before, but no one replied.
The only semi-workaround I’ve found is to strip out all format styling in and around the lists — but this effectively makes the styles system unusable as a paragraph before and after the list have to be unformatted. This is a huge sacrifice and not one I should have to make.
So I have to ask:
• Is there any reliable way to avoid this list-breaking behavior?
• Is there an hope that this long-standing bug is ever going to be fixed?
I’ve really tried to stick with Scrivener. I have loved using most other parts of the software. But after years of hitting the same problem, I’m at the point where I’ll have to move to different software — and I would honestly recommend others consider doing the same if they rely on lists. I just can’t keep spending all this time fixing basic formatting.
I’m speculating here.
Would the same happen if you made your lists a Style?
On Windows, as far as I know, the Style cannot be made to add a list of numbers and bullets to sequential items with line breaks.
So, in practice, try applying the Style after including the numbers or bullets.
Yes, though I don’t think it is long-standing, as they phrased it. I think there is potentially some conflation with other, cross-platform related, issues.
This specifically only surfaced a few weeks ago, and we’ve had several independent reports all appear since then. That doesn’t fit the pattern of something that has been around for ages—though I suppose it isn’t impossible. Either way, it’s on the list of things to look into for the next update.
I share the same issue, but I’m relieved to know that it’s a bug and that plans are being made to fix it. I conducted a small experiment, and it doesn’t seem to matter where the bullet list is located. Even when it’s in the middle of a longer text, the same issues keep happening.
I agree, per my own post on this issue, that the breaking of dot list formatting on close/open is new (months) but general problems around lists, especially not being able to select one dot point in a list and un-dot list it without also changing the other dort points in the list, is very long standing.
Well, sure, the list code comes from Apple and has had serious bugs (and limitations in the design being extremely basic, like you point out) since its introduction in 2004-ish. We’ve filed countless many issues to them ourselves. Very little gets fixed with it though (and far less in recent years).
But, as demonstrated with this bug in particular, it is possible to do things around, or on top of, lists that make them even more fragile. So the best we can often do is just make sure we have swept as much interference away from around it (same goes for the spell check engine, which is another mess these days, tables, and so on).
Although experiencing a rare L&L bug like this one for phantom lists has produced (at least in my case lately) several duplicate bullets (usually of different sizes), spurious bullets and improperly indented lists, I was wondering whether your referring to the occurrence of a Heading 1 - as the ‘styled text’ - followed by a list immediately beneath it could be 'interrupted/'broken up by the insertion of a space, which would be invisible; and which would aim to restrict any formatting for each object (a heading, a list) to just that object and allow them to behave as they should.
It seems to me (and I know this is an uninformed guess) that the attributes of the list, particularly where it begins and ends, are ‘spilling over’ and affecting the attributes of - in this case - a Heading above (or even below) it. By giving that same Heading a bullet etc. Yes?
What’s odd (again: speculation) is that I can strip all styles (‘No Style’) from any given portion of a page; cut all its text; paste it into BBEdit; remove indents/TABs and bullets; paste it back into Scrivener both which ‘Paste’ and ‘Paste and match Style’; see correct formatting; Save the Project. And on re-opening, one or more of those phenomena is visible.
I can certainly live with that. As I’ve said Scrivener is one of those apps I really enjoy using. But I’m so obsessive about detail that I’d like to get everything looking ‘just so’, if I can.
But if I can’t - at least for the moment - I’m not going to ‘complain’ .
Okay, I’m bringing this over to the discussion on the style + list bug, as others might benefit from any talk of workarounds and the particulars of it. The other thread I just left there for anyone searching the forum for the KeepWithNext placeholder popping up.
It seems to me (and I know this is an uninformed guess) that the attributes of the list, particularly where it begins and ends, are ‘spilling over’ and affecting the attributes of - in this case - a Heading above (or even below) it. By giving that same Heading a bullet etc. Yes?
Yes, I would say that’s probably pretty close to what is happening. The style markers are being placed incorrectly, in the list formatting itself, which breaks the list formatting and can cause the style assignment to bleed across lines.
And given that, in theory an empty line, or any “no style” line between the two should avoid it. It does in my testing anyway.
Bear in mind that if you are doing this directly, you might be pasting right back into the corrupted list formatting, even if the document is empty. It’s a good idea to navigate to another binder item and back, before inserting the cleaned text. It’s the same principle for how if you type a bold word into an empty file, cut it, and then use Paste and Match Style it will return bold. If you instead navigate away and return, it will paste default no style.
These are side-effects of invisible mechanisms that make life better for us in most cases. If you backspace over the last bold character and then type, you don’t have to apply bold again, the cursor holds that formatting temporarily, in the likely case you still want it. If you move the cursor or look at another binder item, stray formatting is automatically cleaned up to avoid files becoming bloated with unused formatting.
Lastly, for broken lists it is almost always easier to select the entire list and maybe even a line above and below, and use Format ▸ Lists ▸ None, then again to pick the bullet type you want. That almost always works, and it avoids having to manually reformat everything within the list (italics, links, whatever), as a full round-trip to a plain-text editor will do. Naturally any duplicated bullets that aren’t part of the list anymore will remain, but they are just tabs and characters at that point—precisely why they paste into BBEdit in the first place.
Indeed. I see exactly the same as @JanB describes here.
Yes. Entirely follow.
Because I can’t get it to avoid it, that may be useful in locating exactly what’s going on; maybe more than one thing? If it’d be of any use whatsoever, of course I’m happy to send you a file etc.
OK. Yes; I tried that and it seems to have worked. Thanks .
Would I be right in thinking that the only way to see which other ‘controls’ might be in the ‘affected’ zone in a Scrivener document would be to examine a hex dump of the content.rtf in the Project’s package? Not something I’d want to mess with and/or save, though !
Will do if the navigate-to-another-doc-and-fix-there fails again.
I know Scrivener can do an excellent job of lists. Even though you say elsewhere that the list code is Apple’s, for me lists in (their) TextEdit make it almost unusable.
So I’m content to wait and wish the team well with the update.
For anyone: I have devised a workaround that will avoid the problem entirely, for now, and in a way that does not degrade the quality of the output when compiling.
When you know you will be following a styled line with a list, type “DELETEME” on a line immediately following the styled line, first, then continue the list.
After typing up the list, go back and position the cursor at the end of the styled line, and press ⌥⇧→ once, to select both the newline and the following “DELETEME” text.
Use the Insert ▸ Inline Annotation shortcut to mark the newline and the deletion marker.
You should have something that looks like the following:
Compiling
Depending on whether or not you actually want annotations to compile, choose one of the following:
If you do not want comments/annotations in the output, you most likely don’t need to do anything. Since the newline is included in the annotation, the extra line and the marker text will both be removed.
If you do want annotations, then in the Replacements tab, on the right side of the compile overview window, create a new entry, hold down the Option key and press Return to insert a newline, then type “DELETEME”. Leave the With field empty. We’re basically just replicating what stripping out inline annotations would do when they are excluded from compile, in other words.
No, RTF files are a bit like HTML in that they are technically plain-text files with markup in them. The main difference is that the markup is nearly inscrutable. Scrivener’s own markers are merely normal text that the software scans for and turns into features or formatting when you load it.
I know Scrivener can do an excellent job of lists. Even though you say elsewhere that the list code is Apple’s, for me lists in (their) TextEdit make it almost unusable.
I wasn’t meaning to comment on the menu commands or buttons that would access them (which indeed any developer can decide to do differently from TextEdit), but the core engine that drives their input, display, and export/conversion capabilities.
Will existing errors in the listings fix themselves or are there any plans for a repair tool?
Is there a tool that opens all RTFs in the .scriv file and can do an automatic bulk edit?
I have a file with just under 150,000 words, in which there are 663 scrivenings containing 6,137 list entries. Roughly 1/4 of the list lines have broken formatting. Sometimes I have lines in which I have 6 bullet points in a row. And I have definitely not worked on all of these lines. I have no idea when and why another indentation with another bullet point is added.
To correct this, I will have to do nothing else for several days.
According to the file manager, the current version has a date in December 2024 and has therefore been out for over half a year and the current version is still offered for download on the website or in the App Store …
Wouldn’t it be more beneficial to remove the version before even more customers destroy their files with it?
Question: If the previous version did not have this error, why is the old version not recommended as a ‘workaround’?
Sorry. But the problem is starting to make me angry as I realise the extent of it.
Question: If the previous version did not have this error, why is the old version not recommended as a ‘workaround’?
I don’t see where that has been said (if someone sees otherwise let me know), and to be clear the current version did not have this error either. It has been out for around six months now as you note, but the problem only cropped up in the past month, which means it was an Apple OS update. Evidently they changed something about their text engine that broke how our code works. In my testing anyway, the older version exhibits the same flaw, now, despite having worked fine for years.
Any news when a real fix will be out?
I do sympathise with the situation you’re in, don’t get me wrong, it’s never fun to have to do more work because of bugs (no matter who they come from). As for fixes, if you use a macro program like Keyboard Maestro, I bet you could record a simple sequence of actions that fixes it and inserts the annotation buffer to keep it from happening again. The fix is very procedural and predictable, which macros thrive on.
It might even be worth the cost of it just to fix this one thing, to you, especially as once you do start using it, you’ll most likely find other ways to make your life easier with it. It’s a very nice tool.
To be clear though, the fix, once it is available, will not be able to fix the lists in all likelihood. I can’t say that for certain, but given what I see of the result, it’s a problem of the actual internal formatting codes getting scrambled up into the wrong places, which then causes the text engine to malfunction and break the list, and once that happens it leaves a trace bullet behind. It’s not a simple display-only problem, in other words.
.