Autocomplete binder titles that contains "dot"

Hi there,

I don’t know if that was intentional, but the autocomplete feature doesn’t work under the following conditions.

I’ve got a binder item named “4a.3a - propriedades generativas”

Upon creating an internal link with [[ ]], if I type up to the dot, it works fine; it’ll present a list of all binder items that begin with “4a.

If I narrow it down to 4a.3 It doesn’t bring any option, even though I have files whose titles begin with “4a.3b”, “4a.3b\1”, “4a.3b\2”, etc.

Any character inserted after the dot will prevent autocompletion from working.

Was this intentional, or is there any other reason why it’s behaving like this?

Yes, this is a known limitation with the auto-complete code that is made available by the Mac. Punctuation and spaces are considered breaks in what it looks for. There unfortunately isn’t a good way around it other than hard-coded completions (like how it can suggestion internal placeholders after typing <$ into the editor).

By the way, unless you have a good reason to do all of this numbering yourself by hand in the binder, you might want to look into having the compiler add this numbering for you. That would in many cases make the titles easier to type in anyway (and remember). That are situations where it is very important to have visible numbering in the work space (legal work comes to mind), but it is at least good to know you can leave that up to the computer to handle for you, if possible.

1 Like

AmberV, thanks for the lightning-fast answer.

I think I’ll try something else instead of punctuation, then. I only got a bunch of files, no more than 20.

I’ve been using Scrivener for a while, going through the process until compile phase. It’s been incredibly helpful.

But now, in my PhD, I’ve been trying to push it further, but setting up a zettelkasten, I’m just beginning, so I’m still finding my place around it (I even read some comments of yours about it here and there).

Anyway, I don’t intend to ever compile this file, at the very maximum, export it as individual files and import it elsewhere. That’s if I can’t keep up with the project inside Scrivener, which I hope never happens, for I wish to make this my final solution for note-taking in an academic context :crossed_fingers:t4:

I’ve tryed The Archive and Zettlr, but I find that the time I spend trying to learn how to use new software is better spent reading and writing the thesis. Besides, it’s much easier to integrate between two Scrivener files than The Archive and Scrivener or any other combination.

Thanks for the reply, and If you can point me to other sources on how to manage this kind of project inside Scriver, I’d much appreciate it.

Ah! That explains the “ID” looking prefix then; I should have realised that is what you were doing as it would be a strange way to number things in a book. I completely understand what you are doing, and yes that makes sense to have it in the title. That is what I do as well with a similarly designed system.

I use numbers (a compressed date and time basically), which tends to work well with auto-complete, but my system has a heavier chronology focus than topical, as ZK does.

Thanks for the reply, and If you can point me to other sources on how to manage this kind of project inside Scriver, I’d much appreciate it.

So one thing you can do with a system like this is use the Quick Search tool in the main toolbar. To use your example, you could type in “propried” or however much it takes to find it—or even the ID if you know it. Once what you want to see pops up in the list, drag and drop from the search result list into the editor. Now you have a link pointing to the item. Obviously you don’t need the brackets in that case since the result is already a link.

Even though that involves using the mouse, I often find that to be the most efficient tool, because you don’t need to know how the title begins, or every word within it, or even the title at all because you will find it also locates text matches too. It depends. I use a combination of double-brackets, quick search and even Copyholders to manage linking.

The last one might seem odd, until you consider that a copyholder sticks to the editor no matter where you navigate to, and dragging the icon out of its header bar into the other text editor creates a link. I just make it as small as possible and drag it out whenever needed. This trick is thus very handy when you have developed a new thought that you would like to network it with multiple existing cards.

I’ve tryed The Archive and Zettlr, but I find that the time I spend trying to learn how to use new software is better spent reading and writing the thesis. Besides, it’s much easier to integrate between two Scrivener files than The Archive and Scrivener or any other combination.

I’ve tried both of those as well, and found Zettlr to be the more interesting of the two, but as much as it has a more focused framework for this kind of note-taking than Scrivener does, the overall project window interface feels more capable to me, particularly where it comes to long-form writing (but that’s to be expected). However for some reason what works well for long-form writing seems to also work well for lots of really short “cards” that are linked together.

