You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue related to this other one, but I am opening a new one since this is more of a feature request, while the other one looks more like a bug to me.
I am now trying Memo since I believe it can support a workflow where my notes are organised in different unrelated folders across the filesystem, as opposed to pretty much all other apps I have tried which dictate or at the very least impose contraints on the notes folder structure.
What I want to achieve is being able put my notes wherever they belong on the file system, but still be able to link between different folders when I feel the need for it.
For those interested, (here there is a post about what I mean, and here a feature request for Obsidian to support something similar.
Thanks to VSCode multi-root workspaces, I can import different folders inside my workspace (regardless of where they are actually saved) and still be able to link notes freely between them as if they were all stored inside the same parent folder.
However, I believe Memo handling of the links should be evolved a bit to recognize and handle different type of links:
Internal links between notes that reside in the same root folder (same folder on the file system) should handled as they are now.
For links to notes (or resources) that reside in another root folder (which also have been imported into the workspace) autocompleting to a classic markdown link in the format [Note Name](../relative/path/between/notes/note.md) would come a long way. This way, as long as the relative path between folders is maintained, the links should still work.
A possibly even better approach would be to support some form of folder aliasing, similar to what described on this issue but for folders. This way, the link could look like [[folderAlias\NoteName]], with Memo keeping track that, for example, the "Work" folder alias points to C:\Work on my Work laptop and to \\WORKSHAREDFOLDER\Work when I am at home.
While Memo seem to do a great job as it it now, adding this type of "scattered folder" support would give it an edge over pretty much all other notes app I have tested so far.
The text was updated successfully, but these errors were encountered:
Hello,
This issue related to this other one, but I am opening a new one since this is more of a feature request, while the other one looks more like a bug to me.
I am now trying Memo since I believe it can support a workflow where my notes are organised in different unrelated folders across the filesystem, as opposed to pretty much all other apps I have tried which dictate or at the very least impose contraints on the notes folder structure.
What I want to achieve is being able put my notes wherever they belong on the file system, but still be able to link between different folders when I feel the need for it.
For those interested, (here there is a post about what I mean, and here a feature request for Obsidian to support something similar.
Thanks to VSCode multi-root workspaces, I can import different folders inside my workspace (regardless of where they are actually saved) and still be able to link notes freely between them as if they were all stored inside the same parent folder.
However, I believe Memo handling of the links should be evolved a bit to recognize and handle different type of links:
[Note Name](../relative/path/between/notes/note.md)
would come a long way. This way, as long as the relative path between folders is maintained, the links should still work.[[folderAlias\NoteName]]
, with Memo keeping track that, for example, the "Work" folder alias points toC:\Work
on my Work laptop and to\\WORKSHAREDFOLDER\Work
when I am at home.While Memo seem to do a great job as it it now, adding this type of "scattered folder" support would give it an edge over pretty much all other notes app I have tested so far.
The text was updated successfully, but these errors were encountered: