-
Notifications
You must be signed in to change notification settings - Fork 347
[Discussion] Make haskell-indentation external, editor agnostic project #1086
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I had some similar thoughts, however, Emacs provide a way to package authors control various aspects of Emacs behaviour such as indentation, pairs, completions via special variables, e.g. One thing I can say for sure we can not depend on any external tool, haskell-mode should be self-sufficient. There is very promising Haskell IDE Engine project and if indentation stuff will be added to it, we could use HIE to handle indentation, but even in this case it should be optional and it would be great to provide some fallback. I think future of HIE is still unclear for now, it may or may not become tool number one for any kind of Haskell workflow. Even if we remove indentation logic from haskell-mode we should have some handy customizations. One last point, when I started contributing to haskell-mode I had 0 experience in Elisp, but it was super easy to learn it. I think what we really need is greater number of active people involved in process, I think there are many things we can improve and simplify and make haskell-mode more qualitative and outstanding. |
@arybczak: Possible and doable although a lot of work. Note also that indentation has a couple of unintuitive requirements:
There are projects like structured-haskell-mode and ghc-exactprint, but those work only with syntactically correct Haskell source files. |
Can you provide an example of limitation arising from having indentation helper as external application? My understanding is that if you treat the helper as referentially transparent function, i.e. you pass a config and a fragment of Haskell code and you get a list of indentation points, you're good. A conversion from haskell-mode config to helper config would be needed, but that is not a problem.
That is a noble goal, but it creates unnecessary duplication of work. How many editor developers had (and will have) to do the same thing over and over again to get indentation in Haskell to somehow work? I've looked at HIE, but I don't think there are currently any efforts to solve this specific problems so far. Yes, these requirements make it quite challenging as this prevents us from reusing any existing parser library like haskell-src-exts, unless one makes it return partial syntax tree in case of errors and also contain information about indentation of the source code. Quasi-quoters are a whole issue altogether, but this could possibly be solved e.g. by custom plugins written by their authors or something. Ultimately the same set of issues applies no matter if the development of indentation-mode continues in Elisp for Emacs only or as the external, editor agnostic application, but I would think that the probability of these problems getting solved is much higher in case of the latter. |
@arybczak if such helper indentation application will support all possible platforms suitable for Haskell+Emacs workflow I guess this won't be an issue. |
I guess the following holds true:
I'll close this ticket. Please reopen if you have such a tool running :) |
Hey,
I've recently realized that even though haskell-indentation has seen a lot of improvements recently and is quite pleasant to use, there are two fundamental problems:
Both of these severely reduce the pool of people who would be willing to improve the state of the project. Therefore I wonder if we could benefit from porting haskell-indentation to other language (Haskell seems to be the obvious choice here) and making it an external application so that editors can just pass the code and receive a list of possible indentations to use.
Any thoughts?
The text was updated successfully, but these errors were encountered: