Breaking Changes (removed defcustoms)

Motivation for removal of haskell-interactive-mode:

• haskell-interactive-mode tries to do what can readily be done with Comint.
• We can argue that Comint is not well documented, but it comes with many features that are native to the REPL experience in Emacs, such as the history (C-<up>), Reverse search history (M-r), and the list goes on.
• Reimplementing Comint is a big task in itself and could be questioned if it is in scope of this project.
• Less code easier to maintain.

What is in this PR?

• New architecture.

  • Comint based inf-haskell replaces haskell-interactive-mode for querying the REPL process.
  • Only one session per Emacs process.
  • Only asynchronous process queries. If one query is already running, that query is terminated and the new query is run.

• previously haskell-doc.el, haskell-completions.el, ghci-script-mode.el and haskell.el used to depend on haskell-interactive-mode to talk with the ghci process. Now we use comint for the same thing from inf-haskell.

• Removed haskell-interactive-mode (The REPL)

• interactive-haskell-mode (The minor mode for interactive editing, such as completion at point, show documentation, jump to function definition etc) stays but works with inf-haskell instead of haskell-interactive-mode.

• ~Needs Docs~

• Added docs for haskell-doc.el and haskell.el AKA interactive-haskell-mode

Is there any chance of supporting multiple sessions per Emacs process with inf-haskell? Lot’s of people myself included use a workflow with Emacs where they only have one process running for everything and this new architecture seems to contradict that.

I have to vote no on this one as well -- it removes functionality that currently works well.

Looks like multiple sessions are important, so we will bring it back.

Note that there are people out there that think in opposite way: they think that managing multiple sessions is confusing and brings nothing to the table because the usual GHCi process is anyway about 4GB of resident RAM occupancy.

@vasanthaganeshk: Can you cut this somehow into even smaller parts? I mean something like this process:

1. Convert to comint, keep session management as it is. (this PR)
2. Fix session management properly. (some future PR)

Related: https://github.com/haskell/haskell-mode/issues/1527

Emacs runs on a single thread. If you are doing some task (opening a big file, starting some process, etc.), Emacs is going to get stuck for a while. In the meanwhile you might want to edit something in the other session, the only problem is that Emacs won't respond to C-x b or anything for that matter. Emacs was not designed to handle concurrent things. I think running two Emacs process will be the solution if you want to work on things simultaneously. Running multiple Emacs process is not taxing on a modern computer. I think doing things without leaving Emacs is a little overrated. I don't think multiple sessions is the correct solution to work on two different projects simultaneously.

@vasanthaganeshk, the 'freeze' takes only time during fork and exec, everything else is nicely parallel as internally Emacs uses the usual pipes mechanism.

I do not think running more then one Emacs is a viable solution: most GUIs out there (Windows, Mac OSX, Linux on desktop) make it rather hard to run more than one of an application at the same time.

Even though I agree in principle that having more than one session is questionable, there are clearly people out there that like this features. It would be a shame to take away their toy and we aren't going to upset them with this.

And, on top of that, it looks like this discussion is a great motivator to actually fix session management.

Multiple everything is the expected behavior in emacs, IMO.

I often work on multiple constituent subprojects (for example: explore a bug in some downstream project and then try out fixes or potential regression tests in an upstream library) as well as on unrelated projects (work and hobby, for example).

Big +1 from me on using comint more directly and idiomatically: this is a nice piece of work, and is a welcome move towards simplifying some of haskell-mode, which is arguably becoming unwieldy.

I agree that there should be no assumption of only one session per Emacs instance, but that doesn't need to be complicated to achieve:

At the very least, I should be able to set a variable like 'inf-haskell-buffer-name` on a directory-local basis, and then as long as everything uses that name to find the repl associated with the current haskell file, everything should Just Work™.

Anything else on top of that (e.g. functions that automatically create a suitable repl buffer name based) is optional gravy, IMO, and perhaps even undesirable: some people want a single Emacs-wide REPL, while others would like a separate REPL per cabal target (or group of targets).

@vasanthaganeshk I really like this PR. Are you still active in Haskell? I'd be interested in trying this out and improving it, maybe under some beta name like haskell-neo-interactive or something. There are some other improvements I'd like to make in this area, specifically around: per-buffer (per-target, really) management of interactive compilers, and replacing haskell-doc-mode with calls to :type-of.

Is there a TODO list of features that would be lost by using this? I'd be happy using a feature reduced version and if we want it merged into master perhaps we could add those features one at a time.

Is this still alive?

Is this still alive?

No, this is long since in conflict with master.

For the sake of haskell-mode's health I'd be quite keen to throw away all the existing REPL machinery and replace it with a comint-based solution like this, but I'm not working enough with Haskell right now to tackle it myself or to deal promptly with any fallout from changing existing behaviour.

For the sake of haskell-mode's health I'd be quite keen to throw away all the existing REPL machinery and replace it with a comint-based solution like this [...]

I can't put in words how much I agree. Maybe then we can leverage gud as well

I followed this PR in helping to cut haskell-mode and it worked out quite well. It was a great PR and thanks to the OA.

See https://github.com/tonyday567/haskell-mode/tree/removals

I'm going to shove this branch into doom, try it out for a few weeks and see how it runs.

In case you want some extra inspiration troubleshooting or extending this I have switched to my own roll of ghci in comint. It is heavily inspired by the one in python mode

Ok, so that's haskell-repl done!

Exciting to see you pick this up, @tonyday567. Happy to help land it here in due course.

@tonyday567 any news on this?