#16

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
#17

That sounds great! My 6 examples missed virtual links :smiley:

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

CleanShot 2021-06-25 at 15.29.53@2x
CleanShot 2021-06-25 at 15.29.53@2x2052×806 66.1 KB

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 :smiley:, 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 :smiley:.

2 Likes
#18

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
#19

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
#20

Good point! Sure sure, I’ll add it to its github readme.

#21

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
#22

Hi @lucass !
Opps, nope, it’s not normal, but the reason is even trickier. :slight_smile:
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.

#23

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!

#24

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.

#25

I’m sorry, I lost your thinking, could you please demonstrate the situation and the desired behavior?

#26

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
#27

Oh, thank you for the clarification, now I get it. :slight_smile:
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?

#28

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!

#29

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.

#30

Ok, I will wait to hearing from you. For now, again, many thanks. In my humble opinion the plugin modified in this way will be a real game changer.

1 Like
#31

Hey Akos, today I updated the plugin and I found what you released. So far I only took a rapid look at the new function but it seems to work perfectly.
Many thanks for your work! This dramatically changes my workflow. On the one hand, it is possible to have a structure that is consistently updated; on the other hand, the nodes of this structure, represented by index notes, are no more only containers for links but may be used as notes as such.
Zoottelkeeper makes Obsidian extremely more fluid and powerful, and it optimises the functionalities of note folder autorename and folder note plugins if used along with them.
Really thanks again.

#32

Thank you for such a clever plugin. To date I have relied on using folder much like I always have in file explorer and OneNote. As I transition all note taking to Obsidian I’m considering the application of TOC notes in stead of or possible in combination with high level folders. I have tried excluding folders using that feature but it appears that I am not referencing the absolute path correctly, could you please provide an example of how I would write the path?

Thanks!

1 Like
#33

Let me say that this implementation is amazing. All that matters is automating work to be able to dedicate more fully to the knowledge itself, and with this you achieved it. I have tested the plugin on a ~33 Gb vault with ~20,000 folders (at least one note inside each folder, also images, videos, pdfs, 3d models in OBJ, etc.) and it runs great. The plugin was able to generate all the indexes, and it structured the Graph View quite well.

On the other hand, there is a warning: it is highly complex to configure the plugin to create indexes in certain folders and to exclude other folders. That is not working well at all. It’s not clear how the file paths should be placed, I tried many different combinations and none worked. When trying to delete the indexes, they are generated again. If you want a plugin that creates indexes on certain folders and not on others, then this alternative is still raw and needs participants to improve it. Also, it’s not clear how to implement a template over the indexes (e.g., for tags) if you don’t use the ‘templater’ plugin and you are using only the ‘templates’ core plugin. I wish I knew how to program, I would lend you a hand without hesitation. Excellent work!

2 Likes
#34

I forgot it. Last but not least: as soon as you enable the plugin and click on the ‘create indexes’ button (or something like that) it starts running immediately and generates all the index notes inside each folder. This is not clear in the documentation. You have to carefully select the name that the indexes will have, since if you have a note that is called exactly the same as its containing folder, I assume that it can be erased (I’m not sure about this, it would be great if it was clarified here ). I recommend making a good backup before running this gem (just in case).

1 Like
#35

Hi Akos,

Thanks a lot for the plugin. I was fiddling around with it for the past couple of hours in my vault and I noticed something which might also be an option. At the moment, the links generated by the Zoottelkeeper is in format like this → [[wikilinks]]. This is normally no issue using the plugin when I’m working in the Obsidian. But at the same time I’m using version control (GitHub) to store my system. As you probably know Github’s interface only renders the traditional Markdown links such as this → [github](https://github.com)

Is it possibly to give the option to the user to change the link formatting between wikilinks and traditional markdown? Like the one which Obsidian has already built-in.

Thanks a lot again for this great plugin. It saves a lot of time!