w3m doesn't respect XDG Base Directory standard?
I would like to move .w3m out of $HOME and into $XDG_CONFIG_HOME
agreed @rhysday, here's a hack i use for Steam, it works for any XDG-non-compliant program that won't require your other $HOME files.
#!/usr/bin/env sh
HOME=${XDG_DATA_HOME}/.local/data/program program
Run it, don't source it: otherwise it'll change your session's $HOME.
This method is so much free[tm] and it makes my $HOME so clean that even teleshopping programs are jelly yo
Related SourceForge issue: https://sourceforge.net/p/w3m/feature-requests/31/
- Title: use $XDG_CONFIG_HOME and $XDG_DATA_HOME
- Created: 2017-03-31
It would be great if w3m could follow freedesktop.org's basedir-spec, and use $XDG_CONFIG_HOME and $XDG_DATA_HOME instead of ~/.w3m:
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
+1. I would love it, but it would also mean some work for emacs-w3m to check all places.
On 2021-01-03 14:42, Kelvin M. Klann wrote:
Related SourceForge issue: [1]https://sourceforge.net/p/w3m/feature-requests/31/ * Title: use $XDG_CONFIG_HOME and $XDG_DATA_HOME * Created: 2017-03-31
It would be great if w3m could follow freedesktop.org's basedir-spec, and use $XDG_CONFIG_HOME and $XDG_DATA_HOME instead of ~/.w3m:
-- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
since this seams to be stalled, may i suggest you start by moving the cache only.
#!/usr/bin/env sh HOME=${XDG_DATA_HOME}/.local/data/program programRun it, don't source it: otherwise it'll change your session's $HOME.
@Bumbadawg (or anyone else who happens to know better than me) I'm just a regular end-user who likes a clean home directory, so I'm not sure what this means or does. Do you have the time/patience to elaborate? Do I simply execute that replacing "program" with the application name?"
Also, does it need to be run for each individual application that isn't compliant? (e.g. vim, newsboat, etc)
@SlidingHorn the env-variable $HOME is set in context of running the "program" which makes it so that the "program" stores what it otherwise would have stored under ~/ now instead under ~/.local/data/program. This works as long as the program uses the $HOME variable to determine where it will store its files. If the code is sourced the $HOME variable will be changed globally and effect everything that uses it, so don't do that. "program" could be any program you wish to apply this "fix" to. The script could then be stored in your local bin dir (i.e. ~/.local/bin ~/.bin or whatever you have pointed out in your $PATH) with the same name as the program to override its default behavior.
@Bumbadawg
HOME=${XDG_DATA_HOME}/.local/data/program program
This would normally mean ~/.local/share/.local/data/program. I think the following is more suitable:
HOME=$XDG_DATA_HOME/yourprogram yourprogram
Regardless, this is an unreliable hack, but I can see how it might work in some cases, and it's probably better than nothing.
Hi All,
I was bothered by this issue as well, and thought I might put out a quick PR if there's interest in getting this merged. I'm thinking something like the following:
w3mchecks for the environment variableW3M_DIR. If the environment variable is defined, thenw3mwill put all of its files under that location (just as it does with~/.w3mtoday).- If the environment variable is not defined, it will continue to put all of its files under
~/.w3m(maintaining backwards compatibility).
This method won't comply with the XDG spec exactly, but it will give us the ability to choose where w3m puts its files. It's also very straightforward to implement, only requiring a few small changes involving the RC_DIR macro + documentation.
@tats would you be interested in merging in such a change?
It would be great if you could make the location of the cache user configurable in the config file.
W3M_DIR. If the environment variable is defined, then w3m will put all of its files under that location
It seems acceptable for me.
since this seams to be stalled, may i suggest you start by moving the cache only.
It would be great if you could make the location of the cache user configurable in the config file.
Here is a simple patch I wrote for this: patch.
Commit-URL of what @rkta wrote: https://github.com/rkta/w3m/commit/461bbdb8ba7a2f29b90fa8e0fd6cd804e1cc9c6d
Long time die hard w3m fan here. First of all thanks to everyone still maintaining and improving this software. And for all the small little improvements. I am just an end user, and it's great to see this (totally underrated) software cherished and appreciated by others.
pirate486743186 commented on Aug 6, 2021
It would be great if you could make the location of the cache user configurable in the config file.
- That option in the "config" file would be indeed great. Is this still being considered ?
It's also one of my wishes. I'd would love to choose the location for all those non critical temporary files, "w3mtmpXXX.gz", "w3msrc.htm", "w3mcacheXXX" etc .
Out of my main w3m dir and in a place choosen by me. Maybe ~/.cache/w3m (XDG_CACHE_HOME) or even in some tmp or ram volatile file system to minimize disk writes. Separated from the precious, critical and/or permanent files like config, keyboard, cookies etc.
I am not a developer, but I am curious and wonder about these C programming things. Is this something feasible, or would that involve a lot of work ? Big refactorings/restructurations ? Is it because the w3m code base is very old and predates many of these standards and therefore not easy to "hack" without substantial modifications ?
W3M_DIR. If the environment variable is defined, then w3m will put all of its files under that location
I also see that work is advancing here.
- Would also a env variable "$W3M_CACHE_DIR" be easier to implement as an alternative instead ?
Thanks in advance.
Let me try to answer point by point:
That option in the "config" file would be indeed great. Is this still being considered ?
All of us see the same GitHub issues here -- from what I gather, everybody's down to consider it, but somebody's just got to step up and do it. My PR doesn't do this, because I'm bothered by ~/.w3m, but don't care enough to sort through each cache file (the "move entire directory" approach is easy to implement).
I am not a developer, but I am curious and wonder about these C programming things. Is this something feasible, or would that involve a lot of work ? Big refactorings/restructurations ? Is it because the w3m code base is very old and predates many of these standards and therefore not easy to "hack" without substantial modifications ?
I wouldn't say that. Someone unfamiliar with the language and codebase could probably drop in and fix it in a few hours. I think the main block is not technical, but just the fact that everyone's life is busy and they have other cool things they could be doing instead :)
If you're interested and want to get your feet wet, you could have a crack at it. You don't need to be a great or even good programmer -- making small changes like this is one way to "practice".
I also see that work is advancing here. Would also a env variable "$W3M_CACHE_DIR" be easier to implement as an alternative instead ?
My patch moves the entire ~/.w3m, not just the cache files -- so I thought W3M_DIR would be more appropriate.
On Thu, Jun 02, 2022 at 04:58:46PM -0700, somename123 wrote:
Long time die hard w3m fan here. First of all thanks to everyone still maintaining and improving this software. And for all the small little improvement.
pirate486743186 commented on Aug 6, 2021
It would be great if you could make the location of the cache user configurable in the config file.
That option in the config file would be indeed great. Is this still being considered ? It's also one of my main wishes. I'd would love to see the possibility of choosing the location for all those non critical temporary files "w3mtmpXXX.gz", "w3msrc.htm", "w3mcacheXXX" etc files out of my main w3m dir and in a place choosen by me. Maybe ~/.cache/w3m (XDG_CACHE_HOME) or even in some tmp or ram volatile file system to minimize disk writes.
Separated from the critical and/or permanent files like config, keyboar, cookies etc.
See https://github.com/tats/w3m/pull/219
Any news on this being merged?
#207 and #219 are merged, so .w3m can be moved to out of $HOME with the W3M_DIR environment variable, though still XDG-non-compliant.
Just tested this on both macOS and Debian via brew install w3m --head and after:
export W3M_DIR="~/.local/state/w3m"
Everything is working as expected 🥳 I also have this alias to help with XDG compliance:
alias w3m='w3m -config ~/.config/w3m/config'
It's not a perfect XDG compliance but it's way ahead of where we started when this ticket was opened a couple of years ago 🎉