# Writing index notes (for your saved searches)

edited October 2017

When you update to v0.4.2 today, you may notice this in the release notes:

• Changed: Invoking a search using a saved search now auto-selects a matching note by the same rules a manual search would, so you can write index notes for your saved searches.

This could become an interesting convention/trick and I'm going to experiment with it myself.

Example:

1. Create a filter, pardon, saved search, that searches for "#zettelkasten" only;
2. write a note titled "#zettelkasten" and make it a curated overview about the topic;
3. invoke the saved search -- the curated overview note shows automatically.

As of today, this trick will be more useful for temporary projects than everlasting overviews, because the ID scheme we encourage you to adopt is not compatible with these index notes.

If you keep a note around, it should have an ID so you can link to it. This is useful for curated overviews, too. A topic overview should be a regular Zettel note. (Temporary notes don't need to have an ID; they either get discarded or become permanent by renaming to include an ID.)

When you want to assign the overview note's file called #zettelkasten.txt an ID, you cannot prepend the ID to the file name like we suggest -- or the auto-selection trick won't work. Instead, you have to put the ID inside the note only or at the end of the filename. That's odd.

So maybe the auto-selection feature should also support begin matching at the text part of a file name, i.e. skip the numerical ID part in 201710041209 #zettelkasten.txt. We will have to test how that feels in daily work, once ID-awareness is included in the app. (See @dbarends request: https://forum.zettelkasten.de/discussion/13/request-ignoring-the-id-in-the-title-when-searching)

Have fun!

-- Christian

Post edited by ctietze on

Author at Zettelkasten.de • https://christiantietze.de/

• I'd like to suggest that ID-awareness would allow the user to decide (in app's preferences) where to put the ID (beginning -- or end -- of the file name, or in MMD metadata format, such as UID : 20171010_221659) as well as the format of the ID itself.

I don't have a clue how complicated that could be though.
Does this sound feasible ?

• Me neither, I'll have to test if finding arbitrary ID patterns is fast enough -- and respects Markdown, like code blocks, so that you can write notes that talk about IDs without hassle.

Author at Zettelkasten.de • https://christiantietze.de/

• I'm not sure exactly what you have in mind for the Archive's planned ID awareness, but I hope I'm not alone in preferring to keep the ID separate from the note title and filename. I'd request that you not make any major functionality dependent on having the ID in the title/filename.

• There are a couple of possible things this can relate to, like:

• recognizing the ID part of a file name and producing search suggestions that focuses on the textual non-ID-portion, too
• generating a note header with a configurable ID generation algorithm

We’ll discuss and test this more thoroughly when I’m done with all the other stuff and then find out experimentally what works best and how users can properly configure this to their workflows. I’ll take note of your request, too

Author at Zettelkasten.de • https://christiantietze.de/

• @ctietze: I like your approach

Kind regards,
Dick Barends

• This is my current approach to the question:

Do I really need an ID for a Zettel? I like to see TEXT in my file names (which makes them start talking to me), so I get a quick idea what a certain Zettel is about. IDs seem too abstract to me. That said I don't see a need for IDs.

An advantage for IDs I can see when you need to spot out when exactly you've written your note (if you use the timestamp as an ID). But apart from that?
Another argument could be that using IDs you never ever will have double note titles. But this won't happen with my ZettelKasten containing around 2k Zettel now. I roughly know what my Zettel are about - and if I am not sure when creating a new Zettel a quick search will show me the respective existing Zettel to avoid double title creation.

A new part of my Zettelkasten will be my entomological data (yes, crazy enough I decided to mix them all into my existing Zettelkasten) I now add bit by bit; since biological taxonomy is about unique names for unique species there never can be double entries. No need for IDs here too.

Maybe I just cannot see the real need for unique IDs - you can tell me to open my eyes ;-)

• Or to put it this way:
TA is able to work with Zettel a bit like a relational database, that's what makes it so strong.

Let's say we have a Zettel called

Heidegger's empty total abstractions

Does it make sense to add a timestamp?

