Completion mechanics haskell-completions-grab-prefix implementation

[geraldus]

This is long story. I want to make some improvements on completion stuff.
I will add changes step by step because a bit short in time and made this PR to have some feedback and help.

[geraldus]

Function haskell-grab-pragma-or-ghc-option-prefix handles all stuff described here, and also returns prefixes for pragma names itself, e.g.
{-# OP| ⟹ OP
{-# LANG| ⟹ LANG
I've merged this functionality, because both cases occurs inside {-# #-} comment.

Any thought about how to make it a bit readable?

[geraldus]

@gracjan updated

[geraldus]

the rest should be easier, but I want to fix presentation buffer first

[geraldus]

In some cases it is better to provide completions if point is not at whitespace, for example when point is at closing parenthesis: (ma|) - point is after a character. Any thoughts?

[geraldus]

Well, I believe I've covered all prefix cases originally defined here¹. Now I can write a general function for grabbing prefix at point which first invokes pragma-prefix function and if its result is nil it returns the result of identifier-prefix function.

And after that I can update completions at point function: split it to synchronous and asynchronous ones.
Synchronous function will operate like existing CAP-function, and asynchronous can provide all completions using REPL, i.e. provide completions for GHC options and language extensions running :complete repl ":set <prefix>".

Have any thoughts?

[gracjan]

Sound like a very good idea!

[geraldus]

A little progress here

[gracjan]

Are there some commits here that you could spin-off as a separate pull request? This is getting rather big...

[geraldus]

@gracjan I think I'm done with prefixes, can you review everything that done so far and it is could be merged after squashing some commits. The next part is to update completion functions (still some research needed).

I have no strong opinion on some key points though:

1. Currently, all grabbing functions return nil if mark is activated.
2. Should completion list be provided when typing in the middle of word?

[geraldus]

Is it okay to reserve copy rights to community rather than a person?

[geraldus]

@gracjan I think GPL licence itself (COPYING file) could be spinned-off. Also if GPL is the preferrable licensing method it would be nice to have some notice about licensing on Contributing page.

[gracjan]

Overall this looks good to me. Tests provide assurance that this also works.

License stuff got merged in another commit, so it can go away. Please squash what is there to squash.

(Note: when you commit you can use git commit --squash COMMITID that will generate specially formatted commit message for commits that are supposed to be squashed.)

[geraldus]

@gracjan I will tidy up things this evening, however, I'm still have no strong opinion about completions in the middle of strings. Initially I've decided not to grab prefixes in the middle of string (hence no completions in this case) being influenced by some comments in company-mode sources¹. But, when I write Elisp code company-mode works even in the mid of the word and it feels quite comfortable and useful, so this was wrong decision from the very beginning and provide no completions in the middle of string is likely a misfeature.

Now I'm leaning to other direction, but I don't know and can't recall how completions provision works in other packages (like auto-complete) and/or in other editors/IDEs _(I can check how Sublime works in the evening).

[gracjan]

I would love completions to work inside comments! Note that QuasiQuotes are done using strings, so having completions there can be also useful. I vote for having completions everywhere!

[geraldus]

OK, I've tested Sublime Text and it does not completes in the middle of string, so does company-mode with elisp code. But them both provide completions when point is at punctuation, e.g. co|), com|,, comp|., and etc, and we really need it too for haskell-mode (currently it's not supported).

I also want to have completions inside comments and string literals, this is one of the reasons of my efforts on completion improvements. Currently, it is possible to grab prefix inside comments and strings, but I think I need to implement special completion type for these cases, e.g. 'haskell-completions-literal-prefix. I plan to make some hacking around dabbrev-expand function to get completions in this case, and as a free bonus we'll have a completions for local identifiers (in let blocks) and newly added things with unsaved buffer.
If I'm not mistaken REPL does not provide completions for local identifiers, also it is required to reload file to have completions for things added since last load. Similarly, it is required to save buffer when completions come from TAGS file.

As for quasi-quotes, my current haskell workflow have lot of them, so if it's possible to make QQs support a bit better I'd love to have it. But I have nothing to say about this stuff yet.

[geraldus]

pinging @gracjan, please review carefully final update

[gracjan]

Code is nice, can be merged as is. Do you anything more you want to do about this?

How can I see this working besides of unit tests?

[geraldus]

@gracjan nope, this is supposed to be merged as is, the next PR will touch completion functionality itself. I'm testing this stuff manually running M-: (haskell-completions-grab-prefix), etc. at various places of arbitrary haskell file.