Non-unique titles and filename field

[rkp135]

Currently, the title field is also used by the app to determine the filename and the value of the field is the filename. This has the consequence that no two notes can have the same title. For some uses, having the same title on multiple notes can be very useful. For instance, if one is writing a journal which has multiple entries on different days with the same title which might describe an activity that one did. The list of notes could be sorted using Seq + Title and have the form of an outline where journal entries are nested under a note for each day. In this case, it is cleaner to have the title describe the activity even if it leads to duplication. Something like:
Feb 4
Hike in the woods
Feb 5
Hike in the woods

rather than having a number attached to the title on one of them.

A similar issue was discussed in this thread: Must note titles be unique within a collection?
There, the need was slightly different, but again related to trying to use Notenik like an outliner.

To address this use-case, I request the creation of an optional separate user-editable field, called “filename” for example, which if not empty, is used the way that the title currently is for the purposes of naming the file, and in Wikilinks to identify the file uniquely. The title field can then be used simply for the name displayed in the list and need not be unique anymore. If the “filename” field is empty (the default setting), the note would use the title as it currently does for naming and wikilinks as well as display in the list.
I realize that this would add some complexity to the app, however, arguably, since the default behavior would be the current one, the complexity would just be for advanced users.

Adding a separate field, say “list title” for the name of the note displayed in the list would be another possible solution, but I prefer the other one (“filename” field) because other note taking apps such as Obsidian use the title filed in the YAML front matter for display in lists as well and keeping the title for this purpose would lead to greater compatibility.

Hopefully, this won’t require a lot of coding!

[hbowie]

Thanks for the request!

I’m wondering whether it would be better to have a Collection Setting that allowed the user to pick from a set of algorithms to be used for formation of the filename and unique ID for each note in the collection.

I’ve had such an option in the back of my mind for quite a while, but was lacking a nudge to push me to pursue such a thing.

This strikes me as more useful than a separate field that the user would have to fill in each time they wanted to vary the Note’s ID from the simple title.

How would this sound?

[Malcolm]

If I’m understanding you correctly we could define the shape of the title using modifiers such as:

Title: =$title$= =$date$=
→ My New Post 2024-02-08

or

Title: =$title$= =$seq$=
→ My New Post 5_2

This suggestion would suit me.

[rkp135]

Indeed, this would be a great solution for the use case I presented and more convenient because, as you pointed out, it would save the user the work of finding a unique filename/Note ID. It would be nice to then also have an option for copying the wiki style link in the format: [[$title$ | $filename$]]

@Malcolm, I imagine that the idea is to have an option where the filename might be to choose from a list like the following.

Options for the Filename/Unique ID
Title (i.e., the title field value, which the App then ensures is not unique - this is the only current option)
Timestamp
Title & unique integer (allows titles to be non-unique by adding a digit to the filename but not to the title field value)
… other options

I imagine this would also work for you.

[hbowie]

What I’m thinking now is that each Collection would have an option to specify one auxiliary field to use in note identification, plus a note identification rule, with four possible values:

• Title Only
• Title before the Auxiliary Field
• Tile after the Auxiliary Field
• No title - Auxiliary Field Only

This would seem to provide enough flexibility.

How does this sound?

[rkp135]

Sounds great! I am excited to see how this turns out because I imagine it will open Notenik up to a number of new use cases in outlining, journals and databases.
The note identification rule will also be the rule for naming the note, right?

[Malcolm]

How is the auxiliary field populated? Do you have some examples to describe how we would use it?

[hbowie]

Check out the new beta to see how the UI might work. Look for the new ‘Note ID Config…’ item beneath the Collection menu.

There is no functionality associated with the UI yet, to be clear. So I’m only looking for feedback at this point on how you would change the Note ID configuration for a Collection.

[hbowie]

See the latest beta and let me know how it goes!

The version of the Knowledge Base accessible from within the app has details on the new feature!

Let me know if questions or problems.

[Malcolm]

I’m bumping into problems with autogenerated lookback links between collections. I have one collection that I used Note ID Config, as shown below. This collection contains the LINK field. A second collection contains the lookback field. The lookback links take me to the right collection but I rarely land on the correct note.

I’m not sure how much of this is a notenik problem and how much is being caused by me constantly changing things, especially in collections that are linked. I suspect that if I left things alone they would work.

[hbowie]

There’s a good chance this is a Notenik problem. Thanks for reporting. Let me look into it.

[hbowie]

Check out the 13-9-6 beta and let me know how this works. Thanks!