Comint everywhere

[vasanthaganeshk]

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

[cocreature]

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.

[gregorycollins]

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

[gracjan]

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.

[gracjan]

@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: #1527

[vasanthaganeshk]

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.

[gracjan]

@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.

[lambdageek]

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).

[purcell]

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).

[fommil]

@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.

[fakedrake]

Is this still alive?

[purcell]

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.

[fakedrake]

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

[tonyday567]

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.

[fakedrake]

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

[tonyday567]

Ok, so that's haskell-repl done!

[purcell]

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

[rntz]

@tonyday567 any news on this?

[tonyday567]

@rntz Hi Michael,

I spent a bit of time teasing apart the comint usage, but I couldn't get a handle on the complexity. In my opinion, it would be a lot of work with uncertain outcome, and little hope of acceptance at the end.

I subsequently switched to https://gitlab.com/magus/haskell-ng-mode and found it had everything I needed.