Introduce completion candidates limit, minor fixes

[geraldus]

Don't merge yet, I didn't tested this stuff well and want to play with this before merge. Please review.

[gracjan]

Please use defconst instead of defcustom. After enough of testing we can arrive at a constant that will make almost everybody happy. If somebody detects a use case where that number fails then we would like to receive a pull request so that everybody benefits.

[geraldus]

@gracjan ok, I think a hundred completions is quite comfortable value.

[geraldus]

@gracjan I have no idea about this

In toplevel form:
haskell-sort-imports.el:128:1:Error: the function `copy-list' is not known to be defined.
make: *** [haskell-sort-imports.elc] Error 1

[gracjan]

Use cl-copy-list and do (require 'cl-lib) in the beginning of the file.

[geraldus]

Ok, but I didn't touch haskell-sort-imports.el myself. Will create a separate PR for this issue.

[gracjan]

I've fixed copy-list problem, just rebase over current master and you should be fine.

[geraldus]

Cool, thanks (:

[geraldus]

I did some quick tests, with hundred candidates limit dabbrev completions are still quite slow for short prefixes (2-4 chars), but performance increases for long prefixes. The most comfortable limit value for short prefixes for me is about 10-20 candidates.

I got some insight: what about to set candidates limit on the fly depending of prefix length, i.e. set smaller limit for short prefixes and increase it for long prefixes?

[gracjan]

I've never heard about dabbrev performance issues. Are you sure we are using it right?

[geraldus]

@gracjan, maybe I've took wrong words, I'm talking about issue described in #741 (here is a demo): while I typing nothing appears until I delay, note the "Scanning for dabbrevs" message in echo area.

[gracjan]

@geraldus: Code looks good. It would be good to find somebody besides me and you to play with this before merge.

[geraldus]

Surely, I want to make some more changes, e.g. #776.

[gracjan]

@geraldus: I was thinking about this a bit more. Questions:

1. Is that the limit is a problem only with dabbrev?
2. Is there a way to DO NOTHING about dabbrev in haskell-mode and leave this task to company-dabbrev-mode?

[geraldus]

@gracjan answers :D

1. No, it is not. ikirill also reported some issues about REPL completions with big projects, but in common case limit issue is more related to dabbrev/
2. I think that it is possible and I'm going to check it. When I implemented new synchronous completion mechanism I was not aware of dabbrev customizations in haskell-mode and that company have dabbrev backend out of box also. I will push more updates soon.

[geraldus]

@gracjan I've disabled dabbrev temporarily to test existing behaviour. I've already noticed that now completion candidates in comments are case insensitive. I need to find and look at mentioned dabbrev customizations in haskell-mode.

company-mode uses company-<dabbrev-code> backend when searching completions for identifiers and company-dabbrev when typing inside comments (and it is case insensitive). What do you think about this? Should user make global dabbrev customizations for this case if he (she) want case sensitive completions?

[gracjan]

@geraldus: I've found these custom variables:

• dabbrev-case-distinction
• dabbrev-case-fold-search
• dabbrev-case-replace

We can set the buffer-local so that case sensitivity is kept. Would that work for you?

[geraldus]

@gracjan I will be able to test this in about one or two days.

[gracjan]

@geraldus: hi, what do we do with this branch?

[geraldus]

There were made so many changes, I think we can close this for now, I'm still busy, apologize :(

[gracjan]

No problem. Take care of your stuff, return when you are ready. haskell-mode will be around.