Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for expansion of default entries #5

Open
reedes opened this issue Dec 25, 2015 · 2 comments
Open

Allow for expansion of default entries #5

reedes opened this issue Dec 25, 2015 · 2 comments

Comments

@reedes
Copy link
Collaborator

reedes commented Dec 25, 2015

Currently limited to 300.

Disk technology advancements (e.g., SSD) allow for faster load times.

Allow for default entry list to expand slowly over time, such as by 50 entries a year.

reedes pushed a commit that referenced this issue Dec 25, 2015
@chris-ritsen
Copy link

chris-ritsen commented 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
Copy link
Collaborator Author

reedes commented 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants