[Change Case] The Change Case extension often doesn't result in the transformation requested. about extensions HOT 18 CLOSED

Thanks @erics118. It seems like I'm not the only one perplexed by the behavior of this extension, which I understand is downstream of @blakeembrey's change-case library.

I'd really like something functional though; when I was an Alfred user, I used @derickfay's case converter workflow, and it worked as expected.

I'd really like Raycast's Change Case extension to be the best of them all — even if that requires some work. While I can't code for shit, I'm happy to work through how to improve the current functionality to match user expectations if you're up for it? Perhaps by adding some preferences, as @pernielsentikaer has proposed elsewhere?

from extensions.

I've made the PR, #12586 . Please take a look at the README.md file, where I added some clarification regarding behavior.

One thing I'm not too sure about-should I enable this preference as a default? This would change the workflow of some users (likely more advanced users) who use the context-aware tranformations.

On the other hand, there have been a lot of issues regarding the "incorrect" behavior of the transformations
#10594 #11867 #11150 #11382

from extensions.

@raycastbot keep this issue open

from extensions.

Thank you for opening this issue!

🔔 @erics118 @pernielsentikaer @nagauta you might want to have a look.

from extensions.

Here's my test file:
Change Case Tests.csv

from extensions.

See #10594 Feel free to add docs clarifying the behavior, or a preference to lowercase the text before other transformations

from extensions.

BTW, this is not my chance case library so any specific issues regarding the implementation of the algorithm should be posted in https://github.com/blakeembrey/change-case

from extensions.

I’ll still try to explain some of the patterns in the table

Capital case: this change case library also includes the ability to do convert between different cases, eg camel case to snake case, so this explains what you see in the mixed case tests.

Sentence case: it doesn’t perform an automatic lowercasin. See #10594

Title cae: I’m not sure how title case is implemented, but again, no automatic lowercasing is done

Upper first: upper first is uppercase first of each line, so it’s working correctly. This also relates to a larger issue - there are some duplicated cases (eg two names for the same function) and some cases that I feel aren't too useful. It's pretty messy and I've considered potentially removing them. Also like here, upper first, is a pretty vague name and it's not clear what it really does. Perhaps I'll just remove it

from extensions.

Thank you, @chrismessina – I'm happy to lend a hand as long as it isn't useless, I'd also like to see Raycast's CC extension to be the best but I'm afraid of wasting my time...

from extensions.

I'm still interested — can we come together on a game plan? What would be most useful to start with?

from extensions.

@chrismessina I've added an option to first lowercase all text before further transformations. It seems to work more like what an average user would expect.

Here's a CSV file including your original csv file, and new rows underneath showing the new behavior. What do you think?

Change.Case.Tests.csv

from extensions.

Thanks @erics118. I agree we should discuss defaults and user expectations.

The option you added defines what happens "out of the box", and the out of box behavior should align with the majority of users' expectations:

However, I'm not convinced that unchecked should be the default.

I see that you've added a lengthy explanation for the current default behavior to the Extension Store listing, which only amplifies this idiosyncratic behavior. If users install Change Case directly from the in-app Raycast Store, they'll never see this information.

I have filed a separate issue relating to the redundant cases to simplify this extension, but for now I propose lowercasing input by default, and then performing the transformation. Especially in the cases I outlined (Capital Case, Sentence Case, Title Case, and Upper First) the transformations will conform to the expectations set by the name of the transformation.

To that end, I have two mutually exclusive suggestions:

1. Invert the behavior of your new checkbox; the text of the option should be "Preserve capitalization" and it should be unchecked by default.
2. Remove the checkbox altogether and create new variant transformations for Capital Case, Sentence Case, Title Case, and Upper First that "Preserve capitalization".

It seems to me that Option 1 may be the simplest to implement, but may also introduce a breaking change for the 12K+ existing installs. Option 2 adds complexity but wouldn't break the current behavior.

WDYT?

from extensions.

I think that for simplicity, both for me as the developer, and for the user to understand what the how to configure the extension, we should go with option 1. I feel that Option 2 creates four additional transformations that clutter up the existing huge number of transformations available.

The major concern with this change is that users who frequently make use of transformations such as camelCase -> snakeCase (this use case has popped up in the Slack before), and I don't want their workflow to be completely messed up.

I think we can simply resolve this issue by making the preference required (which forces the user to make configure the preference before continuing to use the extension). The aforementioned users probably are well-versed enough to understand the change and the reasoning behind it. What do you think?

from extensions.

As long as the required option is not a checkbox, your suggestion works.

Thus you could rename "Behavior" to "Preserve capitalization" with an empty "Yes/No" dropdown, and a tip about impact of the choice.

Seems simple and straightforward.

from extensions.

What's wrong with a checkbox? I think I'm missing something

from extensions.

What's wrong with a checkbox? I think I'm missing something

How can you tell if the user made a selection?

That is, if it's required and unchecked by default, the extension can't know whether the user proactively made a choice, so you haven't really made the option "required".

The only way to make the choice "required" is to provide a "No choice" or unset option; as long as the option is unset, the "required" status is unfulfilled:

• No choice
• Yes
• No

from extensions.

Okay, I see.

But, what about the case when the user doesn't actually make a selection and goes with "No choice"?

from extensions.

Haha, well — the question we're trying to answer is: "how do we make setting a configuration option required?" But the extension should work w/o the user need to customize it, so let's revisit what you said above:

I think we can simply resolve this issue by making the preference required (which forces the user to make configure the preference before continuing to use the extension).

Perhaps we shouldn't make it required after all (again, because the extension should work automatically without configuration — people just want to change the case of their text!). It's only if they have more technical requirements (e.g. developers) that they'd look into the extension settings to see if "Preserve Original Capitalization" were offered).

So let's go back to Option 1:

Invert the behavior of your new checkbox; the text of the option should be "Preserve Original Capitalization" and it should be unchecked by default. It should not require user interaction to be set (and therefore shouldn't be "required").

I don't know if there's a way to communicate to the user that the default behavior has changed, but upon the next release, this new default should be enabled. Whether you check the box on behalf of existing installs to maintain consistent behavior is up to you — that is, if that's even possible.

from extensions.