+1 I would appreciate if the graph view could toggle between the real file name as the node name and one, or any, of the following:
aliases: myalias (from the front matter yaml) title: mytitle (from the front matter yaml) # My H1 Title (actual, markdown title)`
I think my personal preference is aliases if there can be only one, as I currently use this to make UID links more friendly in all my notes, where I find title to be redundant as I always include a “# title” in my notes, and any given note will only ever have one “#” level heading. I am unsure if title: is used by any core functionality at this time, but I find it redundant. So aliases is just my selfish pick.
Any of these would potentially make the graph useful for those using meaningless UIDs in zettlekasten style.
Absolutely agree with that. For instance, through a setting could be used the first (or unique) alias to be shown at graph instead of UIDs And when alias is not present, then show UID (note name) as always.
BUT maybe using a Title field in YAML would add compatibility with Zettlr, for instance.
If I had to choose one, I would take Title method for compatibility aspects.
This is the only pending point that is stopping me to start dumping all my notes to Obsidian.
Show [first header found in a file] next-to an ID-only-filename
Add options to show [first header found in a file] [next-to or instead-of] a filename:
In top bars above the page, or in vertical bars in Andy Matuschak mode (plugin).
In File Explorer
In Graph View
list of ‟Starred” files
Position of the header might be limited to first line if unrestricted search for header in large files is infeasible.
purpose:
Allow naming files using only concise permanent ID,
while seeing (showing to user) up-to-date human readable description in all appropriate places.
consequences of not having titles in filename:
Edit filename any time using any software (not only Obsidian) without breaking links.
Avoid need to change all links when title is changed and therefore reduce number of versions created by automatic backup systems.
Eliminate risk of exceeded maximum length of a pathname in some file systems.
Title can contain characters not permitted in filename, including forward slash.
Make markdown more concise/readable by using [[ID|note title]] instead of [[ID note title|note title]].
Seconding on this, as already mentioned above my suggestion is to implement a title YAML tag to use in visualization-related scenarios instead of plain filenames. This solution is also compliant to ones adopted by other tools like pandoc and Zettlr, so it’s a step forward compatibility-wise too.
Plus, which YAML tags are supported should be documented in a dedicated page, maybe into an in-depth introduction about how front-matters work?
This would be really helpful! I use Zettelkasten IDs as file names in my vault. The introduction of aliases eased the pain of linking notes, but the graph and everything using file names as identifiers are still barely usable in this scenario.
Great suggestion. I’m Japanese, so I write the title of the note in Japanese.
However, I have concerns about the stability and flexibility of the file because the Japanese file names contain multiple bytes and contain NFD and NFC issues.
Being able to decouple the file name from the note title and attach a UID to the file name would eliminate these concerns.
That will be a great feature. For a Linux system, I prefer to follow “all lower case and underscore” as files’ name, while using H1 as a note’s title and link (so titles could include characters other than English characters).
@jMatsuzaki Please, do not forget to like the original post by pressing under it, since it is officially prefered method of voting according to FAQ.
quote:
Rather than posting
“+1” or “Agreed”,
use the Like button.
I’ve been thinking about this a bit, and I think the desktop app should mirror what Publish does.
Use the filename as the note’s display title
In desktop app, display file name at top of note i same size and position as an h1 in the document (this would mirror Publish and remove need for people to add their own titles)
Allow a display title attribute in YAML frontmatter where user can indicate a different display title (this would allow special characters, different formats, etc.)
Add display name at top of sidebar, so it’s clear what note you’re looking at
For the time being I would suggest following hint to access your note titles:
If you access your notes primarily through search (like I do), and use top-level headings for the note title, you can enter your search query in the Obsidian search field wrapped in parentheses and prefixed by a hash symbol:
# (one OR two)
If you use YAML front matter, just replace the hash symbol with title:
title: (one OR two)
Make sure the “Collapse results” search option is deactivated. Obsidian will show you list of matching file names together with the first matched line, which will be the note title.
@saf-dmitry great workaround in search. Thanks. Here is a modification:
“#” alone matches fragment identifiers in URLs so I match only # at line beginning.
Here is regex that matches and highlights whole title line: /^(#|title:) [^\n]*/ to be followed by search string.
The regex can be put in by text expander.
Below is AutoHotkey script that automatically writes the hotstring into search field after pressing Ctrl+Shift+F:
@malecjan Thank you for your suggestions. Of course, you are generally right suggesting a regex for more accurate matching of note titles to distinguish them from URL fragments or e.g., hashtags.
In my post I just silently assumed, that all of your notes have a title, and this title always comes as the first non-blank line. In this case there is no need to clutter search query with more complex regexes.
Generally speaking, this workaround will only work, if the first matched line in a note is a title line, otherwise you will not see it in the list of search results.
Please, consider complementary simple request that will make this one much more useful in the future:
By putting title directly in “title” field instead of “aliases” field, we will have it ready when this request is implemented.
When we will see titles daily, we will want them to match in quick switcher and in link suggestions.
“Title” field is well defined, manageable by plugins so in case of need we would be able ourselves to fill missing titles by data extracted from markdown by some plugin to satisfy diverse opinions for how exactly this request should behave (what data to show instead of filename)