Word Frequency: Initial Caps & Mixed Case don't find anything if Ignore Case is set about guiguts-py HOT 8 CLOSED

Guiguts 1 has similar behavior.

One option would be to disable All Caps, Initial Caps & Mixed Case whenever Ignore Case is set. Would need to decide what to do if All Caps was current setting, for example, then user turns on Ignore Case. Since it will be disabling All Caps, should the current setting change to the default All Words?

from guiguts-py.

One option would be to disable All Caps, Initial Caps & Mixed Case whenever Ignore Case is set. Would need to decide what to do if All Caps was current setting, for example, then user turns on Ignore Case. Since it will be disabling All Caps, should the current setting change to the default All Words?

I think it depends on how convoluted you want to get. You could generate a popup that says "Are you sure? This will disable your current selection", and then default to All Words if they proceed. That's what makes the most sense if you're going to keep Ignore Case as a valid option.

Or, another option could be to disable Ignore Case if any of the options that involves case sensitivity is selected.

from guiguts-py.

Another option would be to just disable Ignore Case and do a re-run if Ignore Case is on when an attempt is made to view All, Initial, or Mixed Caps.

from guiguts-py.

My 2¢ on the current ideas:

disable All Caps, Initial Caps & Mixed Case whenever Ignore Case is set

This is "clean," but IMHO it adds clicks, and it may not be obvious why some buttons are disabled. Tooltips could help with that....

generate a popup that says "Are you sure? This will disable your current selection"

This makes it obvious, though I try to steer away from attention-grabbing / blocking popups unless it's an unrecoverable decision (e.g., save file before closing window?). My personal POV is that such pop-ups are disruptive.

disable Ignore Case if any of the options that involves case sensitivity is selected

disable Ignore Case and do a re-run if Ignore Case is on when an attempt is made to view All, Initial, or Mixed Caps

These are "clean," but I feel like the user could miss the change in state, and later get an unexpected result. That is, if the user's mental model is "case-sensitivity is off" their mental model would be wrong. A pop-up solves that, but again, I like to avoid them. (That might be my own ADHD pet peeve--I dislike things popping up and disrupting flow.)

If I were designing this in a vacuum, I think I'd do something different. It seems to me that the intent of these commands is pretty clearly to use case-sensitivity. So I would leave the setting of Ignore Case as-is and run the test ignoring its value. Just behave as if it's set to False in all cases, but not actually change the state of the checkbox. (And it's probably worth mentioning that in the manual.)

To me, that seems intuitive, but maybe others disagree (I have found I don't always think like a typical user).

from guiguts-py.

... So I would leave the setting of Ignore Case as-is and run the test ignoring its value. Just behave as if it's set to False in all cases, but not actually change the state of the checkbox. (And it's probably worth mentioning that in the manual.)

To me, that seems intuitive, but maybe others disagree (I have found I don't always think like a typical user).

That could work, too -- and yes, definitely worth mentioning in the manual that "Ignore Case" is ignored (😁) for options where case sensitivity is required.

from guiguts-py.

So I would leave the setting of Ignore Case as-is and run the test ignoring its value.

I completely agree with this, and would have already done it that way except for one problem.

The tool needs to be completely re-run if the setting of Ignore Case is changed (or is treated as though it had changed). This is because it needs to build a dictionary of all the words in the file, with counts for how frequently they appear. If you have Ignore Case on, then you get one dictionary entry with the total number of occurrences of "an"/"AN"/"An"/"aN", whereas with Ignore Case off, you get 4 dictionary entries with individual counts. (Most of) the various display types then just change how that dictionary is presented to the user.

So, you would need to re-run the tool (behind the user's back, and ignoring the Ignore Case flag) then present the ALL CAP results, for example. Then when the user clicks on Hyphens, for example, you have to note that the current dictionary (that you just created behind the user's back) does not match the setting of the flag, so you need to re-run the tool again, but respecting the fact that the Ignore Case flag is set, and then display the Hyphens.

That seemed a bit messy to me, code-wise, especially since I suspect it will probably happen very rarely IRL.

from guiguts-py.

The tool needs to be completely re-run if the setting of Ignore Case is changed (or is treated as though it had changed).

Ahh... that's quite a wrinkle.

I briefly wondered if we could consider this to be a cheap operation (runtime and memory-wise), and run both at initialization, using the proper data source for each command without a re-run. (Users could still explicitly ask for a re-run.) But I assume we don't have enough real-world data to know (whether it's "cheap" enough). For users on lower-spec computers, or with larger projects (or both), it might be unreasonable to assume we can do it that way. And then I realized that the data is displayed in the dialog, which brings up a hairy UI problem if there were two data sets behind the scenes. I suppose in that case, I'd display whichever is "right" for the value of Ignore Case....

The above seems convoluted to me, so maybe better to call it a thought exercise and move past it. But I wrote it down in case it sparked any ideas.

Is it the case that when you change the value of Ignore Case it automatically re-runs the data? If so, then I think my new 2¢ is to disable the relevant buttons when Ignore Case is set to True. That might not be 100% intuitive for a user, but if there are tooltips on the buttons that indicate they are turned off when Ignore Case is checked, and it's mentioned in the manual, that may be good enough?

In short:

if ignore_case is true:
    disable buttons (mixed case, et al.)
    set button tooltip to indicate reason it's disabled
else:
    enable buttons (mixed case, et al.)
    set button tooltip to "normal" or else no tooltip
end if

Another option is to have universal tooltips that cover either case.

from guiguts-py.

Thanks @tangledhelix. I've implemented your new 2¢, and it looks OK - will get a PR up shortly.
Regarding performance, on my (fairly modern) laptop, with a 17,000 line text file, it takes about 3 seconds for WF to run, so that would double to 6 if we tried to run both case settings each time, or it would add 3 seconds if we made clicking the All Caps button do a re-run behind the user's back. I think your suggestion of disabling buttons but including a tooltip is a good compromise.

from guiguts-py.