Closed aikrahguzar closed 10 months ago
Personally I'd suggest packaging it separately. Yes, many haskell-mode users also use hoogle, but I'd rather encourage multiple small packages that are each maintained actively. Currently there is little support for haskell-mode, and if – for example – someone writes a modern treesitter-based haskell-ts-mode
and distributes it separately from haskell-mode
, then it would be better for everyone if users could install the same hoogle package.
Personally I'd suggest packaging it separately. Yes, many haskell-mode users also use hoogle, but I'd rather encourage multiple small packages that are each maintained actively. Currently there is little support for haskell-mode, and if – for example – someone writes a modern treesitter-based
haskell-ts-mode
and distributes it separately fromhaskell-mode
, then it would be better for everyone if users could install the same hoogle package.
Makes sense, thanks! I will try to get it added to GNU ELPA soonish.
I forgot to mention an additional point, which is that it's rarely a good idea for a major mode package to have a dependency on a "framework" such as "consult" that not everyone would want to have installed: haskell-mode
would have to depend on consult
via consult-hoogle
, and would force installation. The alternative of having a "soft" (or undeclared) dependency leads to compilation errors or general unsafety, so it's better to have separate packages.
The package is now finally on GNU ELPA https://elpa.gnu.org/packages/consult-hoogle.html
Yay, I just saw that pop up in my *Packages*
list. Nice work!
Hi, Sometime ago I wrote an interface for
hoogle
using the async completion and preview functionality provided byconsult
. The code can be found here https://codeberg.org/rahguzar/consult-hoogleThe code needs some reformatting which I will do but otherwise I think it works pretty well. I wanted to ask the maintainers here if it makes sense to bundle such a thing with
haskell-mode
. I think that will be a good thing. The only downside I see is theconsult
dependency but that can handled by making it optional so that people not usingconsult
don't have to do anything. If the inclusion needs some modifications, I can put in some work for that.If on the other hand, you think a separate GNU ELPA package will be better, please let me know.