The Edit | Move ability doesn't fully function on Short Story template projects

I found this digging around for how the Edit | Move ability can be best used.

  • the operation we want is as usual, to locate a destination folder once the Move is initiated from Edit, with some number of files/folders documents selected.

  • normally, this works properly, and specifically of interest here, if you don’t have the destination folder in one of the recorded lists, and thus will locate it in the Binder hierarch portion of the panel.

  • the problem comes if the project has been created using the Short Story template, and that the source item/s you want to move are under the Research folder (I used within a folder contained), and your desired destination is within the Manuscript folder.

  • the problem is: you can’t see any hierarchy under the Manuscript folder! Just nothing on a simple or complex project, not sensitive to the amount or depth of Manuscript folders. You’ll just get offered Manuscript itself, while any folders beneath Research will be properly available.

  • I tried renaming Manuscript to Draft. This didn’t improve the situation, still nothing beneath it.

  • I tried renaming Draft to Manuscript in a project not created from Short Story. This did not cause the problem.

  • thus, it’s something deeper in the works than names.

Bon appetit :), and I will mention @AmberV as in one of his guises he seems to be the attendant person for these things, and well appreciated for it…!

In these conditions are you able to successfully choose the Manuscript folder and do the selected things actually move there?

My first guess from your description of events is that at least one of the items which is part of your intended move is not a text document (or folder), but is some other file type like a pdf or jpg or webarchive, etc. No such files (uncompilables) are allowed in the blessed Manuscript folder. Are you able to rule this diagnosis out?

Is the top-level Manuscript folder actually showing up in the Binder hierarchy list in the Move dialog or is it only showing up under Recents in that dialog? When I pursue my diagnosis, Manuscript/Draft does not even show up in the hierarchy for Move when I am moving an uncompilable file, but it will (if conditions are right) still show up under Recents in that dialog sheet.


Yeah, I am not seeing this happen in my testing:

To test this I created the hierarchy you can see here in the Move To panel. For this screenshot I have also enabled the option to show all targets rather than just containers. The document I am trying to move is a simple text item named “move me”, in the Research folder.

Am I not understanding the description?

@gr, @AmberV, ok, good ideas, guys, so I went back to test again though didn’t think I made any of the obvious mistakes.

And found the actual problem, I think.

It’s that where I first noticed this, the Research/folder files that I intended to move were mostly web captures or pdfs.

Quite properly, Scrivener won’t let you put these types in the Compilable main Draft/Manuscript folder. And decides to hide all there as I saw (but not on the Bookmarks or Recent lists), which I‘ll come back to.

Wouldn’t it be very much clearer about this if the top and hierarchy still showed, but was greyed out? Seems simple adjustment to make that so, instead of hiding, if we’re having a release to fix Scrivenings equivalent, no?

Now, coming back to where there is a true bug here. For completeness, I tried moving a non-text-or-container file to Manuscript folders listed in Bookmarks or Recent. Guess what…the move succeeded. I didn’t try to find out what would happen if you tried to Compile the result….

So the suggested greying out should be applied to inappropriate locations in the Bookmarks or Recent list that is offered on the Edit | Move panel, and is a true bug fix, helping justify fixing all through showing all possible destinations but with greyouts.

Break for joke - iPad autocorrection is great so long as you watch it, for things like making ‘greyout’ into ‘greyhound’ here :slight_smile:

I hope this covers the waterfront, as they say. I did think I’d seen the problem on simple fresh test Short Story templates projects, which I did try before reporting, but now I think not, because as you guys found, I can’t duplicate the problem on fresher ones of those, so long as I’m dealing with content that should be allowed to move into the Compilable Manuscript/Draft or some place beneath it.

On any of this, I didn’t try moving into anything but normal folder-apparent destinations. That’s an interesting question, because anything can be/really is a container in Scrivener, which is very appropriate I believe for handling alternate styles of thinking about manuscript structure.

So I experimented, and found that if a text is used as a container, then it shows up as a possible Move destination. This seems proper and sensible, keeping the clutter down, and asking someone to understand what they’re doing, establishing a text as a container before having the ability to move more into it.

1 Like

Nice catch. I can confirm the bug: Uncompilables can be moved into the Draft folder if it appears on the Recents part of the Move target list.

I have not had a chance to see what happens with such an inappropriately placed file when the project is synced and opened on desktop Scriv. Doesn’t sound good!


1 Like

Thanks! Looks like we need to throw that filter on the Recent list. As for what happens on the desktop, it does remain where you moved it, but it obviously doesn’t compile.

1 Like

Good man :palm_tree: :palm_tree:

And yes, Recent, but also Bookmark list.

Also, I really think if the filter greys items out, instead of eliminating them, the use experience will be very much better…

It’s highly confusing when things just disappear — see the original problem a writer felt, which got me to look into this:

Cheers, @AmberV @gr

On the one hand maybe someone might wonder why the Draft folder is missing entirely when moving PDF files, and seek help on why that is. However I would question how much your suggestion would change, as it seems to me that you’d only be moving the confusion from “where is it” to “why can I not”; the same ignorance drives both questions, and how you prohibit one is probably never going to answer that question.

Meanwhile the suggestion would add a great deal of clutter to a software request that has nothing to do with the Draft folder. To move a PDF from one folder to another, I’d have to scroll past 500 irrelevant grey Draft items every single time to get to the only part of the list that actually matters.

Hmm - good and careful thoughts, motivated by long acquaintance with the breadth of uses, for sure :).

I hadn’t considered the clutter potential, when lots of pdfs, etc. in a folder, and that’s real.

It does occur to me to solve it by splitting the listing:

  • at top, list the allowed candidates (text docs) for a given folder
  • below that, list greyed-out disallowd files, for a given folder
  • only show folder contents when you open it (this may be the current operationI think, away from iPad)

Thus if present, clutter isn’t shown unless you open that folder.
If there is high clutter, it is scrolled off screen below any legals
This acts ike order-by-file-type in Windows, etc.

What do you think?