There aren’t many good reasons for doing so:
- The contents will not be added to the search index (PDFs will).
- Sure, you can hit ⌃⌘O to open it in LibreOffice or whatever, but that’s also pretty much the primary function of a Bookmark.
- And Bookmarks can be viewed in the main editors, so even that isn’t an exclusive capability.
The only real advantage I can think of is if you need both of these conditions:
- The original document (maybe it has complicated layout, pending track changes, whatever Scrivener doesn’t support).
- And you want metadata, notes, an index card and the other benefits that come along with being a binder item.
Even the latter is of slim benefit since a proxy index card created specifically to hold a bookmark to a .docx file is only two actions less convenient to open (⌃⌥O versus ⌃⌥⌘N + Return), and potentially the same level of convenience for mouse users. I use the “library card” method for all kinds of stuff, myself. And if you’re used to using Bookmarks to jump around in your project, the shortcut sequence to use them may well be more engrained into muscle memory than Open in External Editor.
Given how marginal the advantages are, and how confusing it would be to have text files you can’t edit in the binder, actually adding this as a capability really makes no sense. I think the undocumented method I described above is sufficient for those that are really set on the idea despite the alternatives.
[size=110]Aliases[/size]
Aliases are kind of halfway in between symbolic and hard links. They link to the inode rather than the path structure (for non-geeks, it’s a bit like the full zip code instead of the friendlier street address, but more precise), and thus are resilient to the path changing for both the alias and the target—but they are weaker where it comes to source locations that come and go (external drives for example), and particularly in scenarios where the alias is going to be transmitted using non-Mac interfaces. In my experience they can survive movement across volumes with the following conditions:
- If moved together with the target using Mac native methods (including Apple’s provided cp and mv commands), the alias will update to point to the target’s new location.
- If you move or copy the alias by itself to a different volume, then it will remain pointing at the original resource on the other volume.
- If you move the target by itself to a different volume (Command-drag by the way) then the alias on the original volume will break. However, if you later move the item back into its original location, the alias will heal! This is where they do have some similarities to symbolic links.
So give the above, aliases should work even in cases where the project is removed from a context where its aliased research material exists. I.e. if you copy your project to another machine (even from a .zip file) and work on it, your links will be broken for the duration of the session. But when you zip the project up and return to the original machine, plug the external drive back in, et cetera, the aliases will start working again—all thanks to its somewhat hybrid nature. (And that hybrid nature should protect it from non-Mac native archival tools as well.)
Scrivener’s treatment of aliases is a little more robust than one just sitting in the Finder. If the alias was created in a more recent build, then Scrivener would have also stored the original path used to create it, and if the alias itself breaks it will use that path to attempt relocating it, so long as the relative structure around the target is the same. This can help them survive being translocated across machines using cloud technology, where user folder names may differ, and the source material is translocated as well.
So in theory it could mean such an inward facing alias would heal itself in cases where the project ends up being loaded in a different account with a similar folder hierarchy around the target (in this case the project itself). Certainly something to test a few conditions with before committing to though! It does at least qualify under the “move both alias + target together” rule of thumb, and given that the relative structure within the project folder should not be changing, the auto-heal behaviour of Scrivener should also in theory repair them each time you switch machines. (And incidentally, we do something very similar for linked editor images now, too.)
As for safe storage areas within the project (that is, areas that won’t be automatically reclaimed by the orphaned file recovery feature), I would try the root level within the project—where “Snapshots”, “Quick Look” and other folders are. That exemption exists specifically because, with a project’s open nature off of Macs, Windows users tend to use that top level for exactly that kind of convenience—project backups protect these loose files, and they travel around with the project, but aren’t technically a part of it (of course it does kind of negate the idea of keeping backup times down, and most people doing that would probably prefer to know about the alias / shortcut method of outsourcing storage).
Welp, that’s probably way more about aliases than anyone wanted to know.