Setting denote-directory in .dir-locals.el doesn't override denote-directory, but is a silo flag about denote

[MirkoHernandez]

I believe I had similar issues, I started modifying the original denote functions to get the desired functionality but this stopped working when the denote-directory functions changed (I guess after version 2.0 ). Anyway denote-user-enforced-denote-directory provides everything for the workflow I'm using - two custom functions for creating the notes and for everything else (renaming, keywords) the regular denote functions.

(defun my/denote-here ()
 (interactive)
 "Creates a note in default-directory."
 (let ((denote-user-enforced-denote-directory default-directory )) 
   (call-interactively 'denote)))

[jeanphilippegg]

I have made a pull request that removes denote-user-enforced-denote-directory. Working with denote-directory should behave like other user options, meaning you can let bind it as you did, or use it in a .dir-locals.el (with a valid path).

Your use case would be supported.

See pull request #246.

[d-qoi]

Yup, that would make Denote support what I'm trying to do!

[MirkoHernandez]

@jeanphilippegg The problem with that approach is that it will break links that point outside the default directory (unless you are in the root of the silo - try linking, or finding a note from a nested directory to a parent directory). I've been using denote-user-enforced-denote-directory without any issue for months, it is a very simple way to accomplish @d-qoi intended workflow.

A more general solution would probably be the possibility of setting different silo types. But currently (as I understand it) the linking and the note creation functionality is intertwined, denote-directory and denote--default-directory-is-silo-p work a similar way no matter the intended action.

[jeanphilippegg]

@MirkoHernandez Can you give the example setup that is going to break? I am not sure I understand it.

BTW, in pull request #246, I have made denote-user-enforced-denote-directory an obsolete alias of denote-directory, so your current setup would still work until we decide to remove it.

[jeanphilippegg]

After verification, we mostly never use the variable denote-directory, but instead rely on the function (denote-directory) which uses denote-user-enforced-directory or denote-directory in the end.

I think your current setup will not be affected by the changes in #246. If you are able to give it a try and confirm if everything still works, that would be ideal.

[MirkoHernandez]

Sorry, maybe I misunderstood the proposed changes to denote--default-directory-is-silo-p. That function or some other similar one was used to get the directory of the silo, in older versions of denote it used the value set by denote-directory (in my use case the actual value of default-directory) now it defaults to the location of .dir-locals.el, which works great for finding links.

If denote--default-directory-is-silo-p were to return the default-directory value (I though this was @d-qoi suggested change) then some of the link functions would stop working, they start looking for matches from the default-directory and not the entire silo.

[jeanphilippegg]

I see. This is all confusing and it is the kind of confusion that I hoped to remove with my pull request. :)

I am still unsure as to what is your specific usage of Denote. I could make a few tests on my side, but my guess is that it would not be broken. Let me know if you would like me to try some setups (the directories, the locations of .dir-locals.els and their content) just to be sure!

[MirkoHernandez]

@jeanphilippegg I think denote-user-enforced-denote-directory works great, it covers @d-qoi (I'm not sure why you would not want to use that variable) use case and I guess it should support almost any workflow. I never call denote directly tho, this can be confusing for new users who want a specific workflow and find out that setting up dirs.locals.el is not enough.

This version of denote works extremely well for me. In the old version I used to tinker with directory-is-silo-p and denote-link-ol-follow to get the desired results, now I just use a simple wrapper to denote and everything works.

[d-qoi]

I would rather not bind to denote-user-enforced-denote-directory in .dir-locals as the docs call it out specifically for let binding, which is not my use case.

The behavior change of how denote-directory is used in global config and local config with .dir-locals is not well enough explained in the docs, in my opinion, and the reason for that behavior change seems to mostly be a design decision, that is not currently explained in the docs, and not an implementation restriction.

The issue I am calling out is that the expected behavior of binding a variable called denote-directory locally doesn't actually change the value of denote-directory to the local value, which is not consistent.
The local value bound to the correct path is already needed if we are using through sub directories in a silo.
From the docs:
IMPORTANT If your silo contains sub-directories of notes, you should replace default-directory in the above examples with an absolute path to your silo directory, otherwise links from files within the sub-directories cannot be made to files in the parent directory. For example:

The behavior is inconsistent within denote already, which is confusing in my opinion. The suggested change I put in initially would make it consistent without breaking existing behaviors.

[MirkoHernandez]

I agree that the silo behavior is confusing when using default-directory but for your particular use case @d-qoi using denote-user-enforced-denote-directory in a function that wraps denote should work, please try this approach, and confirm if it works or what is missing.

The behavior is inconsistent within denote already, which is confusing in my opinion. The suggested change I put in initially would make it consistent without breaking existing behaviors.

It is confusing but I tried your exact approach about a year ago and it breaks the link functions for the reasons mentioned above.

A possible solution: separate the behavior of denote--default-directory-is-silo-p and denote-directory when it is called for link usage and when it is called for creating notes. This was my approach, until denote-directory changed and it became unnecessary.

[d-qoi]

That approach will work. I can wrap entry points for denote that I want to use to force a value for denote-directory using denote-user-enforced-denote-directory. However, I'm not sure how wrapping a function to let-bind denote-user-enforced-denote-directory for entry points, in my use case, would be different than binding it in a .dir-locals file, which is something I am trying explicitly to avoid.

How does what I suggested initially break links? I have not seen any issues with links so far, even between silos?

[MirkoHernandez]

@d-qoi I initially read the code and assumed that you were using the local-value (this is what I did, reading the value of default-directory if set) but trying the suggested function it turns out that the stringp test ignores the default-directory variable and the function uses the root of the silo (the default behavior).

Those changes seem to improve the default behavior when using a string as a directory ( links would not break) . All the notes created would go into the specified directory, is this the expected result ?.
I guess most users are using that approach but I'm using default-directory for note creation, using it in denote--default-directory-is-silo-p breaks the linking functionality.

[d-qoi]

Ah, assuming you mean denote-directory instead of default-directory that is correct.

If I define denote-directory as a string, and as a valid directory path, in .dir-locals then denote--default-directory-is-silo-p returns that local value. If it is not a string or valid path, denote--default-directory-is-silo-p returns the dir of the .dir-locals file found in the path of default-directory, the original behavior of the function.

From the example in the docs, setting ((nil . ((denote-directory . default-directory)))) in the .dir-locals will fail the stringp check, as the alist-get will return the symbol 'default-directory rather than the value default-directory holds.

[jeanphilippegg]

default-directory is never actually evaluated if denote-directory is set to it.

Anyway, I think this might all be overengineered at this point. I still think that the changes I proposed will not break any current setup, while allowing the setup that you explained in your inital post to work. It would help if you gave a setup that could be tested, something like a directory structure with the .dir-locals.el used. I could test if it breaks. I am still confused as to what could break.

I think that if we have denote-directory behave like any other Emacs variable, all this complexity would go away.

[protesilaos]

I merged the pull request. Please let me know if there are any more issues with this.