Preview doesn't work for vault referring to root directory of a Workspace

awidjaja commented 2 years ago

Please select the area your bug applies to. (Multiple selections are Possible. You can leave blank if you're not sure.)

[x] Workspace. VSCode workspace, vaults, Intellisense/autocomplete, Dendron settings
[ ] Lookup. Dendron's Lookup Command
[x] Views. Dendron Preview, Tree View, Side Panels in the UI
[ ] Schema. Dendron Schemas
[ ] Pod. Data import from / export to Dendron
[ ] Publish. External Site Publish
[ ] Markdown. Markdown features, such as syntax support and features

Describe the bug

Preview doesn't render the document when the vault was created againt the root directory of the Workspace. Other functionalities seem to work.

To Reproduce

Steps to reproduce the behavior:

Initialize dendron code workspace
Add new local Vault and enter . as the path
Enter vault name
Open root
Click dendron preview
Preview will show blank document.

Expected behavior

Preview to render the root and new note in the vault.

Screenshots

If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information)

OS: [Windows - Ubuntu WSL]
Browser: [electron, chrome]
Version: [dendron v0.73.1]

Additional context

This Workspace is used only for notes (.md files) and sync to a git repo (with update access given to specific users that will protect other vaults from being updated by unintended users) .

The vault will be added in a bigger Workspace as a remote vault in a multi-vault setting.

The bigger Workspace are synced to a main gitlab repository, so it is essential to limit the folder depth of the vault to just one in order to avoid unnecessary folder level appear in the directory list.

Eg. instead of /my-vault/vault/home.md and /other-vault/vault/home.md, it should be /my-vault/home.md and other-vault/home.md.

Please fix the preview to be able to render the notes in this scenario.

Note: steps edited to make it more clear.

Dendron Log file

hikchoi commented 2 years ago

I'm not sure if I'm understanding your issue correctly. The path you enter for the workspace initialization should be an absolute path and . will not be accepted by the input box

Can you please clarify this part so I can properly diagnose this issue?

awidjaja commented 2 years ago

No, there are two main steps. First is to initialize the code workspace, and one would enter the full path. The result:

Then follow the step 2 onwards (vault add - local) to create new vault.

hikchoi commented 2 years ago

I apologize. I misread that.

This behavior is by design. When in a workspace, we assume the vault to be in it's own directory. That vault could itself be a git repository which could then be added to another vault as a remote vault with the vault add command if you provide the git url to it.

awidjaja commented 2 years ago

Isn't dendron allow remote multi-vault scenario?

Let me try to ellaborate: I created a code workspace and create multi-vault inside the workspace. Let's assume I created exactly the same as the example.

└── Dendron
    |── .git
    |── dendron.code-workspace
    |── dendron.yml
    |── pods
    |── docs
    ├── vault1
    │   |── .git
    │   ├── foo.md
    │   └── foo.two.md
    └── vault2
        |── .git
        ├── foo.md
        └── foo.one.md

User1 is given access to vault1 repository & User2 is given access to vault2 repository

User 1 wants to edit the documents under vault1 in his pc using vscode. He installed dendron extension and git clone vault1 repository. As expected, it doesn't work (failure #1).

After tinkering quiet sometimes, he realized that it is just standard git repository created by dendron in the multi-vault scenario, blaming himself for assuming (not so unreasonable) that dendron will create the remote workspace as a workable component of the main workspace, he initialize a native dendron workspace. This time, unexpectedly, dendron wouldn't render the existing notes (failure #2). He again wrongly assumed that add native workspace functionality just work.

After another sometimes, he realize that dendron created a folder named vault which he doesn't like, but he can't find a way to rename it. He did think, what if i just surrender and move all the notes into this strange vault and just accept the strange name. But the he realized that he doesn't own the vault and doing so will break the main workspace and he still want to keep his job.