201801231551 Heidegger's empty total abstractions

In my POV now we just made the UID redundant. Not the best idea for a relational data structure.

Ok, let's say I want to always retrace when a Zettel was written (for what reasons ever). Then an UID as a timestamp could make sense. So, our Zettel now will be:

201801231551

If you can live with this, ok. I cannot. How do I get this Zettel via search? Hm, maybe I type in 'Heidegger' or 'abstraction'. Possible that I will get something like this in the search results:

201601231522
201601232351
201701211511
201704222451
201762312351

For me this is totally useless. I need to see text to decide quickly, which Zettel I need to open instead of clicking through all the results.

You may say that this could be solved by Zettel with precise tags. Maybe. But if only using text for the Zettel title (i.e. file names) I even do not need tags (and if - definitely less). Advantage.

• @ChrisJohnson said:
Maybe I just cannot see the real need for unique IDs - you can tell me to open my eyes ;-)

Since you kinda ask for it, here's how I make great use of UIDs.
First and foremost, I'm like you...

@ChrisJohnson said:
I like to see TEXT in my file names (which makes them start talking to me), so I get a quick idea what a certain Zettel is about.

...and for that very reason, I generally don't put UID in the file name but rather in MMD header (exceptions on this further down the page). This method retains information while keeping it out of my way.

But why use UIDs in the first place ?

For two reasons, mainly.

The small one : to have a record of when the file was created (because file metadata as seen in the Finder can get lost, modified or corrupted).

And the big one : to link to stuff, either from other notes in my archive or from outside of it.

If I need to reference a note, I make sure to include its UID in wikiLink format, like this [[20180210_232732]]. Even if the file gets renamed or moved somewhere else, the ID remains untouched and the "link" is still valid.

This is incredibly efficient. Go try a search on the ZK forum for that string and sure enough, it will bring up this post, and only this one (as long as I don't get quoted somewhere else).

If I want to point to a specific paragraph in a longer document, I sometimes add a "bookmark", hidden in HTML comment, like this <!-- ^20180210_232812 -->. The ^ symbol, inspired by footnote syntax from Markdown, indicates me that something else points here and that this ID is not related to the current text but to that something else.

If I add some information to an existing note, I often place marker, like this <!-- +20180210_222651 -->. The + prefix denote addition and the ID itself indicates when it was made. Plus it can be referenced from elsewhere.

Now why use timestamps ? Because they :

• are unique by design (I see them as serial numbers for my notes),
• are quick'n'easy to create (thanks to aText and the like),
• embed some metadata right into the file.

UIDs are widely used by many apps to create links between elements. Be it Bear, Ulysses, Quiver or Boostnotes. The downside of their UIDs though, is that they look something like this 39EC600C-ADC4-43FF-93EC-54FA5B55F8FB-57063-0000655AA2015F39 (actual ID from Bear) which, funny enough, reminds some activation code from my old days on Windows XP. Despite being funny though, this string on its own tells me nothing. That's why I settled on creating my own IDs.

That, in my view, is the beauty of a system relying on files and folders rather a database. You can bend it to your will and use (or not) IDs in the format you like.

Of course, this goes beyond The Archive. As I said earlier, I add an ID to everything I create (in MultiMarkdown metadata header) or collect (append to file name). If I need to reference a PDF file, it will go like this : "For more on this, see dishwasher manual >20180210_230645". Surrounding context will be enough to know what this ID is about and Spotlight will bring up the file in seconds. The > symbols, again inspired by Markdown, reminds me of an arrow that says "go look at this".

Phew ! 600 words down the page, I hope I haven't bored you to death. May you find at least some inspiration for your own workflow.

Cheers.

• edited February 2018

Thanks @maclm for your detailed response!

@maclm said:

But why use UIDs in the first place ?

For two reasons, mainly.

The small one : to have a record of when the file was created (because file metadata as seen in the Finder can get lost, modified or corrupted).

Yup, if (!) needed that's a good way to do it!

@maclm said:
And the big one : to link to stuff, either from other notes in my archive or from outside of it.

If I need to reference a note, I make sure to include its UID in wikiLink format, like this [[20180210_232732]]. Even if the file gets renamed or moved somewhere else, the ID remains untouched and the "link" is still valid.

That is a good point: it's possible to change the file name without changing any links to it. That's why I requested a "rename all links when renaming a Zettel's title" for TA.
Since I only want to do ALL my writing work in ONE app (I'm more and more sure that it will be TA), I then do not need UIDs for that purpose anymore. And I do want to use ONE app only, I'm tired of switching from here to there, because this app has what that don't and vice versa...

@maclm said:
That, in my view, is the beauty of a system relying on files and folders rather a database. You can bend it to your will and use (or not) IDs in the format you like.

D'accord! I just transfer a whole database into text files now just because of that...

@maclm said:
If I need to reference a PDF file, it will go like this : "For more on this, > see dishwasher manual >20180210_230645".

So - as I don't use UIDs, I just can do [[dishwasher manual]].

@maclm said:
Surrounding context will be enough to know what this ID is about...

Exactly. But not using UIDs can save work here: I have to type less plus I can see directly what's the link about. No surrounding text needed. Quod erat demonstrandum ;-)
And surrounding context in most cases only lets you GUESS what the exact content of a linked file could be... That's too dim for me.

@maclm said:
...and Spotlight will bring up the file in seconds.

As I said above - I do not like to switch apps when working on text, this for me is terribly distracting. I need ONE workbench. When I need to ask Spotlight - my text file system is not good enough...
BTW: That's why I put ALL files I am daily working on and with together in ONE folder (for me it's: scientific work for my job, entomological data, botanical data, general information, literary texts, journal etc. ) - my Zettelkasten!

Anyway, I don't say that using UIDs is worthless (as you showed it's not), I only say that for my workflow it's redundant and not needed. And - if someone wants to start with a Zettelkasten - that it will be good to think before, if UIDs are really needed.

