Indent gets lost after ending a list (in editor, not compile)

Hey all. Basically, if I make a list (let’s say, when jotting down outline ideas), and get to the end and decide to stop adding list elements via pressing return 2x or using backspace on the final empty list element which is automatically created when pressing return, the indent settings don’t return to what I have it set to in preferences.

So, for example, I have indents set to roughly 0.5 in the preferences for all new document.

I create a new document.

Type some text, all is well. Press return, all is well.

Add a bullet list, type a few elements:

  • Bananas
  • They all float down here
  • Etc. blah blah

And then end the list (as you do, by pressing return on an empty list item or backspacing the empty list item away), and now the indent is 0 from then on throughout the remainder of the document.

The fastest way to recover is to go to the styles dropbox, and select “no style”—which is already selected, but selecting it again suddenly recovers the indent like a champ.

Wondering: does anyone else have this issue? Could it be a configuration issue on my end? Can you reproduce it?

It does kind of get in the way of brainstorming as creating lists negates the indentation if you want to add a list, be done with it, perhaps type a paragraph after, add another list, that sort of thing.

Just to be specific: this is in the editor, not in the compiled document, and is more “aesthetic” for myself as I write, rather than a worry about the finished product, but I do think it’s odd enough to be a bug.

TLDR;
Indentation setting in preferences set to 0.5, which works for all paragraphs like a champ UNTIL one adds a list and then stops adding to the list to return to standard paragraph format, but then the indentation goes to 0 from that point on unless one resets the style to “no style” (even though the text IS set to no style already).

Just to clarify: MacOS 11.6.7 on a 2014 MacBook Pro, with Scrivener 3.2.3 though I have noticed this behavior for a while, with earlier MacOS versions and earlier Scrivener 3 versions.

Lists don’t work.
The forum is loaded with issues related to them.

They work, but only until you tweak them. Simple like that.
(Someone correct me if I am wrong, but I am under the impression that they don’t work any better under Mac than under Windows.)

When I want to make a list (like an outline for part of a chapter, for e.g.), I use a style properly formatted (big indent - space in-between - next style is “self”) to make my paragraphs stand out as being part of a list.
If you need levels, create a style for each and tweak their indent accordingly.

Oh, and Hey :slight_smile: . Welcome to the forum :slight_smile:

1 Like

Possibly this could clarify things. Losing the indent is not a bug.

Lists

:dizzy_face: Foolishly tapped on drmajorbob’s link which immediately signed me out of my own dropbox account on ipad. Caveat linkor.

You didn’t have to sign in to Dropbox on the page at the link.

I didn’t. All I did was click on the link in that post. Surprising behavior, certainly.

Isn’t this what it leads to? Click on the video and it plays. Dozens of people have followed my Dropbox links.

Nope, the link did not deliver me there.

Some fast transitions happened —none of which asked for my intervention, so I can’t give an entirely precise account of what happened. I surmise the link request was handed off to the dbx app, a notice went by seeming to announce it was logging me out of my account, then left me at a page (back in Safari on the ipad) that seemed to have nothing going on but an invitation to log into my dropbox account there. Which I did not do.

Subsequently opening the dropbox app on ipad confirmed I had indeed been logged out.

Very weird, that is.

Thanks for the link.

However, I still stand by my thought that it is a bug. The video plainly shows just what I’m talking about and if it isn’t a bug, it’s certainly unexpected behavior. The unexplained loss of any formatting in a rich text environment is almost always unexpected.

In any editor I’ve used in the past, when one leaves a list, the following line returns to whatever formatting is default, often exactly what the formatting was before the list.

Noting that the formatting dropdown box at the top of the editor notes “no formatting” is in use with a checkmark next to it when you drop down the box, yet clicking that “no formatting” again (essentially setting an already set option, something that should do nothing normally) returns the line and any following paragraphs to the indented format it should have been in.

Furthermore, the iOS app DOES respect, and return to, the default formatting when leaving or ending a list. In the iOS app, type a paragraph, press return, add a list, add items to the list, and then “return your way out” or backspace the last empty list item, and then begin typing—it begins indenting where it had before the list.

All in all it seems at best an oversight, and not really expected behavior that aligns with other editors one may use in daily life.

Not a big deal for sure! I hit cmd-alt-0 (the shortcut for “no format”) once after the list, and it’s just fine, so I’m not talking end of the world stuff here.

But it seems to me a sticking point for someone not savvy enough with this kind of thing, something they wouldn’t understand, and just randomly lose indents after any lists for the rest of the document (assuming they haven’t padded out the bottom of the doc with paragraph breaks ahead of time, of course, but even then they would end up with a weird section of incorrect formatting smack dab in the middle of their doc).

