VisiData 3.2: XDG by default?

[saulpw]

As we're preparing to release v3.2 in the coming month, I'm considering #2716, which requests that the options.visidata_dir default (currently ~/.visidata) be changed to be XDG-compatible. This is a one-line change in the code, but I've been putting it off, because there are thousands of existing VisiData users, and this may impact them. The main configuration file, visidatarc, should continue to work the same as it currently does. However, with the visidata_dir changed:

• plugins would not load
• macros would not load
• input history would be reset

We would certainly mention the manual migration step in release notes (should be just moving ~/.visidata to the new location, like ~/.config/visidata on Linux), but I imagine there may be many users who upgrade via apt or pip and would be confused or irritated when their VisiData setup seemingly degrades.

It's easiest to just keep things as they are, of course, but XDG seems to be the modern standard for people who care a lot about their dotfiles. (I care about them too but I'm old-school UNIX and have learned to deal with it.)

Anyway, I'm not really interested in automating this migration step, but I'd like to get some opinions from y'all before making the change unilaterally. You can either post a comment below, or add an emoji to vote on this change with 👍 or 👎.

EDIT: Thanks everyone, looks like there are no objections, so we'll do this for v3.2!

[reagle]

🤷 I'm indifferent. If I am reminded/prompted to do so, it's easy enough to change and transition.

[frosencrantz]

I am also old-school Unix, but it seems like XDG is the modern standard. If there is some sort of reminder/prompt XDG is configured but there is no VisiData configuration, I think that would be sufficient.

[atercygnus]

I'm new in the visidata and not managed to use a lot of plugins, so, it's hard for me to think for those users.

Is it possible to use ~/.visidata/plugins if it's present, otherwise use XDG?

[saulpw]

The code gets more complicated that way, and since our general strategy is moving away from plugins and towards incorporating them into the mono-repo, I think we're going to keep the code simple and communicate it in the release notes. I'm also curious to see if anyone notices; I think most people use it without any configuration.