Post edited by ChrisJohnson on
• edited February 2018

@maclm said:
...and for that very reason, I generally don't put UID in the file name but rather in MMD header (exceptions on this further down the page). This method retains information while keeping it out of my way.
...
If I need to reference a note, I make sure to include its UID in wikiLink format, like this [[20180210_232732]]. Even if the file gets renamed or moved somewhere else, the ID remains untouched and the "link" is still valid.

I'm confused: When you click on a link in the Archive, the archive makes the text of the link the active search. In addition, if the link text corresponds to the prefix of a file name, the Archive opens that file. So if you don't use the UIDs as the first thing in your file name, how do your links work? It seems like with your system this link would just give you a list of all files that contain the string "20180210_232732", which includes the file and all files that contain links to it, and that you would then have to further select the intended file from that list before you can view and edit that file.

What am I missing?

• edited February 2018

@galen

That is the reason I put the ID everywhere:

1. It allows for apps to search for them just in the title (e.g. Dropbox search)
2. When search done in The Archive putting the ID first makes the searched file displayed first.

The reason for putting the ID in the title and in the content of the file is to create redundancy to make use of other apps. Not all apps share all features. With redundancy you play safe. Sure, THE ARCHIVE IS THE BEST APP OF ALL TIME AND POSSIBLE WORLDS ( ) but what if you want to change and make use of a search that only searches in the titles?

Safety first.

EDIT II: When you put the ID first in the file name you can use any file browsing feature to sort you notes if you want by date.

Post edited by sfast on

I am a Zettler

• edited February 2018

@sfast said:

1. When search done in The Archive putting the ID first makes the searched file displayed first.

Yes, it's this feature that makes starting filenames with the UID completely essential to the proper functioning of a zettelkasten, in my view.

@ChrisJohnson, I think there might be some misunderstanding on of the issue of redundancy. Redundancy is a problem in a relational database, as you mention, but a zettelkasten is not a relational database — it is much more free-form and relies on a very simple query engine, and is thus (in my experience) usually quite explicit in its coding of connections between notes. It's very common for me to create backlinks to an index note in every note mentioned in the index note. This is redundant information, yes, but my goal is not to represent my web of knowledge in the most compact form possible — my goal is to make my web of knowledge easy to explore quickly.