But thank you for the link, and I’ll say it didn’t give me any Dropbox issue at all, though it may have logged the other poster out as Dropbox does that sometimes…it’s one of the best cloud services, but can be a glitchy beast.

1 Like

And thank you for the answer as well as the welcome.

Styles are an idea for sure… For now I’ll just use the “no format” hotkey to return to default formatting after a list, but creating styles for special uses is a great idea.

It’s only unexpected when you don’t know it will happen. Now, you do.

No, it says “No style”. There is always formatting.

That’s almost true, but not really. If it did that, “no style” would be a style, which it is not. Its true behavior is a bit complex, but don’t yield to the temptation to simplify it to what you expect based on other word processors.

Scrivener is not WYSIWYG, and this is one of the ramifications of that.

It isn’t “no format”. It’s “no style”, and that is a very different thing. It’s a different thing in Word and other programs too, not just in Scrivener.

1 Like

As noted in a previous thread:

This is an unfortunately side-effect of how OS X handles lists.

It’s not something we have any control over. The given approach in that thread is now out of date so ignore that. What you have found is the right way to do it now: hit the ⌥⌘0 shortcut (for Format ▸ Styles ▸ No Style) to revert the current empty line you are on back to the default formatting, which would include an indent (among any other shifts in settings) from the sound of it.

This is also a useful tool when working with styles that continue automatically when pressing return. It’s a way of backing out of any custom formatting environment and returning to normal—similar to how one would use a “Normal” or “Body” style in a word processor.

Excellent, thanks for the reply. I was only reporting what I thought was a bug simply due to the fact it seems unexpected behavior, and somewhat illogical just because when one is done with a list, it is a likely use case that they would want to return to prior formatting, indenting, etc. But, hey, I get it. Apple, for all the good stuff they do, also does really really dumb stuff, especially on the software level. I know their constantly changing SDKs and APIs make it a full-time job just keeping software running from year to year, and ⌥⌘0 will just have to suffice.

-Edited to remove replies to other parts of the thread that simply weren’t worth continuing-

Excellent, thanks for the reply. I was only reporting what I thought was a bug simply due to the fact it seems unexpected behavior, and somewhat illogical just because when one is done with a list, it is a likely use case that they would want to return to prior formatting, indenting, etc.

Quite right, I don’t disagree one bit. It’s one of the many little things about Apple’s list tool that could use improvement, but I think they are in a bit of difficult place with it because of how simple the editor is. There is no good way of knowing what “normal” is, really, as the whole thing just keeps cascading off of whatever formatting is currently on the cursor, there is no normal. Scrivener has some concept of that, but this is tacked on top of the text engine, and it isn’t possible for us to inform the listing tool of these modifications, it just works the way it works.

I know their constantly changing SDKs and APIs make it a full-time job just keeping software running from year to year…

Oh yeah, that’s a big problem. In fact right now they are in the multi-year process of rebuilding the text engine from scratch, which at some point is going to make a huge mess of Scrivener once the old method is removed. Probably a long way off, but it’s one of those thing we just have to keep tabs on. We can’t even migrate yet and get on top of it, because the current implementation is incomplete. It is my hope that they rebuild lists and tables though, because unlike Apple’s typical change-everything-continually approach to things, those two in particular have been neglected since their inception. They still have bugs from Mac OS X Tiger, and are using the exact same UI (aesthetic changes to the widgets aside) and interfaces.

1 Like

Oh boy…that sounds…exciting…

I’ll tell you what, I’ve been coding since I was maybe 12 or so. Started in BASIC on an old Atari 8-bit. Did the college thing, all that. I can code in C, C++, assembly for a few architectures, dabbled in Python, enjoyed myself with Lua—mostly a scripting language, but quite quirky and interesting.

And when I look at the Apple stuff, my head spins. The amount of interlinking parts, all relying on one another, in a modern GUI OS, layers upon layers of abstraction, versions upon versions of this and that component, everything breaking everything else and 1000 lines of documentation to scour to find out why widget A broke text area B…

And then they add notches to phones, or change aspect ratios on you…

I’ll stick to my “hacking around because it makes me happy” instead of creating anything complex for production use, thank you very much.

Thumbs up to you folks for doing the dirty work so we have a wonderful program to use.

Thumbs up, but I don’t envy you :slight_smile:

2 Likes

I am not sure if it is a bug or a “feature” :grinning: but, after choosing a list style and hitting the return key twice, the curser defaults to a different indent than the previous text.

Is this suppose to happen? If not, how can I fix this issue?

This post above has notes on what to expect, and how to get your normal formatting back. There is also some discussion on why it works that way, following.