Added a command line option that reduces attachment filenames to thei…

[Optimierungswerfer]

…r basename only instead of containing the whole local path as a prefix, which can be ugly especially if the local path uses upwards directory movement resulting in something like "......_dir_Attachment.txt" instead of "Attachment.txt". The command line option is opt-in, which means this addition does not break anything.

[kovetskiy]

Hi! What is your motivation behind making this behavior optional? It feels like we've got a bunch of command line arguments already.

[Optimierungswerfer]

There are two related reasons for why I made it optional:

First, to consider that some users might rely on the old behavior and changing the default would be a breaking change (I did not want to pull the rug from anyone's feet) and,
Secondly, to keep the old behavior available, since it might be desired to still have the full path in the attachment name. It really depends on the specific use case and if you are dealing with upwards directory movement in your attachment paths.

If you think it's okay in this case to sacrifice feature/behavior stability in favor of keeping down the number of command line arguments, I could of course also make it the new behavior and scrap the old one entirely, but I did not want to make this call by myself.

[Skeeve]

Why not make it also a configurable option in the mark file like I did with --drop-h1 and --title-from-h1.

That way one can make it a default by means of the configuration file.

And maybe instead of having it be a boolean you could make it an integer:

shorten_filenames=0=> Do not shorten
shorten_filename=1 => keep basename
shorten_filename=<number> => keep <number> path elements from the end. So 2 would be the parent directory of the attachment plus the filename.

[Skeeve]

For just one commandline parameter there are quite a lot of changes.

And what about my suggestion of making it an integer giving the number of elements you want to keep from the filename?