Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to detect the delimiter used (_ or space, etc) as output #9

Open
nb-programmer opened this issue Jun 11, 2022 · 2 comments
Open

Comments

@nb-programmer
Copy link

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

@igorcmoura
Copy link
Owner

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:

  1. 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:

  2. 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?

@nb-programmer
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants