https://www.dendron.so/ logo
Join DiscordCommunities
Powered by
# dev
  • k
    so the type definition comes from vscode-uri
  • k
    dendron/packages/engine-server/node_modules/vscode-uri/lib/esm/index.d.ts
  • k
    vscode-uri
    is listed as a 
    dependency
    in 
    engine-server
    . is it showing up under 
    node_modules
    in 
    engine-server
    ?
  • j
    yep; I get things to build also if I change 
    import { URI } from "vscode-URI";
    to 
    import { URI } from "vscode-uri";
  • j
    ...since the folder there is 
    vscode-uri
  • k
    got it. the 
    vscode-URI
    was probably from me fat fingering a 
    ~
    while in `vim`😅 might be something to do with case sensitive file systems that results in an error when you're building? whatever the case, it should probably be lowercase moving forward 🙂
  • j
    oh, are you developing on windows? running linux here
  • k
    mac
  • j
    lol, didn't know that mac had case insensitive file system.
  • k
    yeah, digging into this
  • k
    Copy code
    File System Personality:   APFS
   Type (Bundle):             apfs
   Name (User Visible):       APFS
   Owners:                    Enabled
  • k
    new macs use apple file system which, by default, is case insensitive -_-
  • k
    so good catch is all i can say 🙂
  • j
    I'm on linux/android camp, so don't know anything about that
  • k
    we do have a travis pipeline that builds dendron on all platforms: https://github.com/dendronhq/dendron/blob/master/.travis.yml#L12:L12 error should have popped up there. will dig into the logs later today to see if i missed something
  • j
    taking a look at https://github.com/dendronhq/dendron/issues/141 The one line change is not quite one line, since the following would fail if the editorPath is not set:
    Copy code
    typescript
    const cNoteFname =
      opts?.overrides?.domain || path.basename(editorPath, ".md");
  • j
    While going through the code, I had to take a closer look at addBehavior - https://www.dendron.so/notes/5c213aa6-e4ba-49e8-85c5-1bdcb33ce202.html#defaultnodetypeaddbehavior . I had somewhat hard time following the examples, since the second one changes to use different note name (
    dendron.demo.md
    vs 
    pro.foo.md
    ). If changing that to be the same, the second and third became equal:
    Copy code
    childOfDomain:
dendron.demo.md -> create new journal note -> dendron.journal.2020-08-03.md

childOfDomainNamespace:
dendron.demo.md -> create new journal note -> dendron.demo.journal.2020-08-03.md

childOfCurrent:
dendron.demo.md -> create new journal note -> dendron.demo.journal.2020-08-03.md

asOwnDomain:
dendron.demo.md -> create new journal note -> journal.2020-08-03.md
  • j
    I guess the intent of the second one is to create a child for the currently active schema leaf (namespace) if such exists (?). Without better knowledge, something like the following would make this more intuitive (to me):
    Copy code
    sibling:
tools.dendron.notes.demo.md -> create new journal note -> tools.dendron.notes.journal.2020-08-03.md

child:
tools.dendron.notes.demo.md -> create new journal note -> tools.dendron.notes.demo.journal.2020-08-03.md

root:
tools.dendron.remarks.md -> create new journal note -> journal.2020-08-03.md

schema:
tools.dendron.notes.demo.md -> create new journal note -> tools.dendron.journal.2020-08-03.md

in this example, the schema-option assumes that "tools" is defined in the schema, and it has set namespace to true.
    Continuing on this, the term "namespace" is also somewhat hard to understand correctly. Elsewhere in the docs: "when a schema is a namespace, it can have arbitrary children. equivalent to cli.* glob pattern". What makes this difficult is that any node in the schema can anyway have arbitrary children, since "...you can create notes that don’t match any schema". Anyway, after spending some time on this, I think I now know how it works. Maybe formulating namespace something like this could help "making a schema node a namespace automatically brings its immediate children as part of the schema, even if they are not explicitly defined in the schema definition".
  • k
    > taking a look at https://github.com/dendronhq/dendron/issues/141 > The one line change is not quite one line, since the following would fail if the editorPath is not set: > >
    Copy code
    typescript
>     const cNoteFname =
>       opts?.overrides?.domain || path.basename(editorPath, ".md");
>
    @User you're right. all note creation requires a current active editor unless 
    _noteAddBehaviorEnum = 'asOwnDomain'
  • k
    > While going through the code, I had to take a closer look at addBehavior - https://www.dendron.so/notes/5c213aa6-e4ba-49e8-85c5-1bdcb33ce202.html#defaultnodetypeaddbehavior . I had somewhat hard time following the examples, since the second one changes to use different note name (
    dendron.demo.md
    vs 
    pro.foo.md
    ). If changing that to be the same, the second and third became equal: > >
    Copy code
    > childOfDomain:
