Allow .pqivrc in current directory

[DHMike57]

Allows a .pqivrc file in the local directory for settings specific to that directory

[phillipberndt]

I like the idea in general, but have two concerns with this implementation:

• ./ is unexpected - I'd expect settings in the parent directories of the images to take effect
• This needs some kind of opt-in - since the config can be used to bind executing commands to arbitrary keys, it'd otherwise pose a security risk when viewing downloaded folders

The question is what's the most user friendly alternative?!

We could

• Support an environment variable with multiple additional, colon separated, additional configuration files to load
• Just use --actions-from-stdin with a bash script or an alias to do what you need
• Implement safe local configuration that asks for confirmation before loading it
• Implement actions to load configuration from a file and to reset configuration to defaults, and then you can just bind a key to load config from the current directory

The first one sounds like the best compromise at first sight. What do you think?

[DHMike57]

• ./ is unexpected - I'd expect settings in the parent directories of the images to take effect

My idea for this came from wanting bigger thumbnails in the .pqiv-select sub-directory, so the parent directory settings would not have been what I wanted. Perhaps I am misunderstanding - is the './' not simply redundant?

• This needs some kind of opt-in - since the config can be used to bind executing commands to arbitrary keys, it'd otherwise pose a security risk when viewing downloaded folders

Shows my naivety - I can never imagine what crooks might be thinking! I suspect that the 'set and forget' that I would like and the security needs are incompatible.

The question is what's the most user friendly alternative?!

We could

• Support an environment variable with multiple additional, colon separated, additional configuration files to load

Fine if it can be 'set and forget', but would allowing a relative path egPQIVRC_PATH=.pqivrc:<rest of standard locations> not open the same security risk? Something close to this could be achieved simply by pushing the PQIVRC_PATH file onto the search queue rather than returning if not found.

• Just use --actions-from-stdin with a bash script or an alias to do what you need

Something else to figure out for a light user.

• Implement safe local configuration that asks for confirmation before loading it

Mildly irritating if it had to be at each launch unless we could remember the answer eg with with a hidden file.

• Implement actions to load configuration from a file and to reset configuration to defaults, and then you can just bind a key to load config from the current directory

Workable, but another key binding to remember.

The first one sounds like the best compromise at first sight. What do you think?

It's nice of you to ask my opinion, but the truth is I am only a light occasional user who made a quick patch for a specific task of the moment. FWIW, though, I'd choose the 'confirmation' option first and the 'PATH' second (need a little more administration).

Thanks for a lovely piece of software BTW - in usability terms this is of microscopic significance!