If it runs into all caps, it lowercases first, otherwise it won't so acronyms survive. It's also wise to quotes and various sentence endings. And it handles a couple of false positives (acronyms with periods are not end-of-sentence and neither are quotes after a comma).
When you have time, would it be possible in the case of all caps to treat acronyms with periods like you do otherwise?
Finally, would it be difficult to use a user-supplied word list of words to always use all caps? I think we may have discussed this before, and I know a common list is huge. But maybe for specific user and/or company and/or industry it might make sense.
Again, not urgent at all. Please work on only when you have the time and interest.
You mean just preserve them? And remove the periods?
The title case macro has a list (small words) of words that should not be capitalized. You could also certainly have a list of acronyms. And you could read that list from a file if it was very long. (Ah, but where would that file live?)
But the sentence case macro works differently. It doesn’t look at words like the title case macro. It looks at sentence boundaries and those false positives.
Which means it would just require a separate operation to go through the selection to look for the acronyms. Not a big deal.
Updated to handle bug capitalizing letters following an apostrophe in contractions. We're just lowering casing them in the fourth line rather than try to fix them in the third line where they are capitalized.
Yes, it's an interesting problem (for which, as you can see above) I was drafted. It's a lot harder to identify a sentence than it might seem.
Your macro is an admirable attack on the problem. It also illustrates just how hard it is to use actions to deal with a complex situation in Keyboard Maestro's visual programming language. You can get tied up in knots pretty easily, scrolling around to find out where you are (I'm in the middle of just such a project right now, in fact).
It's a lot harder to identify a sentence than it might seem.
Yes, my version was just at start, after line-breaks and after dots. Did not even think of quotation marks or other endings like "!" "?" as in your version.
I think regular expressions is limited by the set of logic is has as its disposal, and can easily get very expensive if trying to cater for every possible form a sentence structure can take.
I think text scanning methods are possibly more well-suited to this situation, as one can define custom logic as they please, and as a string only ends up being processed once, might even be more efficient.