> dendron.demo.md -> create new journal note -> dendron.journal.2020-08-03.md
> 
> childOfDomainNamespace:
> dendron.demo.md -> create new journal note -> dendron.demo.journal.2020-08-03.md
> 
> childOfCurrent:
> dendron.demo.md -> create new journal note -> dendron.demo.journal.2020-08-03.md
> 
> asOwnDomain:
> dendron.demo.md -> create new journal note -> journal.2020-08-03.md
>
    @User and that's a fair point. i updated the second example so that the first and second wouldn't look the same but i will update them all to use the same hierarchy to drive home the point
  • k
    > I guess the intent of the second one is to create a child for the currently active schema leaf (namespace) if such exists (?). Without better knowledge, something like the following would make this more intuitive (to me): > >
    Copy code
    > sibling:
> tools.dendron.notes.demo.md -> create new journal note -> tools.dendron.notes.journal.2020-08-03.md
> 
> child:
> tools.dendron.notes.demo.md -> create new journal note -> tools.dendron.notes.demo.journal.2020-08-03.md
> 
> root:
> tools.dendron.remarks.md -> create new journal note -> journal.2020-08-03.md
> 
> schema:
> tools.dendron.notes.demo.md -> create new journal note -> tools.dendron.journal.2020-08-03.md
> 
> in this example, the schema-option assumes that "tools" is defined in the schema, and it has set namespace to true.
>
    > > Continuing on this, the term "namespace" is also somewhat hard to understand correctly. Elsewhere in the docs: "when a schema is a namespace, it can have arbitrary children. equivalent to cli.* glob pattern". What makes this difficult is that any node in the schema can anyway have arbitrary children, since "...you can create notes that don’t match any schema". Anyway, after spending some time on this, I think I now know how it works. Maybe formulating namespace something like this could help "making a schema node a namespace automatically brings its immediate children as part of the schema, even if they are not explicitly defined in the schema definition". @User i use 
    domain
    to mean the root of the current hierarchy. i like your simplified values, would just swap 
    root
    with 
    domain
    . in the future, instead of having 
    parent: root
    in the default schema to indicate that it is the root of the hierarchy, planning on adding a 
    domain: true
    property instead and removing 
    parent
    altogether
  • k
    feel free to create an issue to update the 
    addBehavior
    values. we have a way of automatically upgrading old settings here: https://github.com/dendronhq/dendron/blob/master/packages/plugin-core/src/commands/UpgradeSettings.ts#L1:L1 its currently only used to set new defaults but can also be used to change existing values.
  • k
    > Continuing on this, the term "namespace" is also somewhat hard to understand correctly. Elsewhere in the docs: "when a schema is a namespace, it can have arbitrary children. equivalent to cli.* glob pattern". What makes this difficult is that any node in the schema can anyway have arbitrary children, since "...you can create notes that don’t match any schema". Anyway, after spending some time on this, I think I now know how it works. Maybe formulating namespace something like this could help "making a schema node a namespace automatically brings its immediate children as part of the schema, even if they are not explicitly defined in the schema definition". @User that's a fair point. will update the docs here as well
  • k
  • j
    @User > i use domain to mean the root of the current hierarchy Does that mean the closest node in the schema + potentially the children under it if it's a namespace? > i like your simplified values, would just swap root with domain. I was thinking that 
    schema
    would be exactly that, and 
    root
    would be the absolute root of the whole vault. IIUC, domain is the immediate child of the absolute root? I'm somewhat confused with the terminology... I think there's at least the following concepts: 1. root: the absolute root of the vault 2. static schema node: things defined explicitly in the schema 3. dynamic schema node: node that belongs to the schema via namespace mechanism 4. non-schema node: node which doesn't appear in schema or isn't an immediate child of a namespace schema node 5. domain: an immediate child of the root (?). Might be 2 or 4?
  • k
    i think part of the confusion is that dendron has two types of nodes, 
    schemas
    and 
    notes
    , and that the two relate to each other but are also independent. ### schemas - namespace: a schema can be designated as a namespace. if so, it will match all its children and designate them as a match ### notes
    Copy code
    .
├── root.md  --> absolute root of vault
└── project.md  --> root of project hierarchy. also referred to as the hierarchy **domain**
    └── project.foo.md --> a note within the project hierarchy
    ### add behavior - for all below examples, assume that 
    pro.dendron.demo.md
    is opened and that 
    pro
    matches a namespace schema - childOfDomain: add new note as child of the current domain (aka root of current hierarchy). doesn't take into account schema - output: 
    pro.journal
    - childOfDomainNamespace: add new note as child of the current domain. if domain matches a namespace schema, make it into a child of that instead - output: 
    pro.dendron.journal
    - childOfCurrent: add new note as child of whatever note your currently on - output: 
    pro.dendron.demo.journal
    - asOwnDomain: add new note as its own domain. dis-regards current open note - output: 
    journal
    (domain name specified by 
    default{NodeType}Name
    )
  • j
    Sooo.. what is the name of a node below a namespace?
  • j
    I think it gets schema icon, indicating that its part if the schema, thus its a schema node (?)
  • j
    But on the other hand, it isnt
  • k
    a node below a namespace, if we're talking about add behavior, is the 
    childOfDomainNamespace
12345...108Latest