After another few hours of frustration, he remember there is another option to initialize workspace. He deleted everything and start over. This time he initialize a code workspace. Again this created the not-to-be-renamed vault folder, but at least now most dendron functionalities seems to work except rendering the existing notes (failure #3). It's a progress no matter how small! He learned his lesson and spend hours reading the dendron website again and again, reading all possible hidden instructions there to make sure he won't make another silly but not so unreasonable, assumptions.

Now he feels more confident and execute add vault command. His intension was to include the existing notes into the workspace vault. There wasn't any instruction not-to-do-this in the entire dendron website so he again assume it will just work. He entered the root directory (.) where the existing dendron notes and the workspace file were and created a vault with the name he like. It seems to work! But, every dendron functionalities work now, except that dendron preview still insist on rendering a blank page for any dendron notes (failure #5). Only this single damn thing doesn't work. OK, now it's time to give up! But wait, maybe those helpful guys at dendron could help.

He created an issue in dendron repository and after sometimes, he was told that this is intentional.
Is it the time to tell boss to stop thinking of using dendron, except for his personal notes? Or would you reconsider of somehow removing this intentional hassle?

awidjaja commented 2 years ago

My dendron extension was just updated to v0.74.0.

I see this good intention:

We make managing general knowledge like managing code and your PKM like an IDE.

Developer Centric Dendron aims to create a world class developer experience for managing knowledge.

Our goal is to provide a tool with the efficiency of vim, the extensibility of emacs, and the approachability of VSCode.

Since vscode allow any folder, including root dir (.) to be a workspace, isn't it ironic with above objective that dendron intentionally disable this scenario?

awidjaja commented 2 years ago

Further down. It seems the founder understands that Different knowledge bases require different levels of structure. But reality is different.

Gradual Structure Dendron extends markdown with structural primitives to make it easier to manage at scale and tooling on top to work with this structure.

Different knowledge bases require different levels of structure - a PKM used for keeping daily journals is different than a company wide knowledge base used by thousands of developers.

Dendron works with any level of structure, meaning you can take free form notes when starting out and gradually layer on more structure as your knowledge base grows more.

Flexible and Consistent Dendron is both flexible and consistent. It provides a consistent structure for all your notes and gives you the flexibility to change that structure.

In Dendron, you can refactor notes and Dendron will make sure that your PKM is consistent throughout. This means that you have the best of both worlds: a basic structure for the organization but the flexibility to change it.

kevinslin commented 2 years ago

Hey @awidjaja

Thanks for reporting this interesting edge case.

We'll add this to our validation steps to show an error so that future users can stay clear of it.

In terms of using multi-vault while keeping your job - something to note is that a vault today isn't meant to be initialized outside of a workspace. So if you want different users to use different vaults, you would also have to create a different workspace for those vaults.

For example, lets say you have an admin vault and a regular vault and you needed user A to access both vaults whereas user B should only access the regular vault. The setup would look like the following:

For user A

- workspace-admin
    - dendron.yml
    - admin/
    - regular/

For user b

- workspace-normal
    - dendron.yml
    - regular/

We're working on features to make thhis setup simpler in the future by making every vault a workspace.

awidjaja commented 2 years ago

Hi Kevin, first of all the keeping a job think is a joke, not to be taken too seriously. However, the frustration is real.

The question is how to get main repo structure like below to be split into multi-vault that can be maintained independently by users of each team.

workspace-main
    - dendron.yml
    - Teams/
        - team-a/ (actual folder)
            - a.md
            - b.md
    Team A (vault name)

The workaround you shared requires a separate effort to store the workspace configuration file for each vault to a different repo as it can't be stored inside its own repo.

The only way is to restructure the main repo first into this somewhat ugly structure.

workspace-main
    - .git
    - dendron.code-workspace
    - dendron.yml
    - Teams/
        - team-a/ 
            - vault/ (actual folder)
                - a.md
                - b.md
            - .git
            - dendron.code-workspace
            - dendron.yml
    Team A (vault name)

dendronhq / dendron