search

novoid / appendfilename

Intelligent appending text to file names, considering file extensions and file tags
GNU General Public License v3.0
49 stars 7 forks source link

Move constants to dot config file #5

Open metbril opened 5 years ago

metbril commented 5 years ago

Suggestion.

The code has some constants Iike separators and ignored words that are hardcoded. Since I used pip to install, it is hard to customize this. My suggestion would be to move these constants to a hidden config file in $HOME, like $HOME/.appendfilename or $HOME/.config/appendfilename.

https://unix.stackexchange.com/questions/68721/where-should-user-configuration-files-go

novoid commented 5 years ago

Good point and I will have to think about it.

My initial thoughts:

I do hesitate putting FILENAME_TAG_SEPARATOR, BETWEEN_TAG_SEPARATOR, or TEXT_SEPARATOR into a user config file. Since appendfilename is embedded in workflows with other tools, I would never support different values for those variables.

For FILENAME_COMPONENT_LOWERCASE_BLACKLIST and INITIAL_CONTROLLED_VOCABULARY it is a different story though. Do you really want to modify them? I honestly did forget that I do have such variables myself in the first place ...

metbril commented 5 years ago

Well, for FILENAME_COMPONENT_LOWERCASE_BLACKLIST you are using German phrases. My main language is Dutch, but I also use English a lot, so to be able to blacklist in another language a configurable list would be nice.

I'm not sure what I would use INITIAL_CONTROLLED_VOCABULARY for, but these words seem specific to your personal use cases. Since the tool is in pip, I would suggest making it generic with some sensible defaults?

Don't you think using the separators in a config file (always) is the owner/user's responsibility? Your defaults make sense, and any other tools should (imho) also support configured separators.

novoid commented 5 years ago

Hi,

As far as I remember, INITIAL_CONTROLLED_VOCABULARY was necessary for unit testing but I'd have to look into it to confirm this. IMHO it's not necessary for a user to overwrite/modify this since I've implemented the .filetags approach which allows even more advanced workflows.

ad modifying the separator string: you're right that it is the responsibility of the user. However, when I do see a config possibility as a user, I should be able to assume that any valid setting is supported by the tool. And this assumption I need to avoid.

The likelihood that something gets broken among appendfilename, guessfilename, filetags, and much more tools because of changing the separator string is very high. Therefore, I consider FILENAME_TAG_SEPARATOR, BETWEEN_TAG_SEPARATOR, and TEXT_SEPARATOR as hard-coded even when I decided to put them into constants.

For FILENAME_COMPONENT_LOWERCASE_BLACKLIST and INITIAL_CONTROLLED_VOCABULARY I have to take a deeper look and think about it. So far, there are no clear use-cases to me because I don't think that I myself still need/use them. Maybe they get removed altogether.

novoid commented 3 years ago

This could also address #9.