Open nb-programmer opened 2 years ago
Thank you for the suggestion!
So, I thought about this feature and came to the conclusion that this may not be as useful as it seems. The reasons are:
Anitopy doesn't actually detects delimiters, it receives them as an option. So replacing all given delimiters (or the defaults if you're not passing any) by spaces may achieve the same results you are expecting. However, there are some drawbacks in using this method: some delimiters are not actually considered delimiters by anitopy depending on its surrounding tokens. So you may end up replacing characters you're not supposed to. This leads to my second reason:
I don't know the details of your use case, but I think a better practice would be building the entire filename using the extracted information. This ensures that all elements end up at the same positions in the filename and all generated filenames look alike.
So, what do you think?
Yep, your second reasoning makes more sense than what I was thinking. The use case is, as I said to just make all file names in the same format (you know, some have _, and some use period to separate terms, etc.). But now that I think about it, just reconstructing the file name from the extracted data seems to be better, at least as far as renaming a bunch of file goes.
I mean, in the end they are just meaningless separator, and usually (in programming languages for example) they would be ignored, so your points make sense. I think we can just leave it as is for now, unless more people require it for a better reason
One use case for making file name uniform by detecting the delimiter used and replace it with space. The output could have a field called "delimiter_detected" for this if the delimiter can be determined