Allow “[^]” to work without “()” in it

[Palloxin]

This [^] doesn't work in the app and one need to write it this way: [^()] to make it work. Can u allow the first form too?

[sky10p]

I utilize Java's regex interpreter to verify the correctness of expressions. I'm not sure why that particular expression wasn't being correctly processed, but I will include it in my test suite and work on a fix as soon as possible.

[sky10p]

I believe this to be a standard practice, as '[^abc]' represents a specific type of expression used for negation. However, the correct form should be [\^] instead of [^()]. (I have tested and it works)

While certain websites may permit this expression, from a formal standpoint, it might not be considered correct. This is because it employs a negated group devoid of elements. akin to using '[]' without any elements, but in a negated form.

Do you agree with this assessment?

[Palloxin]

Can you add an "auto correct" feature to just target this? If an user types [^] in regex the app should add the () in it. What do you think? OR to just virtually accept [^] but processed as [^()] "under the table" Under the table means that the app will accept [^] but there will be a process in background that replaces it with[^()] Like a frequent customer that enters in a mcdonald and says "the usual" and the employee know that it is the food n° 34 in the menù.

[sky10p]

"I appreciate your suggestion about adding an 'auto-correct' feature for specific regex patterns like [^], but there are important considerations to take into account.

Firstly, it's crucial to understand that [^()} and [\^] are not equivalent expressions in the context of regular expressions. The expression [^()} means that it matches any character that is not '(' or ')'. On the other hand, [\^] is an expression that specifically looks for matches with the '^' character, along with any other characters included.

Given these differences, automatically converting [^] to [\^] could lead to misunderstandings in the regex patterns and potentially incorrect matches.

However, I do see value in your idea of enhancing user experience. Instead of automatic conversions, I suggest adding detailed error messages to the app. This way, when a user's expression doesn't work as expected, they can receive immediate feedback explaining why. This approach could help users understand and correct their regex patterns more effectively, without altering the intended functionality of their expressions.

In summary, while the idea of simplifying regex input is appealing, maintaining the accuracy and clarity of expressions is paramount. Providing informative error messages could be a more effective way to assist users in navigating complex regex patterns