Here are some posts that might give you some ideas:

  • Using a project as a scratch pad replacement. I wrote about how the user interface can make such a difference above. Well one of those things that makes Scrivener ideal, to me, is how flexible it is interface is. This project template demonstrates a way of turning Scrivener into a tool that is very focused on rapid note taking in a more “flat list of linked cards” way. This project doesn’t even use the binder!

  • Creating an external “inbox” for your project. If your notes often come from outside of Scrivener, maybe even from outside of your computer, this can be handy. You can set up a folder where you save .txt/.md/.rtf files and have those automatically imported into the project the next time you load it.

    An interesting thing here though is that if you use that feature more as intended, as a way of editing the contents of your binder with other tools, this can open up the use of other tools that are also file system oriented. I haven’t tried it with Zettlr, but in theory I think it should work fine with a folder of .md files. You can kind of have the best of both worlds here, in other words!

  • Integrating two projects together with external links: it looks like you are already on top of this, but just in case, this makes the “notepad” style project idea above more interesting.

  • Tips for linking in Scrivener: you probably already know most of this, but at the bottom of that post is another list of links on topics (some already here).

2 Likes

Thank you @AmberV. What an insightful piece. Very useful for those of us involved in and writing about academic research or otherwise (whatever form that takes).

@AmberV, thank you very much for the information.

With feature-rich software like Scrivener, there’s always the possibility of forgetting something we once knew. I’ve used the drag-and-drop feature before but completely forgot about it in the last couple of days. Thanks for the reminder!

I’ve seen your “Using a project as a scratch pad replacement”, but for the moment, I’ve settled with the Dual Navigation layout, as I can always work with at least two items. With your tip of dragging items, I can use the “Go to Collections” on the Outliner and then drag the relevant note on the left editor!

If I set some keyboard shortcuts for the Collections (4. philosophy, 1. economics, etc.), I can use ⌃Tab to move to the Outliner and then something like ⌥⌘4 to go to the philosophy collection. A much-improved workflow. Thanks again!

But I still got one last question and one request.

You’ve mentioned the Quick Search tool in the main toolbar, but I’m using the search options in the Outliner view on the right (Dual Navigation), but if I change what’s being displayed in it, the search bar goes away.

The question: isn’t there a way to make it stick there?
That’d be interesting since I’ve opted to “auto-hide” the toolbar in full-screen mode (small 13-inch screen).

The request: Can the autocomplete option be brought to the file name field?
I know it wouldn’t cater for the masses, but for someone adding a sequential naming convention, even a weird one, it could speed up the process of finding the last file with a given sequence.

1 Like

Oh, I forgot something. Now it truly is the last point.

I know the idea behind Compile is “multiple binder items, one output”.

But in case I ever have to get my notes out as single files keeping some linking system… is it possible?

I’m asking because if I need to implement some changes to my notes, something of the Markdown world (which I’d have to learn), I better do it now that I’ve only got a few cards instead of down the road with hundreds of notes.

The outliner/corkboard filter bar is designed to vanish and stop doing anything the moment you navigate elsewhere. It was thought that it would confuse people if it stayed active until you dismissed it. The compromise is that hitting Ctrl+F / ⌘F brings all of the settings back, so you just have to hit that whenever you change what you’re viewing.

Can the autocomplete option be brought to the file name field?

That has been requested before, but as far as I know it never went anywhere. It makes sense to me as well, as what we might want auto-completed in the main text seems equally useful in how we identify and refer to the text.

I’m asking because if I need to implement some changes to my notes, something of the Markdown world (which I’d have to learn), I better do it now that I’ve only got a few cards instead of down the road with hundreds of notes.

While it is possible to compile with links (depending on the file type output), it’s a global on/off setting in the compiler, which makes using a mix of link intentions difficult. There isn’t a clear way of saying that this link here should be in the compiled output but not this one.

Markdown does make that possible though, very simply, because links in Markdown are a matter of punctuation. The difference between a link you intend to “publish” and a link you do not is simply whether or not it has square brackets around it. This is a cross-reference in Markdown: [Name of Binder Item]. Thus with wiki links turned on you just type in three instead of two. Scrivener strips out the two leaving the third behind.

But yes, as you say, now is the best time to figure out how you want to do things—but another advantage of a plain-text way of marking links is that it is a lot easier to change your mind later on, or even to use a form of shorthand while writing, that gets expanded with compile Replacements or other methods, later on. I do something much like that for this specific kind of linking. I prefer to only mark a link with the ID rather than its full title, and I use a script that converts these short links to full links automatically.