eg do not support XDG_CONFIG_HOME about eg HOT 14 CLOSED

This is now merged and released as of v1.2.0.

from eg.

Is that the way XDG is supposed to work? I would have expected that you have either XDG or ~, not both. Is that incorrect? My first glance at the documentation didn't take an opinion, though I could have missed it.

No, XDG is not supposed to work in tandem with ~. On contrary, it is designed to stop the practice of keeping the config/data file in ~.

I have submitted such PR, because, I wanted to maintain the backward compatibility for the users that have used eg in past and their config file is in ~. For them this PR will not break anything, but for new users the default XDG convention will be followed (i.e. XDG_CONFIG_HOME for config file).

from eg.

Is XDG_CONFIG_HOME an archlinux-only thing? I'm unfamiliar with it.

from eg.

XDG_CONFIG_HOME is part of XDG directory structure, which is a new (quite old now) specification for unix like systems. The details are are available here.

Previously different program used to save the user configuration and data in $HOME folder. This specification tries to unclutter the mess, so that $HOME is more cleaner and config file and data file are having special folder for them.

from eg.

Sorry for the delay on this. I've been trying to decide what I think about it.

I wasn't familiar with XDG. Trying to get a sense for how widespread this it, it looks like git uses it, while it appears npm, ruby gems, and tmux have decided against it.

Do you know of other tools that do/don't use it? The npm issue says Chrome uses it, which is a pretty heavy hitter.

I respect the philosophy behind XDG, but I am somewhat hesitant to add (admittedly modest) complexity for what seems like a rather niche case. Certainly XDG users must have some way to support tools that don't look for the XDG directory? I run a symlink script when I install my dotfiles repo on a new machine. Without all tools buying into the XDG system, this step seems unavoidable. Keeping eg as one of them doesn't seem like a terrible thing to me. If I used XDG myself I might feel differently, of course.

Alternatively, people with XDG could just include an alias in their bashrc to have eg run with the config file flag pointing at their XDG directory.

The tmux issue above has 50 thumbs up to the idea of implementing XDG. If this was a popular request I could see including it. For now, I'm inclined to keep it as-is, reconsidering if it becomes a popular request.

I'm curious to hear what you think, though. Looking at those issues, people that use XDG seem to have pretty strong feelings about it. =)

from eg.

I'm rethinking my position on this, though I'm considering a slightly different implementation.

One thing I notice in your PR is that it looks like you are supporting both the XDG system and the defaults. For example if the XDG directory exists, but the XDG egrc doesn't exist, you still look in the default directory: ~/.egrc.

Is that the way XDG is supposed to work? I would have expected that you have either XDG or ~, not both. Is that incorrect? My first glance at the documentation didn't take an opinion, though I could have missed it.

from eg.

Sorry this has taken me so long. I wanted to take a different approach than you did so that I could write tests, but the tests are hard to understand. I'd write them differently if I was writing them now.

Can you take a look at this branch and see if it behaves like you expect? It did in my own messing around, but I'd love some confirmation.

from eg.

If anybody wanting this and using this directory structure could verify on the branch I mention above, I'd appreciate it. I'm hoping to include this in a release this week, and I'd appreciate a sanity check.

from eg.

I just had a look at the branch; I created an eg.conf in $XDG_CONFIG_HOME and it works as expected
I'm new to eg but I have two thoughts:

• Thank you for trying to implement XDG specs. For those who try to use them it's very satisfying to find that a program tries to respect them.
• As for the sanity check or simply my personal opinion, in my experience with configs in XDG_CONFIG_HOME, and also according to the actual specs, it seems like the most sensible choice is to have a subdirectory, meaning the file should be located at $XDG_CONFIG_HOME/eg/eg.conf. This also makes sense because I would store custom and/or examples there as well, making it a nicely packed directory for the program.

Let me know what you think!

from eg.

Yikes! Good point on the fact that there should be a subdirectory! I should have realized this, since I've begun using XDG in a few places on my linux machines, but I missed it.

Thank you so much for pointing it out!

I am inclined to leave it as ${XDG_CONFIG_HOME/eg/egrc rather than ${XDG_CONFIG_HOME}/eg/eg.conf, however. I don't see anything normative about the name of the actual config file in the spec you link to, and the summary here (see the notes column in the table at the bottom) shows some files that retain the rc name, like hg/hgrc for mercurial.

If I'm wrong about that, please let me know. I use XDG for i3 and rofi, and neither use the foo.conf syntax. Maybe I just have a biased sample, however.

In the meantime I'll make the change to a directory.

Thank you again for taking the time to check, I really appreciate it.

from eg.

Well I'm a doofus--I just realized that I had already changed it to eg.conf. I'm tempted to change it back to egrc... Hmm...

from eg.

By all means, egrc is much better!

from eg.

I just merged to master looking for ${XDG_CONFIG_HOME/eg/egrc. If you could check again that I'm right thinking it does what we discussed (it does when I try it), that'd be great.

Assuming so, I'll likely release a new version next month.

from eg.

Yes, everything works as expected. Thanks!

from eg.