GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
...eze when huge number of candidates for single-character matches)
Abort autocomplete when less than ac-auto-start characters (to avoid …
…freeze when huge number of candidates for single-character matches)
Have you tried setting ac-candidate-limit? And if you don't byte-compile auto-complete.el, it gets much slower for use.
I haven't set ac-candidate-limit (unless it is set by default). As far as I know I byte compiled all the files (using the included makefile), but I've not messed around with Emacs lisp very much, so I may have missed something.
However, with the patch I made, I've had no further slowdown problems - it cancels the autocompleting as soon as I'm down to 1 character.
Does this patch treat the requires source attribute?
I think this patch unconditionally abort auto-complete, ignoring requires attribute.
ac-auto-start can be t, so this patch could cause some error. But I think this practical workaround can be acceptable, though requires should be considered correctly.
I just tried to write code that considers the requires property. But I think it is impossible with the current architecture of AC: ac-prefix holds one prefix value. There could be different prefix values for different sources. If this PR is pulled, sources with custom prefix definition and requires property stop working. So, I suggest not to pull this PR for now and release 1.4. We can solve this after the code base was refactored for 2.0.