Code duplication between haskell-process-do-type, haskell-process-insert-type

[bergey]

haskell-process-do-type has two code paths, one to insert a type, one to show it in the minibuffer. They share no code, and for example use different rules to decide what string to pass to ghci.

I'm happy to make a PR refactoring the common code into a single function, if the maintainers agree that this would be an improvement.

[gracjan]

Hmm, interesting.

I remember Artur working on this and it proved problematic to merge those code paths. I'm not sure what the problem was, though.

If you can merge it then great, go ahead!

[geraldus]

I'll be able to have a look tommorow.

[geraldus]

Oh, guys, I'm a greatest lier, apologizes, I have not looked at this yet. Maybe on Thuesday...

[bergey]

No rush, I have plenty of other projects. =)

[geraldus]

Ok, the difference is if user just wants to see a type, do-type shows result in the minibuffer or in popup window depending on presentation mode configuration. If user wants to insert a type, it is not necessary to show result, because it will be inserted anyway. So there is two diffrents ways of functionallity. Does it makes some sense? Or do you have other questions?

[bergey]

I understand the difference in output. I was surprised that this leads to different regexen to match the Haskell identifier, and to decide whether to add parens in the ghci query. I jumped to the conclusion that the two functions should do the same thing up to the point where they output the type differently. Looking now, that may be wrong.

Is it documented anywhere that haskell-process-do-type will message the type of the expression in region, but haskell-process-insert-type will ignore the active region and pick the identifier at point? Or that neither will give the type of an operator?

I thought that merging the code up to the point of display might be the first step towards documenting, and possibly expanding, their functionality. If you think they're better off separate, feel free to close this issue, and I'll take a stab at documenting the current behavior, at least.

[gracjan]

Thinking about this issue again it might be more productive for you to contribute to Haskell IDE Engine because it is supposed to fix this and many other problems.

[bergey]

Yes, that makes sense. Thanks for the advice.