I have links in my Research folder to a number of text files. When I click on the links, the files automatically open in an external editor. I want them to open in a Quick Reference window, or a copyholder, or even in the editor. Anything BUT the external editor. How can I do this?
(Windows) :
The files need to first be imported in the project for them to open internally.
To the exception of web pages, some text files and images, that can be loaded in the bookmarks panel, if set as a project or document bookmark. (Perhaps other files/formats too, that I don’t know.)
On the Mac specifically, hyperlinks in the text can be dragged into an editor or copyholder header bar to load them in the respective viewer. This will use a Quick Look preview if available, or the native viewer if it is a file type Scrivener supports viewing (like PDF). There is no way to load a text file of any kind into a viewer that will be editable, since Scrivener does not support editing random external files directly. Thus the best you’ll get is a read-only view of it (again via Quick Look).
If you don’t already have a Copyholder open, you can efficiently do so by Opt-dragging the header bar icon onto the header bar it came from to do so. Then from there you can drag the link to the text file into the copyholder’s smaller header bar.
Perfect. That’s exactly what I wanted. I don’t need to edit the text files, just to view their contents.
One puzzlement. I use text files with non-standard extensions, and I’ve installed a plug-in for QuickLook that allows me to view such files via QuickLook in the Finder. But when I tried the procedure you’ve suggested, only the files with the standard .txt extension were readable in the copyholder, even tho QuickLook allows me to view, say, text files with a .log extension. Any suggestions for how to fix this?
Many thanks!
Hmm, that’s not something I have tried specifically, but I do know that Quick Look can sometimes be a little cranky and require a reboot after installing something that enables a new view type.
It’s also a long shot, but try going into the Sharing: Import preference pane in Scrivener, and see if .log is registered with Scrivener as a text file type. I would think that only makes a difference when dropping a .log file into the binder, but who knows, maybe it has impact on what the editor will accept as a view as well.
I’ve been using the updated Quick Look for a long time now. It’s not something new for me, and it’s worked fine. It’s also been through many many reboots.
Also, I updated the Import Preference pane in Scrivener a long time ago, and that nicely accommodates all my weird file names. But, as you suspect, only if I drop the file into the binder.
I may try uninstalling and reinstalling my Quick Look plugin. I just wanted to confirm that Scrivener actually uses the MacOS Quick Look for the copyholder display (as opposed to a copy or facsimile of the app).
Yes, any editor view (this includes the Bookmarks pane in the inspector as well) is going to fall back to Quick Look if the file type being displayed there is not directly supported, and I believe that is the only fall back since Quick Look has its own measure of displaying a large document icon if it can’t do anything else.
So if that is what you are seeing, it is QL, and for some reason it is not making use of your plugin. Perhaps it is designed as something that only enhances Finder? It may be worth asking the author of it about, if it can work through third-party tools like Scrivener and DEVONthink (not sure what else does this).
As an aside, on a relatively vanilla test system running macOS 13, I get the following when viewing a .log file in the editor:
As you can see from the footer bar, it is recognising it as a “Log File” (these open in Console by default, as you probably know). The display is slightly different in the Copyholder in that it has no footer bar information, and for some reason it shows the file path as a URI instead of a typical system path, but it otherwise continues to show the content as expected (like all .txt files do on my system).
Amber, your note sent me scrambling for a few days of very hard work to sort out the problem. I’m happy to report it is solved, but not quite in the way you might expect. First some background. The plug-in I’m using is called QLStephen, and it is definitely a QL enhancement. Here’s the source for it:
and if you want an alternative way to install the plug-in, here’s a set of ultra-geeky instructions from the MacApp store (but they work fine if you just copy them blindly):
Note that the MacApp version of the instructions will automatically install the latest version of the plug-in, which runs under Catalina and is supposedly backward-compatible. After doing research for the past two days, I decided that the Catalina version is maybe buggy, and since I’m running Mojave, I actually rolled back my version of the plug-in to the previous version (1.4.4), which is available from GitHub.
Anyway, back to the problem. After losing my mind tweaking plists and clearing caches, I realized that, for most of my text files with non-standard extensions, the plug-in was working fine, and played very nicely with Scrivener as well. But there were a few files that simply wouldn’t preview no matter what I did. Finally I tried copying all the text from one of those files, and pasting it into a new file. Same frustrating result. But that told me the problem was in the file content itself. So I opened the recalcitrant file in BBEdit and used the “show invisible characters” setting to take a look. The very last character in the file was an upside-down question mark that was red; no idea what it was. I deleted it, saved the file, and now it works just fine. Found the same mystifying character embedded in the other files that were troublesome, and deleting the character fixed all of them.
Thanks for the test with the log file. Another thing I found during my research was this blog post:
It seems to explain in exhaustive detail how MacOS parses file names and paths for display, and I’m 99% sure it would explain what you noticed about the URI instead of the file path. Frankly, I haven’t got the stamina to read it at this point. I just want to get back to my project, now that everything works the way it’s supposed to. Thanks very much for all your help!
1 Like
Thanks for the update! It’s strange how a null character (presumably, or something similar) would cause the embedded QL viewer to fail while it worked fine in Finder. Glad to hear you’ve got it figured out and can view these files as intended.