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

Follow XDG Base Directory specification #57

Closed
MyFedora opened this issue Aug 3, 2023 · 6 comments
Closed

Follow XDG Base Directory specification #57

MyFedora opened this issue Aug 3, 2023 · 6 comments

Comments

@MyFedora
Copy link

MyFedora commented Aug 3, 2023

I believe ${XDG_STATE_HOME}/filetags is a more preferable default directory for tagtrees compared to ~/.filetags_tagfilter for people who want to avoid dotfile clutter. Albeit debatable, one may also want to move ${HOME}/.filetags inside of an xdg base directory, which could be at the following path: ${XDG_CONFIG_HOME}/filetags/vocabulary. If we continue this example, #16 maps to ${XDG_CONFIG_HOME}/filetags/filetags.{toml,yaml,...}.

@MyFedora
Copy link
Author

MyFedora commented Aug 3, 2023

@nbehrnd figured you may be interested in this due to your comment in #16. I'll probably support ${XDG_CONFIG_HOME}/filetags/vocabulary as a ${HOME}/.filetags replacement in my fork as I want my home directory to stay clean without workarounds. Meanwhile, you can use boxxy if that's something you need right now.

@novoid
Copy link
Owner

novoid commented Aug 6, 2023

Thanks for the input.

I understand where you're coming from and for any other tool, I might follow your suggestion right away.

However, I need to think about that because it also breaks the simple to understand pattern of "the next .filetags file in any parent directory defines the current set of tags for its sub-hierarchy. If you would follow that pattern for ${XDG_CONFIG_HOME}/filetags, this would mean that this definition only works for ${XDG_CONFIG_HOME}/filetags and its sub-directories.

Some people may even use .filtags files only deep down their directory hierarchy and not in their $HOME. Those people would not the ones that would be irritated here but it emphasizes that the location of the file has some explicit meaning which would be broken if this idea would be implemented.

Furthermore, it would require a less clean "look for the next .filetags file in all parent directories"-algorithm since people might choose to use .filetags files in a parent directory of $HOME.

@MyFedora
Copy link
Author

MyFedora commented Aug 6, 2023

I think that's a valid perspective, and I don't intend to support that specific aspect here based on previous comments on this issue. But what I can't excuse is ~/.filetags_tagfilter.

@novoid
Copy link
Owner

novoid commented Aug 7, 2023

I'll keep it in the back of my head, closing it for now and maybe re-open it in future when I came up with a concept that is transparent to the user.

And yes, with playing around with NixOS/Home-Manager and re-thinking my own concept of dotfiles, I do understand dotfile minimalism even more.

@novoid novoid closed this as completed Aug 7, 2023
@novoid novoid self-assigned this Aug 7, 2023
@MyFedora
Copy link
Author

MyFedora commented Aug 8, 2023

I don't get why this issue was closed. I think that ~/.filetags_tagfilter doesn't follow the XDG Base Directory specification, and I see no good reason against changing the default to a more sensible value. .filetags are debatable, but that's only a part of the problem.

@novoid
Copy link
Owner

novoid commented Nov 26, 2024

As I tried to explain above, the location of the .filetags files (potential many different across your hierarchy!) itself has information attached. Therefore, one fixed position would lose that pattern. Unless there is a good concept that is able to deal with that, this won't get changed.

Furthermore, this would break the pattern that any sub-hierarchy has its meta-data files attached as well, even when synchronized across different hosts.

One single position in $HOME would break functionality here, sorry.

Related to the tagfilter file:

filetags/__init__.py:TAGFILTER_DIRECTORY = os.path.join(os.path.expanduser("~"), ".filetags_tagfilter")

What would you like to see here?

How would you do the transition of existing hierarchies of current users when this behavior is changed?

Why is the current behavior an issue in practice?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants