Dewi Morgan wrote:
Happy to maintain it, if you tell me what needs doing and where I should stick the uploaded version. In the absense of guidance, I'll create a wiki page similar to
http://www.autohotkey.com/wiki/index.ph ... er_Control and upload to ~anonymous in the same way as on that page.
I'd prefer a one-click download; so you could put the file anywhere that it stays a .ahk file (perhaps
www.autohotkey.net to provide best performance). In other words, I prefer no intermediate page unless you think some kind of introduction or documentation becomes necessary.
Dewi Morgan wrote:
1) Personally, other than sections which need to be separated because they perform different tasks that users may want to disable en masse (the -ing fix, diacritics) I'd be inclined to merge the lists from various sources in order to prevent duplicates, and because the source isn't relevant to the user. Sources should probably be credited in the comments at the top of the script instead. This would prevent failure to credit sources for words that had been removed from their section due to duplication, and would mean that a single alphabetised list would be considerably easier to search.
That sounds great.
Dewi Morgan wrote:
2) ...So to globally grab Win+H for a function that some people will not even use seems intrusive, and will break any program that wants to use that hotkey. So I'd be inclined to instead have "add an entry" as a rightclick context menu thing, with an optional user-configurable hotkey.
I believe the hotkey was originally Jim Biancolo's idea. From a benefit/cost point-of-view, having some kind of global hotkey enabled by default probably does more good than harm, especially when you take into account existing users (i.e. backward compatibility). On the other hand, existing users would have to explicitly upgrade to the new script you create, so maybe disabling the hotkey by default would be acceptable.
Dewi Morgan wrote:
3) I would probably retain all typos from all current lists. While I agree that "it seems best to omit the really obscure/personal misspellings to prevent the size from ballooning too much", figuring out which words those are would be awfully tricky and time consuming, unless there's a simple way that I'm missing. I have tended to only add terms where they're regular typos, where they're included in "most frequently misspelled" lists (eg the TextTrust press release), or where they're included in "autocorrect" lists. This prettymuch guarantees that there'll be a fair number of people who'll make each typo.
That sounds reasonable. I just wanted to avoid having more than 30% of the list comprised by off-the-wall misspellings that most people would frown upon if they actually saw them.
Dewi Morgan wrote:
...the diacritics list. My reasoning for including the latter is that creating diacritics in most keyboard layouts is complex enough that most people will not know how to create, say, an umlaut.
I'm wary of including that due to possible interference with programming languages such as AutoHotkey, which uses backtick as an escape symbol. However, I'm not sure exactly what you have in mind, so maybe there's no cause for concern.
Dewi Morgan wrote:
In the extreme case, it could keep a count of which typos people make and how often, and auto-upload that anonymously every month or so. That'd show which corrections are not being used. But the CPU taken by the monitoring would considerably outweigh any saving made.
That would be an interesting project; but I agree that it's too costly.
Dewi Morgan wrote:
4) An application exclusion list is important, I feel: some applications should probably be excluded, such as those with their own autoreplace systems, programming IDEs, etc. The diacritics section probably needs a longer list, and should have a context-menu option to disable it completely.
If it's verified that the autocorrect script actually interferes with a particular app, I agree that it would be nice to exclude it. Perhaps
GroupAdd and
#IfWinNotActive ahk_group will be sufficient.
Dewi Morgan wrote:
5) Either maintain two lists (commonwealth and US spellings), or have a toggle to switch between them. Though where possible, most corrections should probably just avoid the distinction, eg correcting "collour" to "colour", and "collor" to "color", reguardless of their locale preferences.
Although that's pretty ambitious, I'm sure many users would welcome it if you have the time.
Dewi Morgan wrote:
Sadly, I am largely unaffected by Moore's law, so as a test I took your list and appended my code blocks to the end. According to the task manager, on my 500MHz machine, cpu usage hit 4% if I typed frantically. If I just dragged my fingers across the keyboard, I got it to hit 9%.
Ah, it's good to know the performance is acceptable even on older hardware. Thanks for the test.
Dewi Morgan wrote:
Incidentally I found a (probably-known) bug in the forums "copy" link while doing that test: if you click "copy" to copy the diacritics block, all non-ascii characters are replaced by "?" but if you manually highlight and copy, this does not happen.
I'll PM that to Titan (its author) in case he can fix it.
Thanks for making auto-correct better for us all.
Login
Register
FAQ
Search
vPhiLho 
