is it possible to set this up to exclude certain folders? i love it, but i have one big folder that i don’t need to index. thanks for the great plugin!
1 Like
Hi @jdr ,
That’s a great idea!
Currently it’s not supported, but I’m glad to implement it soon!
1 Like
Hi @oash !
thanks for thinking on the improvements.Here are my thoughts:
- I’m afraid the absolute paths are mandatory, othervise if you have two folders with the same name placed in different folders, their link would point to the same node in the graph view.
- Yes, the index notes could be excluded, i add it as a feature request.
- Templates for index notes are under development, they will resolve the case you raised I think.
Thank you very much, i can move forward with the implementation!
I’ll keep you posted.
1 Like
Thank you for the response! 2 and 3 sound amazing, especially the templates!
Maybe for 1 the link could be styled as:
[[subfolder/noteName.md|noteName]]
%% displays a link as "noteName" %%
to target this issue? I think adding a pipe + filename with stripped extension and path should be a simple fix!
Looking forward to seeing your work, I just watch the GitHub repo.
Cheers.
Aham, okok, but what happens if there are FolderA and FolderB with the same subfolder and the same note within?
I think both index file woul contain the same link: [[subfolder/noteName.md|noteName]] , which would be one node in the graph view.
Or not, what do you think?
Summary:
They wouldn’t be one node on the graph, no. The graph displays nodes based on the note filename, excluding the path and extension. Even if n notes have identical names but different folders, there will be n nodes in the graph with identical names, not one node representing all of them.
Situation 1:
Root folder TestFolder, with 2 subfolders Subfolder 1 and Subfolder 2 and each with Note1.md.
Here are some examples:
Example 1, what I’m suggesting:
Index of Test Folder:
[[Test Folder/Subfolder 1/Note1.md|Note1]]
[[Test Folder/Subfolder 2/Note1.md|Note1]]
Example 2, the current situation in Zoottelkeeper:
Index of Test Folder:
[[Test Folder/Subfolder 1/Note1.md]]
[[Test Folder/Subfolder 2/Note1.md]]
Example 3, different note display names:
Index of Test Folder:
[[Test Folder/Subfolder 1/Note1.md|foo]]
[[Test Folder/Subfolder 2/Note1.md|bar]]
As you can see, all 3 graphs are identical, the name of the node in the graph depends only on the filename of the note, excluding the extension and path. So even the current situation in Zoottelkeeper does not prevent this problem.
This is why I never have multiple notes with identical names under different folders. All my notes have different names, but it’s a preference thing. It keeps the graphs cleaner.
Situation 2
Root folders Folder A and Folder B, each with subfolder subfolder and each with note Note1.md
Example 1, what I’m suggesting
Folder A Index
[[Folder A/Subfolder/Note1|Note1]]
Folder B Index
[[Folder B/Subfolder/Note1|Note1]]
Example 2, the current situation in Zoottelkeeper
Folder A Index
[[Folder A/Subfolder/Note1]]
Folder B Index
[[Folder B/Subfolder/Note1]]
Example 3, different note display names
Folder A Index
[[Folder A/Subfolder/Note1|foo]]
Folder B Index
[[Folder B/Subfolder/Note1|bar]]
As you can see, it’s the same as situation 1 above.
Conclusion
It makes perfect sense to display notes in the index as
[[folder/subfolder/noteName.md|noteName]]
since it doesn’t affect the graph view, and the only side effect is making things prettier.
Sorry for the very long comment 
1 Like
Hi @oash !
Huh, thanks for the detailed insights! During I tried it by myself I realized for what I had a feeling that it won’t work for Zoottelkeeper.
The links with pipe works perfectly on files, but not for links without real files, e.g. virtual links. And as Zoottelkeeper connects folders together using virtual links, it will go wrong, a relative [[subFolder]] will point to the same virtual entity.
So, my suggestion would be to have an option to use relative paths for files only, and in this case - similarly to the absolute paths- the folder links should be absolute paths.
That would be a win-win scenario i think.
1 Like
That sounds great! My 6 examples missed virtual links
I just played around with the folder links for the past 30 minutes and I think I understand their purpose. Pretty smart!
For example, let’s say I have this folder structure:
root/
├── subfolderA/
│ ├── Note1.md
│ ├── Note2.md
├── subfolderB/
│ ├── Note1.md
│ └── Note2.md
root2/
├── subfolderA/
│ ├── Note1.md
│ ├── Note2.md
├── subfolderB/
│ ├── Note1.md
│ └── Note2.md
when Zoottelkeeper runs, we end up with:
root/
│ ├── _index_of_root.md
├── subfolderA/
│ ├── _index_of_subfolderA.md
│ ├── Note1.md
│ ├── Note2.md
├── subfolderB/
│ ├── _index_of_subfolderB.md
│ ├── Note1.md
│ └── Note2.md
root2/
│ ├── _index_of_root2.md
├── subfolderA/
│ ├── _index_of_subfolderA.md
│ ├── Note1.md
│ ├── Note2.md
├── subfolderB/
│ ├── _index_of_subfolderB.md
│ ├── Note1.md
│ └── Note2.md
Now I went into every one of the six index notes and added a pipe to ALL the links, real and virtual. For example,
_index_of_root.md
[[root/subfolderA|subfolderA]]
[[root/subfolderB|subfolderB]]
[[root/_index_of_root.md|_index_of_root]]
[[root|root]]
_index_of_root2.md
[[root2/subfolderA|subfolderA]]
[[root2/subfolderB|subfolderB]]
[[root2/_index_of_root2.md|_index_of_root2.md]]
[[root2|root2]]
and similarly for the indices of the subfolders. You see there are two separate nodes for subfolderA, titled by their path (root vs root2) and similarly for subfolderB.
Here is the local graph for _index_of_root2.md
So I think if you add a toggle (i.e. let the user select) to use pipes, it would work great for both virtual AND real links! And I think it’s the easiest to implement programmatically since you don’t have to figure out whether something is a file or a folder , just add a pipe to everything.
I think another option that would make sense for people who use Obsidian Publish is a toggle to turn off folder/virtual links. They look great in graph view in the app since you can control depth, but on Obsidian publish they 1. lead nowhere and 2. aren’t useful on the graph view since it only shows a depth 1 local view.
Again, I appreciate all your work on this amazing plugin, I hope I can keep helping in any way possible. Might be time to learn JavaScript .
2 Likes
Beside of this feat. I would consider to make the index files plain content to be simpler by having an option to push relative paths on where it makes sense.
But anyway, I think now I have a clear picture about this feature request, thanks a lot, I really appreciate it @oash !
I’ll find the time to implement it during the next week.
2 Likes
Is there any chance that you have a walk through video explaining more of the workflow. I enjoy the LYT methods, and have seen some of his stuff, but trying to wrap my head around this plugin a bit more
1 Like
Good point! Sure sure, I’ll add it to its github readme.
Dear Akos, I have a question about your excellent plugin.
I noticed from the explanation visible on your GitHub page that there should be the possibility to hide the file path showing only the files themselves so that the readability of the links is better. However, I do not find the option on the plugin settings page under the general setting. Is it normal??
Thanks for your help.
1 Like
Hi @lucass !
Opps, nope, it’s not normal, but the reason is even trickier. 
This feature was planned to be introduced among others as a batch, but I convinced the contributor on that it cannot be implemented as it is, because it may cause mixing the note references. So we excluded this feature, but, unfortunately we left the feat. in the description.
But! When you raised this issue, I rechecked the logic, and I recalled an idea raised here, that at most we could support the resolution of the .md extensions from the files, and to show simple links in the Preview (so in Edit mode you still see absolute paths to the files within the index file). So I reimplemented this feature, and I’m planning to release a new version soon.
I keep you posted on the updates.
Hi @lucass ,
I released a new version, 0.9.0 that contains the feature of cleaning paths in preview mode. Feel free to give it a try.
Thank you for raising this up!
Dear Akos,
many thanks for your answer and for the new version of the plugin you released. From my point of view, in this way, the lists of links are more actionable and usable.
I take advantage of your kindness to cover another point related to the plugin.
Basically, whenever I write a note implying some attachment I am used to turning it into a folder note to keep all the attachments together with their parent note within the same folder. However, if I use the plugin, I have to duplicate the note to do so. Indeed, when I move the folder note around the file tree and the index of links is affected by this move the content of the note is completely erased by the plugin which recreates a new index based on the new position of the note within the file tree.
I wonder if there is a solution to make the note where the plugin creates and keeps update the index writable without losing the note content if the note changes its position within the file tree.
Otherwise, if I have a folder for each note I have to create a folder note for the index of links and another one for writing the stuff. I know it is not a big issue, but it would be more convenient to get the possibility to write directly on the folder note without having the content deleted if the note is moved to another folder.
Thanks for your help.
I’m sorry, I lost your thinking, could you please demonstrate the situation and the desired behavior?
Yes, for sure, sorry if I explained my thought in a manner not enough clear.
The aspect I’d like to point out is that the index note generated by the plugin is not usable for writing any content which is different from the index as such, because the plugin deletes whatever is handwritten when it has to update the index.
Moving to an example, the scenario is the following.
I set the plugin choosing to use the same name for the index file and for its folder, so I will have a file tree appearing like this.
Folder A
Index file of Folder A
Folder A1
Index file of Folder A1
Folder A1.1.
Index file of Folder A1.1.
Attachment 1
Attachment 2
Folder A1.2.
Index file of folder A1.2.
Attachment 1
Attachment 2
This is the way how the file tree appears using the plugin. However, if I need to add some content to the index file notes I can’t because the plugin deleted the content when I move the index files note through the file tree. Therefore the structure needed to add some handwritten content to a note required the creation of another note where write the content. Hence I will have a situation as follow.
Folder A
Index file of Folder A
Folder A1
Index file of Folder A1
Folder A1.1.
Index file of Folder A1.1.
Note A1.1.
Attachment 1
Attachment 2
Folder A1.2.
Index file of folder A1.2.
Note A1.2.
Attachment 1
Attachment 2
Basically when I use a folder containing only one note with its attachment instead of a list of notes, it would make sense to have the possibility to write directly on the index note below the index generated by the plugin rather then to create another note for the specific purpose to include some text.
So, the plugin works perfectly if i have:
Folder A
Index note of Folder A
Note A1
Note A2
Note A3
Excetera…
But, if I have manage a situation like this
Folder A
Index note of Folder A
Note A
Attachment 1
Attachment 2
Attachment 3
It would make sense to write the content of Note A directly on the Index note of Folder A without creating another note for this purpose, but if i write something on the index note it is erased when I move the note and the index is updated. My perspective only follows a principle of optimization of the containers of information avoiding creating too many notes when it could be avoided.
I do not know if it is possible, but It would be fantastic to get the possibility to write directly on the index note making the plugin not delete the handwritten text when it has to update the index. Maybe it is possible to put the index below a heading preserving the rest of the note, so that only the index under the heading is updated while the rest of the index note is kept the same.
Having said this, if you can do something towards this behaviour of the plugin I will appreciate it a lot, otherwise, I think in any case your plugin is extremely smart and I will use it anyhow.
Many thanks and sorry if I have written so much.
1 Like
Oh, thank you for the clarification, now I get it.
What if we introduce two placeholders within the index file like:
%% <placeholder_of_index_content_begin> %% and
%% <placeholder_of_index_content_end> %%, and put the index file content (I mean the links to the notes of the folder) between them?
In this case, anything is written outside of these placeholders won’t be removed by the plugin. And if we use %%, the placeholder will be recognized as a comment, so it won’t be shown in the preview.
How about this?
It seems to me that this could be a perfect solution. Many thanks for this idea.
Do you think automatically including these placeholders in the plugin rewriting it (sorry but my programming knowledge are really limited and I don’t guess which is the procedure to follow) or it is something that I have to do by my own simply copying and pasting the placeholder you suggested above and below the generated index?
Thanks again!
nopenope, no manual task to do, this placeholder-stuff should be implemented in the plugin, i’ll create an issue about this on github, and i’ll develop it soon. i keep you updated on the progress.