Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directory folgezettels [plugin] #497

Closed
srid opened this issue Dec 21, 2020 · 4 comments · Fixed by #500
Closed

Directory folgezettels [plugin] #497

srid opened this issue Dec 21, 2020 · 4 comments · Fixed by #500
Assignees
Labels
as-plugin Should be implemented as a plugin proposal Proposal with exact spec yet to be fleshed out

Comments

@srid
Copy link
Owner

srid commented Dec 21, 2020

Neuron has an experimental feature (disabled by default; see here) for storing notes in sub-directories recursively. We can take it one step further by treating these directories as the folgezettel parent of its contents.

Consider the following directory layout:

foo/
foo/bar/qux.md

In this proposal, Neuron determines 3 zettels, with foo branching to bar that in turn branches to qux. Only qux exists as a file on disk; the other two are created on demand (similar to #379 in concept). The contents of foo and bar will be populated with the appropriate link query that displays their contents. Users may override this content by adding a foo.md and foo/bar.md, which will continue to (implicitly) branch of to their contents.

@srid srid added the proposal Proposal with exact spec yet to be fleshed out label Dec 21, 2020
@srid srid self-assigned this Dec 21, 2020
@srid srid pinned this issue Dec 21, 2020
@srid
Copy link
Owner Author

srid commented Dec 24, 2020

Addendum:

  • The zettel ID of these auto-created zettels should reflect the entire path. So foo/bar/ should have the ID index-foo-bar. If the user creates a foo/bar.md (to manually specify the directory zettel), then the zettel ID would just be bar. Why? Because it allow us to have duplicate directory names in the tree; eg: Archive/2020 and Tax/2020. You can create a Tax/2020.md without conflicting with the Archive/2020 directory zettel.
    • Once you override like that, you can't have "2020.md" elsewhere, though (because zettel filenames must be unique). So in this case, the user may have to name it Tax/Tax2020.md and Tax/Tax2020/*.

EDIT (Dec 25): Hmm, I'm two-minded about it. For simplicity, perhaps we should just go with the original directory name, and have the user rename their folders should a conflict arise. For eg., rename Archive/2020/12 => Archive/2020/2020-12 (to prevent conflicts with day "12" from other months, and years)

@srid
Copy link
Owner Author

srid commented Dec 24, 2020

And,

  • There will auto-generated hierarchical tags based on the path. Eg: index/foo/bar. That's how directory folgezettel relationships will be established.

CC @b0o especially as this is looking similar to their neuron-extras

@srid srid changed the title Implicit folgezettel via sub-directories Directory folgezettels Dec 24, 2020
@srid srid added the as-plugin Should be implemented as a plugin label Dec 26, 2020
@srid srid changed the title Directory folgezettels Directory folgezettels [plugin] Dec 26, 2020
@srid srid closed this as completed in #500 Dec 28, 2020
@srid
Copy link
Owner Author

srid commented Dec 28, 2020

https://neuron.zettel.page/dirtree.html

@srid srid unpinned this issue Dec 28, 2020
@RoyiAvital
Copy link

In my opinion this project has 2 layers:

  1. The graph generation engine.
  2. The generation of the consumption form of the data (The website).

I think it will make sense to tag issues based on which layer they act on.
For instance, having an automated generation of a web page per tag which by default shows the cloud of the Zettels using this tag ("Cloud" in the form of the result of the query [[z:zettels?tag=foo]] is a great idea in my mind.

Changing the graph and relations by adding a new object into the graph which is not user generated, is wrong in my opinion.

But regardless of my opinion, making easy to understand on which layer we're talking, in my opinion will generate a better discussion between the users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
as-plugin Should be implemented as a plugin proposal Proposal with exact spec yet to be fleshed out
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants