Can't hide in-line annotations. Can't search for comments

I am trying trying trying to find a way to manage glossary/index entries. So far I’ve taken to writing a bit of AppleScript code to generates a string that represents the Epoch in seconds. That is wrapped within a ShortCut Service. That way I can Control click anywhere and my ShortCut will paste this unique string prefixed by the arbitrary “NDXID:” string. Example NDXID: 3819555010. So, I have created a Glossery/Index Entry template and each time I add an entry, I paste the NDXID string with EpochSeconds at the end of the entry. Now, I can copy that NDXID: 3819555010 string and paste it into an comment or footnote but because there is no way to set up a search or search collection that targets comments or footnotes, I am forced to past the sting directly into the text and convert that string into an Inline Annotation because that is the only place I can insert it such that I can perform a search and collection for all instances of pointers to my Glossary Entries. The problem is that unlike footnotes and comments, the presence of these Inline Annotations in the body of my manuscript documents is completely distracting and makes writing and editing anything but pleasant and intuitive. And that is because Scrivener does no offer a way to hide Inline Annotations and Scrivener does not provide a way to search comments or any other metadata that could contain a glossary item’s searchable ID as pointed to a particular selection of text. Comments would be an ideal place for such searchable pointers or backlinks to glossary/index entries, but comments can’t be searched and comments can’t be layered. Try this, select a word in the text displayed in the editor, make a comment attached to that selected word. Now select a longer string of words that includes the word you’ve already attached a comment to. Scrivener will not allow it. You can’t even attach two (or more) comments to the same word. But doesn’t matter anyway as Scrivener doesn’t allow search filters for comments or footnotes or document links, making its impossible to set up search collections as a way to organize and navigate associations between documents. Would be oh so awesome for both the compile pre-print output and for the writing process itself if a glossary/index function could act as an easy navigation and organization aid. I have read through a great deal of the posts and comments regarding these issues here in this forum and nobody seems to have figured out an effective workaround. Admins have suggested using the Notes area to paste such ID’s but Notes are whole-document devices which makes them a non-starter when an index is supposed to target chunks the size of a page or smaller. Suggestions have even been made to slice up chapter documents into smaller sub-documents that could then hold the appropriate ID pointer in their notes. But this only works if one is never going to like more than one glossary/index entry to a particular chunk of text. That simply will not work. It also makes editing and revising a project a nightmare. Admins have then admonished people who are looking for some solution to this problem saying that Scrivener is not a pre-press or layout application. But I find this argument to be a bit more than ridiculous when so much of Scrivener’s appeal is its automated Compile functionality which automates so much of what used to require a specialized pre-press tool and or a team of professional typesetters and book designers. Including a live table of contents and a live index and glossary sections would just be automating what we writers hate hate hate to pay for once our manuscript is complete. And, more importantly, live ToC and Glossary/Index functionality would make the process of writing so much easier. Especially at the granularity of long-form writing, of books and book series. If a glossary would function as a clack and navigate or click and view or click and edit, it would really help writers keep book sized projects comprehendible and humanly possible. Until then, I really doesn’t seem that it would be that much of a problem to allow project search filters to include inline annotations and footnotes and document links and a way to hide and show (keystroke toggle) the visiblity of inline annotations, note links, footnote links, etc in the editor.

If anyone knows of a solution that is viable with the existing versions of Scrivener, please please please let me know.

Thanks

Paragraphs, man, paragraphs.

Seriously, if you want someone to read your words, you need to care about your readers.

4 Likes

I agree with @auxbuss please separate your posts into paragraphs. As a dyslexic I cannot follow such dense text.

4 Likes

As stated by the previous posters, that ginormous, ginormous, ginormous block of text was almost unreadable (I did catch the repeated words).

Though I found myself searching for a delete button and some way to escape, I got the impression that Scrivener may not be the app for you. (the L&L team make no claims that Scrivener is the perfect solution for everyone).

The L&L team have made a number of suggestions that apparently don’t fit what you need. I’m guessing if they can’t suggest a solution within Scrivener as it currently exists, there isn’t one.

I see you’ve been on the forum since 2017, so I’m guessing you’ll have seen a number of the ‘doesn’t seem that it would be that much of a problem’ posts from people suggesting/demanding re-writes of Scrivener to fit their image of what Scrivener should achieve for them, and the various ‘it ain’t that simple’ or ‘does not fit with Keith’s vision for Scrivener’ replies.

5 Likes

Absolutely. I’m not dyslexic, but I took one look at this long tract and immediately thought, “I can’t be bothered to plough through this.”

Mark

4 Likes

This is a misunderstanding I caught near the beginning, which might clear up the rest of it:

Comment text is included as part of the “Text”, the same as inline annotations, so there’s really no difference in this regard for the project search. In both cases you can limit Scrivener to searching in “Text” and the returns will be the documents containing main text, comments, annotations, or footnotes of either type that match the string, which can then be saved as a search collection. With an uncommon string, such as you seem to be using, you’re less likely to get unwanted returns, since it wouldn’t often be used outside of your intended case.

3 Likes