feat(list): allow modification of display commands

[aagon]

At the moment, the display commands of the various shell invocations are hardcoded into the various autoloaded functions. It could be useful to let the user modify those, to use xargs(1) rather than the ls option of find(1), for instance.

This simple patch replaces the hardcoded strings with variables defined by a few defcustoms. I have also taken the liberty to create a customisation group for dired-list.

This makes c7ca84c unneeded : the literal flag can now directly be added or removed in the string describing the command (it is there by default, I have followed the default value you had given to dired-list-use-N-flag).

Feel free to rename the variables, I was not particularly inspired.

Best,

Aymeric Agon-Rambosson

[Fuco1]

One thing I wonder about is that if we add some fix and someone customized these strings, they won't get the fix. Although this is somewhat minimal concern, since that would most likely imply that the base program changed as well and so probably people would investigate... but it is a bit inconvenient.

I tried to design dired-list so it's very simple to just add your own versions in your own config as new command just calling dired-list and providing the arguments.

So in principle this could be a quick way to do some light customization but the price is that the bugfixing / updates might be a bit confusing.

[aagon]

I remember wanting to add this partly because I did not like the default output using the -ls option of find(1), and also because I needed the -F option of ls(1) to work around a nasty bug (the last character of the filename was getting eaten under certain conditions) that I could not reproduce with emacs -q. So it was precisely to allow for a quick bugfix that I thought of adding these.

I tried to design dired-list so it's very simple to just add your own versions in your own config as new command just calling dired-list and providing the arguments.

Indeed, I could (should) have done that, and I will. I'll close for the time being.

since that would most likely imply that the base program changed as well

It might be in the future that the changes to the underlying programs (hopefully rare) will make you have to add other ad hoc variables like dired-list-use-N-flag, up to a point when this PR will prove simpler. I'll open it again if ever the case arises.

I agree that the downside is that users would have to actually read the manual pages of the underlying commands, and since the fixes you mention would arrive in the default values of these variables, they would also have to check for changes there if anything goes wrong with their config. But that is a very common issue : issues introduced by changing the default values of variable become the user's responsibility, particularly when the variable itself can be any arbitrary string.