Various bug findings

bug?: “treat all docs with children as folders” option doesn’t affect parent files (1st level)? seems to affect nothing. still have to convert parent files into folders for them to export!

bug: parent folder (even when converted as a file) ALWAYS exports even if there’s no text within it or even if ‘include in compile’ in unchecked [resulting in empty files]

bug: doesn’t switch focus on ctrl+tab when a collection or search result is open

bug: history buttons don’t work properly!

bug: selecting annotation text to end of line also unintentionally selects paragraph break (unless there is an unhighlighted space/character at the end of the line) [so formatting becomes broken when exporting or using copy-special to remove annotations] [<since remedied by converting to footnotes. Phew.] :slight_smile:

bug: “find previous formatting” shortcut doesn’t work, but “find next” works fine

[moved my suggestions to appropriate forum. here are more bugs…]

footnotes don’t always create upon highlighting text and using its shortcut [might take take several attempts; seems purely random]
^
on odd occasions one or few footnotes won’t behave like the rest; it shows like default text

I hope these kinks will be ironed out as this software is just what I needed! It’s given my songwriting a new lease of life. :slight_smile:

That feature only impacts interface navigation, actually. It makes it so that file groups act in all ways like folders do, in terms of what they show when you click on them (Corkboard by default), and how they act when you add new items to them. There are other subtle differences throughout the interface, but those are the main things. To impact how things compile you’ll need to mess with the Formatting compile settings. It sounds like you just need to copy your Folder settings to the middle File Group settings in that pane.

I’m not sure what you mean here, I can’t reproduce this one. If you mean that it merely shows up in the Contents compile list: yes it always will, even if it is unchecked—and in fact you should see it is unchecked in that list as well. This view isn’t so much meant to be a literal preview of what will compile, but an overview of will and will not compile.

But this answer might also be related to the first one. You might just need to be visiting the Formatting pane, rather than trying to adjust things in the outliner. The Formatting pane works off of what you have in the outliner, it’s true, but it is often set up to be permissive and do the same thing for two different types—so thus switching types won’t really do much. You’d need to turn off Titles and Text (and anything else) for the types you truly do not wish to export. That would be more efficient than messing with the Include in Compile checkboxes, too.

History and Ctrl-Tab bugs are noted. Thanks.

I’ll see if there is anything on file for the footnote stuff.

I’ve experimented adding new items to files and folders, but don’t see any different behaviour. How are files, file groups and folders different from each other? The only thing I’ve noticed is the icon - but clearly I’m missing something. Is it in the manual somewhere?

When you select a folder and create a new text item, either via Ctrl-N, Enter, or by clicking one of the buttons or menus, the file will be created as the last child item of the folder. When the subdocuments option is off then selecting a file group and doing the same will cause the text file to be created after the container as a sibling to it, rather than within it as a child. Turning the option on causes it to act like a folder and put the new text file into it as a child. The other difference is when clicking on containers. If you click on a folder, it will use your current group view preference (Corkboard/Outliner/Scriveners). Now, if you turned off the group view mode on a folder, so that you were looking at the folder’s text, then your preferred group view mode is actually off, and so there would appear to be no difference between a folder and file group or even a file. So try clicking on a folder, choosing Corkboard, and then clicking on another folder. It should stick to Corkboard. Now click on a file group. With the subdocuments option on, the file group will act like a folder and load the corkboard. With it off, it will act like a text file and just so you the text of the container item, even though it has children. Another place is in search results. By default when you click on a folder in search results, it shows the folder text instead of its corkboard, because the reason for it being in the search results is a result of its content, not any of its children’s content. You can turn that off though in Navigation preferences, so that clicking on folders in search results goes ahead and uses the group view mode anyway. When the subdocuments option is on, file groups will follow suit.

Ultimately you are correct,there is not a whole lot of difference between files and folders, just a few subtle things. This option when turned on makes the line just a little more blurry. The difference can be made more prominent in the compiler—and that is really what you want to focus on when designing a structure. The use of folders, file groups, and files can give you a lot of flexibility in terms of output. Whether you need that is another matter, but since the compiler’s Formatting pane lets you set up different headers and formats based on these three types, you can creatively use them to accomplish a number of tricky things, like having a Prelude that doesn’t say “Chapter One: Prelude”, because it is a file group instead of a folder, etc.

Not sure if that, if it is the solution, will be feasible for me. In short here’s what happens:

‘Parent folder’ [in editor, contains no text]

text1.doc

text2.doc

selecting this ‘Parent folder’ and then hitting ctrl+x (export) will export all the above but will also produce an additional file titled the same as this ‘Parent folder’. This is inconvinient as it obviously contains no text…

it becomes:
‘Parent folder’

Parent folder.doc
text1.doc

text2.doc

and another bug: in split-screen, selecting a ‘project reference’ always opens in main editor, even when 2nd editor is currently selected. [doubly annoying when the history buttons don’t work and you have to trawl through your directory to go back to the original file!]

and as for the footnote bug, it still stands! I use footnoting a great deal, and rarely text will appear as standard in a footnoted line - even when you ctrl+7 to toggle ghost text, it’ll be unchanged… and I know that it’s footnoted 'cos placing the blinker within the footnote reveals the characters either side as a different colour! It’s odd.

Yes, the empty file export is a known problem. There are two related problems here. That one is more visible. The less visible one is that Scrivener shouldn’t be creating empty RTF files inside the project bundle itself. It should be keeping the system clean so only resources needed are created. But anyway, yes, on the list that one is.

There hasn’t been a release since I responded to this e-mail, so anything previous discussed or reported here will not yet have been fixed in a public release. :slight_smile:

Bug (not beta mind): creating new file/folder in corkboard whilst viewed in a collection cannot be deleted; it simply transports you back to top directory of that collection. I had to delete it from the binder.

This was an accidental annoyance in that I tried highlighting two files in corkboard and pushed enter, hoping they’d both open as splits… but no, it oddly prefers to create a new file. Instead I had to right click > Open > Open in editor. A tad laborious. Hope to see the other bugs I’ve listed fixed sometime…