As another example, I use the UID of a zettel at least twice in every zettel: once in the filename so that [[UID]] links bring me directly to that note (a feature of The Archive and nvALT), and again in the title to allow for easy link creation. So a zettel with filename 201802111047 Example Zettel would have this as its first line:

Example Zettel[[201802111047]]

This allows me to quickly copy and paste the first line of a zettel to create a direct link to that zettel. Sure the information is redundant, but the redundancy serves the purpose of speeding up link creation.

The system you describe is vulnerable to link rot if you ever decide to change the titles of your notes, which requires a heavy-duty solution (namely your "rename all links when renaming a Zettel's title" feature request) that goes against the "Software Agnostic Programming" ethos of The Archive's developers. Your system is also subject to confusion if two notes have very similar titles, so you need some convention to deal with that. With UIDs those problems do not need to be solved because they do not arise.

Christian and Sascha are young guys, but it's almost certain that they have thought about this problem far more than you have, and I would recommend that you follow their system until you find a specific functional (as opposed to aesthetic) reason to deviate from it. Your writing sounds to me as if you do not understand the problem well enough to deviate wisely. And with more understanding, your aesthetics might change. (I personally find the UID system quite beautiful.)

Post edited by galen on
• edited February 2018

@galen said:
This allows me to quickly copy and paste the first line of a zettel to create a direct link to that zettel.

Same without UIDs.

@galen said:
The system you describe is vulnerable to link rot if you ever decide to change the titles of your notes, which requires a heavy-duty solution (namely your "rename all links when renaming a Zettel's title" feature request) that goes against the "Software Agnostic Programming" ethos of The Archive's developers.

True.

@galen said:
Your system is also subject to confusion if two notes have very similar titles, so you need some convention to deal with that. With UIDs those problems do not need to be solved because they do not arise.

Similar file names are not same file names. I cannot see the problem here. And if similar Zettel names may confuse UIDs cannot change this (if using the UID + text as file name; only using the UID as file name is not on option for me, as I described in a post above).

@galen said:
...until you find a functional (as opposed to aesthetic) reason to deviate from it...

Aesthetic reasons?

Post edited by ChrisJohnson on
• @galen said:
What am I missing?

Nothing (as far as I can tell).
My system is far from perfect and the approach @sfast suggests is way better.

Except for one thing : using Editorial on iOS, there is not enough room in the list to see the actual file name if it starts with the ID.

• edited February 2018

@ChrisJohnson said:

@galen said:
This allows me to quickly copy and paste the first line of a zettel to create a direct link to that zettel.

Same without UIDs.

I brought this up as an example of how redundant information in a zettelkasten can serve a good purpose, not to show that UIDs make it easier to create links with. In fact, it is more work to create links with UIDs, but the resulting zettelkasten is more robust. In my opinion this is a good tradeoff.

@galen said:
Your system is also subject to confusion if two notes have very similar titles, so you need some convention to deal with that. With UIDs those problems do not need to be solved because they do not arise.

Similar file names are not same file names. I cannot see the problem here. And if similar Zettel names may confuse UIDs cannot change this (if using the UID + text as file name; only using the UID as file name is not on option for me, as I described in a post above).

The issue is, if you are using The Archive or nvALT, you must use a unique prefix of the filename as your link text to guarantee that clicking on the link will bring you directly to the zettel, as opposed to just initiating a search. So you need some system in place that guarantees that every filename always has a unique prefix that is calculable at the time the zettel is created and that will remain unique, even as new zettels are added. E.g., you might have a zettel that contains

See [[Example Note 1]] for more about this.

which works fine until you add a note named Example Note 11. Then the link stops working. So adding a new zettel has non-local effects on the behavior of the zettelkasten. Because UIDs are guaranteed (by convention) to be unique prefixes of the filename, a link in the form of [[UID]] will never stop working as a result of adding a new zettel, whatever its name.

