5 ms·

I mean, Emacs respects the convention, developed ~40 years after Emacs was first released.

psanford 3y ago
I'm not saying the developers couldn't support it. I'm saying you are not entitled to name call them if they choose to not support it.
lilyball 3y ago
There are countless tools that write to the bash files though, which is not true for most programs. Bash changing its locations would break all of these. Heck, git adopted ~/.config/git years ago, and yet just last week I ran across a tool that created and wrote to ~/.gitconfig instead of my ~/.config/git/config. If Bash tried to change then we'd be dealing with the fallout probably forever.
- devnullbrain 3y ago
  >There are countless tools that write to the bash files though Which is terrible, btw. Configuration using untyped, unchecked files, readable & writeable by almost everything is one of the worst parts of Linux. Especially when it exists in a directory the user should expect to be their exclusive domain.
  - arp242 3y ago
    Whether it is or isn't terrible is sort of besides the point; the fact is that it exists, and that stuff would break.
    - LukeShu 3y ago
      IMO, it's terrible enough that that stuff breaking would be a good thing.
      - arp242 3y ago
        It's not that "terrible" in the first place, all things considering, and breaking people's workflow just to satisfy your preferences is just anti-user and a good way to piss off people.
        zlg_codes 3y ago
        If I remember correctly, ncmpcpp did this crap. $HOME/.ncmpcpp -> $XDG_CONFIG_HOME/ncmpcpp The correct way to handle this, for any projects forcing the change, is to use a staged deprecation period: * first, you add support for XDG * second, wait at least one version to give people time to get used to it * third, switch the config location search order so it checks XDG before .whatever * lastly, after an announcement and deprecation period, and at least 2-3 releases, remove support for the .whatever folder. (To be fair, it's totally possible that my upgrade path with ncmpcpp skipped over some steps and they actually did it correctly. Will have to check when I care enough to dig through commits.)
      - n0tinventedhere 3y ago
        I agree with you there. I don't remember which it was, but one of the runtimes managers (was it pyenv, rvm or nvm?) wrote to my .bashrc and .zshrc without asking for permission to do so, instead of just telling me the locations it wants me to include in my $PATH. I don't do path munging in my zshrc, rather, I source a different file that I use to manage this stuff and set up a way to avoid duplicates in $PATH and only adding things to $PATH when they exist so that my shell configuration doesn't do anything dumb when used across multiple computers. Well, I'd rather their attempt at writing to my shell config breaks. This is one of the many reasons why you should, if you haven't yet, manage your dotfiles with version control. Many tools assist in giving you some sugar over the process, I use homeshick which will move files away into a git controlled folder and create symlinks.
      - prmoustache 3y ago
        If it is that terrible, I guess the good way to do it is not to break stuff to people using bash, but to use another shell, possibly a fork that will be expressly known to not use bash original config files. That way you can introduce the new guidelines while not breaking stuff to those who want the old bash.
- tmtvl 3y ago
  Wouldn't the tools which write to (and presumably read from) the Bash files break if the user were to do something like use another shell? While Bash has its niceties, I really can't go back to not being able to autocomplete "~/pr/l/Ka/RE" to "~/projects/lisp/Kandria/README.mess" with a single TAB.
- yrro 3y ago
  Any tool which dares to write to my .bashrc (or any other config file that it doesn't own) will not remain on my systems. How dare they!
- soraminazuki 3y ago
  There are multiple reasons why tools shouldn't be doing this. First, I don't like tools overwriting my configuration. My dotfiles belong to me and I have things configured the way they are for a reason. Tools should inform me if changes are required to my configuration, and not just go and change it by itself. Second, it prevents users from making their configuration files read only. This affects users of Home Manager by the way, which deploys configuration files as symlinks to read only files under /nix/store. Even more egregious are files that write mutable state to configuration files, which makes them unsuitable for version control. Unfortunately, Docker is guilty of this and stores mutable state in config.json. Finally, as mentioned, it interferes with XDG adoption. Personally, I'm all for breaking tools that write to user configuration files. They cause too many headaches with no clear benefit.
NikkiA 3y ago
Wait, it does? I'm still using .emacs.d like a schlub.
tsimionescu 3y ago
I've never seen .emacs anywhere other than $HOME/.emacs, or seen Emacs write files outside $HOME/.emacs.d. In what situation does Emacs use $HOME/.config/?
- delta_p_delta_x 3y ago
  If you already have legacy paths, then Emacs doesn't migrate things for you, as far as I understand. This is fair behaviour IMO, because migrating configs automatically might break user setups.
  - psanford 3y ago
    Then you have to support both forever. Its not clear why that is better.
  - tsimionescu 3y ago
    Based on the other comments, it sounds more like emacs supports XDG if you want it to, but still defaults to ~/.emacs if you don't explicitly set up an XDG environment for it. Distributions may choose to do so, but I don't think compiling from source does.
- LukeShu 3y ago
  Since Emacs 27.1, if $XDG_CONFIG_HOME/emacs/ exists and neither ~/.emacs nor ~/.emacs.d/ exist, then it will set user-emacs-directory to $XDG_CONFIG_HOME/emacs/ instead of ~/.emacs.d/.
  - tsimionescu 3y ago
    So, if I understand correctly (and this would match my experience), if I compile emacs from sources on a new computer and just run make install, the "legacy" paths will be used instead of the XDG ones, unless I explicitly mkdir $XDG_CONFIG_HOME/emacs. I would then say emacs supports XDG, but doesn't use it by default, right?
    - 3y ago

I'm not saying the developers couldn't support it. I'm saying you are not entitled to name call them if they choose to not support it.

lilyball 3y ago

There are countless tools that write to the bash files though, which is not true for most programs. Bash changing its locations would break all of these. Heck, git adopted ~/.config/git years ago, and yet just last week I ran across a tool that created and wrote to ~/.gitconfig instead of my ~/.config/git/config. If Bash tried to change then we'd be dealing with the fallout probably forever.

devnullbrain 3y ago
>There are countless tools that write to the bash files though Which is terrible, btw. Configuration using untyped, unchecked files, readable & writeable by almost everything is one of the worst parts of Linux. Especially when it exists in a directory the user should expect to be their exclusive domain.
- arp242 3y ago
  Whether it is or isn't terrible is sort of besides the point; the fact is that it exists, and that stuff would break.
  - LukeShu 3y ago
    IMO, it's terrible enough that that stuff breaking would be a good thing.
    - arp242 3y ago
      It's not that "terrible" in the first place, all things considering, and breaking people's workflow just to satisfy your preferences is just anti-user and a good way to piss off people.
      - zlg_codes 3y ago
        If I remember correctly, ncmpcpp did this crap. $HOME/.ncmpcpp -> $XDG_CONFIG_HOME/ncmpcpp The correct way to handle this, for any projects forcing the change, is to use a staged deprecation period: * first, you add support for XDG * second, wait at least one version to give people time to get used to it * third, switch the config location search order so it checks XDG before .whatever * lastly, after an announcement and deprecation period, and at least 2-3 releases, remove support for the .whatever folder. (To be fair, it's totally possible that my upgrade path with ncmpcpp skipped over some steps and they actually did it correctly. Will have to check when I care enough to dig through commits.)
    - n0tinventedhere 3y ago
      I agree with you there. I don't remember which it was, but one of the runtimes managers (was it pyenv, rvm or nvm?) wrote to my .bashrc and .zshrc without asking for permission to do so, instead of just telling me the locations it wants me to include in my $PATH. I don't do path munging in my zshrc, rather, I source a different file that I use to manage this stuff and set up a way to avoid duplicates in $PATH and only adding things to $PATH when they exist so that my shell configuration doesn't do anything dumb when used across multiple computers. Well, I'd rather their attempt at writing to my shell config breaks. This is one of the many reasons why you should, if you haven't yet, manage your dotfiles with version control. Many tools assist in giving you some sugar over the process, I use homeshick which will move files away into a git controlled folder and create symlinks.
    - prmoustache 3y ago
      If it is that terrible, I guess the good way to do it is not to break stuff to people using bash, but to use another shell, possibly a fork that will be expressly known to not use bash original config files. That way you can introduce the new guidelines while not breaking stuff to those who want the old bash.
tmtvl 3y ago
Wouldn't the tools which write to (and presumably read from) the Bash files break if the user were to do something like use another shell? While Bash has its niceties, I really can't go back to not being able to autocomplete "~/pr/l/Ka/RE" to "~/projects/lisp/Kandria/README.mess" with a single TAB.
yrro 3y ago
Any tool which dares to write to my .bashrc (or any other config file that it doesn't own) will not remain on my systems. How dare they!
soraminazuki 3y ago
There are multiple reasons why tools shouldn't be doing this. First, I don't like tools overwriting my configuration. My dotfiles belong to me and I have things configured the way they are for a reason. Tools should inform me if changes are required to my configuration, and not just go and change it by itself. Second, it prevents users from making their configuration files read only. This affects users of Home Manager by the way, which deploys configuration files as symlinks to read only files under /nix/store. Even more egregious are files that write mutable state to configuration files, which makes them unsuitable for version control. Unfortunately, Docker is guilty of this and stores mutable state in config.json. Finally, as mentioned, it interferes with XDG adoption. Personally, I'm all for breaking tools that write to user configuration files. They cause too many headaches with no clear benefit.

NikkiA 3y ago

Wait, it does? I'm still using .emacs.d like a schlub.

tsimionescu 3y ago

I've never seen .emacs anywhere other than $HOME/.emacs, or seen Emacs write files outside $HOME/.emacs.d. In what situation does Emacs use $HOME/.config/?

delta_p_delta_x 3y ago
If you already have legacy paths, then Emacs doesn't migrate things for you, as far as I understand. This is fair behaviour IMO, because migrating configs automatically might break user setups.
- psanford 3y ago
  Then you have to support both forever. Its not clear why that is better.
- tsimionescu 3y ago
  Based on the other comments, it sounds more like emacs supports XDG if you want it to, but still defaults to ~/.emacs if you don't explicitly set up an XDG environment for it. Distributions may choose to do so, but I don't think compiling from source does.
LukeShu 3y ago
Since Emacs 27.1, if $XDG_CONFIG_HOME/emacs/ exists and neither ~/.emacs nor ~/.emacs.d/ exist, then it will set user-emacs-directory to $XDG_CONFIG_HOME/emacs/ instead of ~/.emacs.d/.
- tsimionescu 3y ago
  So, if I understand correctly (and this would match my experience), if I compile emacs from sources on a new computer and just run make install, the "legacy" paths will be used instead of the XDG ones, unless I explicitly mkdir $XDG_CONFIG_HOME/emacs. I would then say emacs supports XDG, but doesn't use it by default, right?
  - 3y ago