tats / w3m

Debian's w3m: WWW browsable pager
https://tracker.debian.org/pkg/w3m
Other
870 stars 91 forks source link

w3m doesn't respect XDG Base Directory standard? #130

Open rhysday opened 4 years ago

rhysday commented 4 years ago

I would like to move .w3m out of $HOME and into $XDG_CONFIG_HOME

Bumbadawg commented 4 years ago

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

kmk3 commented 3 years ago

Related SourceForge issue: https://sourceforge.net/p/w3m/feature-requests/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

Boruch-Baum commented 3 years ago

+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

pirate486743186 commented 3 years ago

since this seams to be stalled, may i suggest you start by moving the cache only.

SlidingHorn commented 3 years ago
#!/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.

@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)

z0noxz commented 3 years ago

@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.

MRAAGH commented 3 years ago

@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.

yashlala commented 3 years ago

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:

  1. w3m checks for the environment variable W3M_DIR. If the environment variable is defined, then w3m will put all of its files under that location (just as it does with ~/.w3m today).
  2. 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?

pirate486743186 commented 3 years ago

It would be great if you could make the location of the cache user configurable in the config file.

tats commented 3 years ago

W3M_DIR. If the environment variable is defined, then w3m will put all of its files under that location

It seems acceptable for me.

rkta commented 3 years ago

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.

Jonta commented 3 years ago

Commit-URL of what @rkta wrote: https://github.com/rkta/w3m/commit/461bbdb8ba7a2f29b90fa8e0fd6cd804e1cc9c6d

m040601 commented 2 years ago

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.

  1. 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.

  1. Would also a env variable "$W3M_CACHE_DIR" be easier to implement as an alternative instead ?

Thanks in advance.

yashlala commented 2 years ago

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.

rkta commented 2 years ago

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

ignamartinoli commented 2 years ago

Any news on this being merged?

tats commented 1 year ago

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.

jessebot commented 1 year ago

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 🎉