If you are ok dealing with links that once worked not working anymore, or have some other means of keeping links functional, then no worries. But this is a consideration when abandoning UIDs.

Also, UIDs allows links to act as quick references. For example, say we have a zettel named 201802111709 BK Econ _Wealth of Nations_ Connections to Modern Monetary Policy. I can link to it in passing like this:

As Smith makes very clear [[201802111709]], this is not a problem.

To my eye this is much cleaner than always using the entire filename, even if we forgo UIDs. I.e.,

As Smith makes very clear [[BK Econ _Wealth of Nations_ Connections to Modern Monetary Policy]], this is not a problem.

This is especially pertinent if you abstain from using tags by coding zettel content in filenames, as you implied you might do when you said

You may say that this could be solved by Zettel with precise tags. Maybe. But if only using text for the Zettel title (i.e. file names) I even do not need tags (and if - definitely less). Advantage.

since this will make filenames longer and link text more ungainly.

@galen said:
...until you find a functional (as opposed to aesthetic) reason to deviate from it...

Aesthetic reasons?

Your objections to UIDs so far seem rooted in your current personal aesthetics — e.g., not wanting to have zettels contain "redundant" information, not wanting to use non-link text to identify the link target, etc. — and not in their functional shortcomings — i.e., shortcomings that you have found after gaining some experience with using them in a sizable zettelkasten. This is not to dismiss aesthetic considerations, which are supremely important, but to simply encourage you to learn why the system was designed as it was before assuming you understand how it should change. What you have written clearly indicates that you have not grasped the advantages of using UIDs, or even how to use UIDs correctly. Until you understand how to use UIDs in a zettelkasten and what the advantage of doing so is, you are not qualified to argue that they should not be used.

Post edited by galen on
• @maclm said:

@galen said:
What am I missing?

Nothing (as far as I can tell).
My system is far from perfect and the approach @sfast suggests is way better.

Except for one thing : using Editorial on iOS, there is not enough room in the list to see the actual file name if it starts with the ID.

Ah yes, I've experienced this myself. I don't use iOS to interface with my zettelkasten except in emergencies, so this isn't a consideration for me. But if I used it more often I could see that it would be a big pain.

• If using synoptical Zettel titles - is it really necessary to change them later? When new aspects occur, it's a good idea to create a new Zettel.

If using an exact title, e.g. when dealing with taxonomical data (as I do), an UID prevents linking problems, if the taxon may change to a synonym (which means, the Zettel name will change).

Nevertheless, in that case now I have to change ALL links (in other Zettel) to the taxon, which became a synonym unless you only used the UID as the link, which exactly is what I do not find helpful in my workflow.

Example: Let's say my file is

2018021212H590213 Lucanus bicolor SAUNDERS (nec OLIVIER) 1839

Later I find out that this is not the current taxon anylonger but now a synonym. So, I will change it to

2018021212H590213 Odontolabis cuvera ssp. cuvera HOPE, 1842

As long as in all Zettel which will link to this Zettel I only used the

2018021212H590213

I am totally fine.

To use the UID only as the link doesn't always make sense. To know, what the link exactly is about, you have to click to see - which I find distracting. That's why I like to use the whole name. Now the UID becomes redundant, means an information without need here.
This has nothing to do with aesthetics, it's about function.

