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

[bug] Sentence case should preserve sentences. #19

Open
smhmd opened this issue Nov 4, 2020 · 3 comments
Open

[bug] Sentence case should preserve sentences. #19

smhmd opened this issue Nov 4, 2020 · 3 comments

Comments

@smhmd
Copy link
Contributor

smhmd commented Nov 4, 2020

-S should preserve sentences.

$ echo 'This is a sentence. this is another sentence' | stdrename --text -S
This is a sentence. this is another sentence
$ echo 'This is a sentence. this is another sentence.' | stdrename --text -S
This is a sentence this is another sentence

First case, this is another... should be This is another....
I'm not sure why having a dot at the end of the input results in all dots being removed in the second case.

@smhmd
Copy link
Contributor Author

smhmd commented Nov 4, 2020

Ideal output is This is a sentence. This is another sentence(.?)

@Gadiguibou
Copy link
Owner

Gadiguibou commented Nov 4, 2020

This is indeed an interesting behavior, that I hadn't considered.

It is caused by the current way that stdrename renames inputs. Currently, stdrename's goals are to rename files first and maybe variables second. This means it parses inputs as though they were file names and splits off the extension before renaming them (this means it won't translate text after the first "." if there's no other "." after it like in your first example).

This works fine for variable names as well, since you really shouldn't have "." in variable names in most programming languages.

In the second example, it considers the file stem to include the first "." and the extension to be empty (from the last "." onward) as would be the case for an executable on Linux for example (although no "." is included in those cases). Thus, it translates the file stem and returns its translation as would be expected. However, since there's no extension to re-attach to it, stdrename "forgets" about the final "." in the process.

Could you clarify what use case you would have for this? While this is unexpected behavior, I'd prefer to make sure there's actually a reason for "fixing" this before doing so and making stdrename's code more complex than it needs to be.

@Gadiguibou
Copy link
Owner

Gadiguibou commented Nov 4, 2020

This also highlights another problem: --text mode really isn't appropriately named.

--text mode is really an --interactive mode (-i in most programs), in its current implementation. It's not designed to translate actual text.

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

No branches or pull requests

2 participants