You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have the opposite idea with my list (more is better) and wanted to share it. I've got about 39500 entries in my list. This has been built up over the past five years:
This is by far the largest list I've seen anywhere; mine it for content if you want. I've never had any feedback on this by anyone else, but you should be able to source that file and not be terribly surprised by any of the corrections doing the wrong thing, except for some of the shorter words. The philosophy behind it is to autocorrect words to what was meant to be typed. I do not try to fix capitalisation, use few contractions, no abbreviations of long words, single-word corrections only, plural word endings should generally have an 's' on the incorrect word, and no synthetic additions (i.e., adding entries for uppercase versions of the same word is a waste of time. Additionally, attempting to hit the shift key can create different typos). Any ambiguous entry that autocorrects to the wrong word, for any reason, is removed. The result allows for typing in the fastest, sloppiest manner possible while still maintaining accuracy of intent. Most of these were generated on Apple keyboards. I've got a function that creates an input() at the bottom pre-filled with the first spelling suggestion for the word that appends another iabbrev line to the abbrev source file:
This makes adding new entries trivial and quick - I usually move between spelling errors with vim-unimpaired's bindings, then leader-d, hit enter or retype the word, then [s to the next to repeat the process. Generating typos becomes helpful rather than annoying. I generally get about 40wpm with spelling correction included while doing stream-of-consciousness type writing with this setup.
Startup times are a huge problem, of course. Time on my laptop is about 12 seconds, 7 seconds on my desktop. Sourcing the file again without clearing the abberv map is even slower. Internally, it's stored in the same list as mappings for key commands. I recently discovered that nvim has async job control, which can load a script after the program has started. The result is slower than having them load at startup, but I can type "teh" for about 23 seconds before it starts getting corrected to "the".
I like your idea of easily adding new entries and a rich library of abbreviations.
The long startup times are especially a problem with litecorrect's buffer-scoping -- they must be initialized for every buffer where you're word processing. (You might be writing code in other buffers where you don't want the abbreviations, hence the scoping.)
I'll definitely scan your list, looking especially for those corrections that are both common and short. That's where litecorrect's strength seems to be. Thanks!
Activity
Allow for expansion of default entries #5
chris-ritsen commentedon Jul 10, 2016
I have the opposite idea with my list (more is better) and wanted to share it. I've got about 39500 entries in my list. This has been built up over the past five years:
https://raw.githubusercontent.com/chris-ritsen/vimrc/master/abbrev.vim
This is by far the largest list I've seen anywhere; mine it for content if you want. I've never had any feedback on this by anyone else, but you should be able to source that file and not be terribly surprised by any of the corrections doing the wrong thing, except for some of the shorter words. The philosophy behind it is to autocorrect words to what was meant to be typed. I do not try to fix capitalisation, use few contractions, no abbreviations of long words, single-word corrections only, plural word endings should generally have an 's' on the incorrect word, and no synthetic additions (i.e., adding entries for uppercase versions of the same word is a waste of time. Additionally, attempting to hit the shift key can create different typos). Any ambiguous entry that autocorrects to the wrong word, for any reason, is removed. The result allows for typing in the fastest, sloppiest manner possible while still maintaining accuracy of intent. Most of these were generated on Apple keyboards. I've got a function that creates an input() at the bottom pre-filled with the first spelling suggestion for the word that appends another iabbrev line to the abbrev source file:
https://github.com/chris-ritsen/vimrc/blob/master/plugin/functions.vim
This makes adding new entries trivial and quick - I usually move between spelling errors with vim-unimpaired's bindings, then leader-d, hit enter or retype the word, then [s to the next to repeat the process. Generating typos becomes helpful rather than annoying. I generally get about 40wpm with spelling correction included while doing stream-of-consciousness type writing with this setup.
Startup times are a huge problem, of course. Time on my laptop is about 12 seconds, 7 seconds on my desktop. Sourcing the file again without clearing the abberv map is even slower. Internally, it's stored in the same list as mappings for key commands. I recently discovered that nvim has async job control, which can load a script after the program has started. The result is slower than having them load at startup, but I can type "teh" for about 23 seconds before it starts getting corrected to "the".
reedes commentedon Jul 11, 2016
I like your idea of easily adding new entries and a rich library of abbreviations.
The long startup times are especially a problem with litecorrect's buffer-scoping -- they must be initialized for every buffer where you're word processing. (You might be writing code in other buffers where you don't want the abbreviations, hence the scoping.)
I'll definitely scan your list, looking especially for those corrections that are both common and short. That's where litecorrect's strength seems to be. Thanks!