@galen
Maybe I missed something (definitely I'm not an 'expert'), maybe I didn't understand the UID concept fully - that's why I've thrown my hat into the discussion. Then one can show me, where I am wrong; that's totally fine. That's what discussions are for, aren't they? I am happy to learn. But there is definitely no need for unfriendly and snooty statements, whether I am qualified to join to argue or not. If you do not like 'unqualified' statements, just stop replying to.

• edited February 2018

@ChrisJohnson said:
If using synoptical Zettel titles - is it really necessary to change them later? When new aspects occur, it's a good idea to create a new Zettel.

I change filenames with some regularity, either to differentiate an old zettel from a new one with a similar name, or because I have adopted a new content-coding convention in the names. In a more mature system where conventions are completely settled, this would be less necessary, but I am still experimenting with how best to name notes.

If using an exact title, e.g. when dealing with taxonomical data (as I do), an UID prevents linking problems, if the taxon may change to a synonym (which means, the Zettel name will change).

Nevertheless, in that case now I have to change ALL links (in other Zettel) to the taxon,

Yes, this is what UIDs allow you to avoid.

which became a synonym unless you only used the UID as the link, which exactly is what I do not find helpful in my workflow.

I think this is because you're not yet using UIDs in an effective way. See below.

Example: Let's say my file is

2018021212H590213 Lucanus bicolor SAUNDERS (nec OLIVIER) 1839

Later I find out that this is not the current taxon anylonger but now a synonym. So, I will change it to

2018021212H590213 Odontolabis cuvera ssp. cuvera HOPE, 1842

As long as in all Zettel which will link to this Zettel I only used the

2018021212H590213

I am totally fine.

To use the UID only as the link doesn't always make sense. To know, what the link exactly is about, you have to click to see - which I find distracting.

You definitely don't want to have to click the link to find out what the note is about — I am fully with you there. But this is what contextual text around the link is for. UIDs allow you to separate link text from contextual text.

To follow your example, you could use 2018021212H590213 as the link text, and some form of the rest of the title as contextual text. For example,

This was some years before Lucanus bicolor[[2018021212H590213]] first showed up in western entomological taxonomies.

Here the link will always work even if the taxon changes, and you can supply as much or as little of the rest of the zettel title to indicate the contents of the link. After the taxon changes, you would most likely want to update the text, but here again you could tailor the contextual text as needed. E.g.,

This was some years before Odontolabis cuvera (formerly Lucanus bicolor)[[2018021212H590213]] first showed up in western entomological taxonomies.

And both of these are much easier on the eyes than

This was some years before [[Lucanus bicolor SAUNDERS (nec OLIVIER) 1839]] first showed up in western entomological taxonomies.

@galen
Maybe I missed something (definitely I'm not an 'expert'), maybe I didn't understand the UID concept fully - that's why I've thrown my hat into the discussion. Then one can show me, where I am wrong; that's totally fine. That's what discussions are for, aren't they? I am happy to learn. But there is definitely no need for unfriendly and snooty statements, whether I am qualified to join to argue or not. If you do not like 'unqualified' statements, just stop replying to.

Fair enough — apologies for my unpleasant tone. It sounds to me as if you have dismissed UIDs without first understanding them, but that is no reason for me to get snooty.

Post edited by galen on
• I think it is important to understand that starting file names with UIDs or not is not so much a question of right or wrong, but more one of specific tradeoffs that depend on your particular usage patterns.

If you, like me, regularly access your notes on an iPhone, then having a UID at the beginning of each file name is pretty much a deal breaker. Another significant disadvantage is that you lose the ability to instantly switch to notes that you know (the beginning of) the name of (e.g., whenever I want to look at my Regular Expressions cheat sheet, I just need to type "reg").

It is absolutely correct that link handling is more foolproof with UIDs, but if you rarely rename a note, it is also not a problem at all to do a quick batch search and replace for "[[Old Title]]" -> "[[New Title]]" in those cases. Furthermore, not having one note title be a complete subset of another one is also trivially easy to avoid.

So it is clear that starting file names with UIDs has both advantages and disadvantages. Instead of trying to argue whether the advantages outweigh the disadvantages or vice versa, maybe it would be more useful to think about how the advantages of both approaches could be combined.

Ideally, we would want the UID to not clog up the file name, but still be able to use it to link to a note directly and not just get a list of notes, which also includes all the notes that link to the original note. One way to accomplish this would be to include the UID together with a prefix in the note body, for example "ID:201802130850". The format of the internal links would remain "[[201802130850]]".

The obvious downside of this approach would be that, with the current version of The Archive, you would need to manually prepend "ID:" to the search string after clicking a link (and also hit Arrow Down to actually view the single remaining note). That would not be terribly convenient... unless The Archive had an option "[x] Prepend ____ whenever an internal link is clicked". Ideally, TA would also always show a note if it was the only remaining search result -- this would actually be a universally useful feature, especially when you use tags.

Maybe there are other ways to solve this problem, but implementing such a prepend option does not strike me as terribly difficult, and it would allow you to keep foolproof linking without all the disadvantages of starting file names with UIDs.

Fortunately, moving UIDs between file names and note bodies is very easy to do programmatically, so even if you already have a Zettelkasten with 3000 notes whose names start with UIDs, you could just use a short script to migrate them to the new format. The same holds true if you, for whatever reason, wanted to go back to file names starting with UIDs: All you would need to do is to run a simple script once.

If you like The Archive's "PrettyFunctional (Basic)" theme, consider upgrading to the "PrettyFunctional (Regular)" theme.

• Sorry if this has already been covered, but one thing that placing a UID at the beginning of the filename makes impossible is meaningfully sorting by name — which may not be canonical Zettelkasten practice, but can still be awfully useful.

(On the other hand, the current version of The Archive doesn't seem to offer any other option for sorting by creation date. @ctietze , would you please consider adding this? Maybe add a pop-up menu for sort order to the top of the note list column, and/or add it to a contextual menu in the note list?)

• edited February 2018

@Basil said:
Ideally, we would want the UID to not clog up the file name, but still be able to use it to link to a note directly and not just get a list of notes, which also includes all the notes that link to the original note. One way to accomplish this would be to include the UID together with a prefix in the note body, for example "ID:201802130850". The format of the internal links would remain "[[201802130850]]".

I've thought about adding prefix to distinguish the link from its target. But you're wright, that's a bit inconvenient, unless...

The Archive had an option "[x] Prepend ____ whenever an internal link is clicked". Ideally, TA would also always show a note if it was the only remaining search result -- this would actually be a universally useful feature, especially when you use tags.

Maybe there could be a specific URL scheme for this.
Since [[WikiLinks]] use thearchive://match/<TERM>, here's what comes to (my) mind :
thearchive://link/<TERM> could use @Basil suggestion "[x] Prepend ____" from the app preferences.

As an aside, I sometimes wish thearchive:// was shortened to ta://. Not sure how close that would come to what's considered bad practice though. (But there was nv:// in nvALT...)

Post edited by maclm on
• edited February 2018

@Eurobubba said:
On the other hand, the current version of The Archive doesn't seem to offer any other option for sorting by creation date.

Using View > Sort By we already have title and modification date. You're right that without ID in the filename, we can't have by creation date without resorting to the Finder or other external app (Leap comes to mind).

But that metadata can easily be corrupted or modified externally (Dropbox, iCloud...). I don't know for how long that would remain reliable. I see modification date as a live thing, thus more useful to me.

• Great stuff you come up here in the process! Could you also open new discussions with the requests so we can reference and discuss them outside this thread's context, too?

Author at Zettelkasten.de • https://christiantietze.de/

• ## IDs interfere with iOS

As a proud conscientious objector of smartphone usage with a strong believe and sense of mission I am happy for this additional feature of the IDs.

Seriously, I am wondering how you think the net benefit of a smartphone over a physical note book is.

## Tone of Writing

You guys came to a good solution on yourself. I just want to credit you for civil manners.

I am a Zettler

• @maclm said:
But that metadata can easily be corrupted or modified externally (Dropbox, iCloud...). I don't know for how long that would remain reliable. I see modification date as a live thing, thus more useful to me.

I'm not suggesting dropping sorting by modification date; I want all three sorting options (creation, modification, filename), plus UID as a separate metadata category from filename or creation date (no immediate use case, but I can imagine someday wanting to distinguish between the file as a filesystem object and the zettel as a zettelkasten object), and possibly others that I'm not thinking of right at this moment. While it's true that file creation date metadata is not absolutely reliable, that hardly means it's useless.