Lists getting "destroyed" always?

Scrivener Scrivener for Windows
,
21

I am now very concerned about having to change the order of my lists. Is drag and drop just as problematic as cut and paste or cut/paste/match style?

It took me one try to end up in a mess where undo was applying list formatting to the wrong lines and moving things around incorrectly.

The shortcuts for moving paragraphs around, in Edit ▸ Move are a good way of moving things around in a list. But as for the rest I’ll admit to not having much experience with the feature myself, and cannot really comment on whether all of these methods of using styles and section layouts is worth it or not. It seems like something that would benefit from direct testing, to make sure it does what you want before further spending time on it.

22

Oy. Not an answer I anticipated. I’m so glad I asked. Thank you for the ‘fair warning’. I need an alternative.

“List numbering” is a concept that is integral to what I need to output. There is no room for maybe’s or glitches; think of my list as a family with parents, children and grandchildren listed in birth order. There is one, and only one way to reflect that accurately in a hierarchal numbered list. I do not want to use a feature that can “end up in a mess” when it needs an edit. With that in mind…

I’ve also been toying with an alternative approach, which I think might work much better and automate some numbering I need in the process. Theoretically speaking, is this viable?

  • Create a hierarchal ‘template’ for a group of documents that I could copy for each numbered list I need.
  • The top doc would be contain something like “The children of y and his wife x were:” (no title, no heading, no number - it would just be the last section/paragraph of text in (chapter <$n>)
  • Each indented subdoc (child <$sn>) would be the equivalent of one item in a numbered list., the next indent level would be their children (grandchildren <$sn>).
  • The binder docs would be ‘indented’ by generation and use placeholders for hierarchal sub-numbering <chapter $n> (<$sn>, <$sn>) etc.
    I think this will eliminate any renumbering issues when docs/children are edited/ moved around?
  • Assign section names to each list level/generation - say child, grandchild etc. solely for re-assigning styles at compile for various publishers ie. Arabic, roman, alpha numbering and font size/style.
  • Should there ever be occasion to move a child to the grandchild level or vice versa, I could just change the section type in the inspector and all would be good because the both have the <$sn> placeholder - Right?
  • Assign styles to each section name especially indent level. (I’m not sure if I should do more than indent levels in the editor. For compile I would use the styles given by the publisher.)

My reason for contemplating this method over a regular Scrivener list is because of the auto numbering possibilities.

  • If each person is auto numbered in their own doc/chapter, then moving them around wouldn’t be an issue at all with the exception of the possible need to change the section type in the inspector with a click.
  • Since everyone is now in their own doc (or chapter) I could cross-reference anyone, anywhere in my draft and within this hierarchal arrangement by their ‘number’ or chapter or section.

What I haven’t figured out yet is the proper placeholder format to link to the doc, but only print the associated placeholder number, but I know it can be done… Somehow :wink:

I may have mixed up terminology a bit, but I hope it’s clear enough to understand my proposed alternative. Are there any glaring errors/omissions in my thinking?

23

Yeah I might be a little confused about the precise implementation, as this is in response to a thread about enumerated lists in the text editor, but all of your examples seem to be relating to chapter and section numbering?

Well that aside, as it may not be terribly important to know exactly how it is being used, one such improvement I would suggest is to use named auto-numbering streams instead of the $n and $sn pair, which is a pretty limited tool. Using named streams means you can reset them as needed, similar to how some of the built-in formats reset section numbering at each chapter. It means you can use whatever lettering/numbering style you need at each level, and can have more than two levels.

Here is a demonstration compile Format you can import into your compiler sidebar, via the gear button at the bottom of it, to see the idea in action. Everything will be taking place in the Title Options tab, using the prefix and suffix fields.

simple_list_output.scrformat (32.8 KB)

Assign styles to each section name especially indent level. (I’m not sure if I should do more than indent levels in the editor. For compile I would use the styles given by the publisher.)

You could go to that trouble, but if this is really book structure you’re talking about, a far better tool for that would be the “Default Types by Structure” tab, in the Project Settings: Section Types pane. Then if you move a grandchild up to the top, it automatically becomes a ‘chapter’, rather than having open the inspector and muck around. What things are is driven by where they are nested to.

And if you do mean lists, like creating numbered text lists meant to print in the flow of the normal body text, you could still use that same concept there. An idea would be to have all such lists one level below the main text body level, such as in this example (which integrates with the above compile settings):

nested_listing_in_outliner_levels.zip (158.7 KB)

What I haven’t figured out yet is the proper placeholder format to link to the doc, but only print the associated placeholder number, but I know it can be done… Somehow

Type in <$p> into the editor, select the placeholder, and drop the item you want to print the page number for onto the selection, creating an internal link to it. That’s a special case, but most document placeholders will work that way as well. For example, <$title> linked to another item will do just what you expect, so would <$status> or <$custom:NameOfFile>.

Compile that, and the only people that will notice you used something other than lists to generate a body text list are those with access to the word processing file.

2 Likes