comint-simple-send: Wrong type argument: stringp, nil

[Munksgaard]

I'm getting the error comint-simple-send: Wrong type argument: stringp, nil when trying to C-c C-l a Futhark file. This is with version 0.2 in emacs 25.2.2.

[athas]

Do you have a stack trace?

[Munksgaard]

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  comint-send-string(#<process futhark> ":load skifte-punkt.fut\n")
  comint-simple-send(#<process futhark> ":load skifte-punkt.fut")
  apply(comint-simple-send (#<process futhark> ":load skifte-punkt.fut"))
  futhark-comint-load-file("skifte-punkt.fut")
  eval((futhark-comint-load-file "skifte-punkt.fut") nil)
  eval-expression((futhark-comint-load-file "skifte-punkt.fut") nil)
  funcall-interactively(eval-expression (futhark-comint-load-file "skifte-punkt.fut") nil)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)

[athas]

Version 0.2 doesn't mean much. Are you using the newest version? Have you saved the file? I really don't see what futhark-mode.el could be doing wrong. Is the *futhark* process already running?

Wait, Emacs 25.2.2? Why so old?

[Munksgaard]

Version 0.2 doesn't mean much. Are you using the newest version? Have you saved the file? I really don't see what futhark-mode.el could be doing wrong. Is the *futhark* process already running?

Apparently I'm running 20200123.931 from melpa, which I'm guessing is the latest version. 0.2 was just from the source file.

I'm thinking that my problems are due to some interaction problems between futhark-mode and interactive-haskell-mode: If I start a new Emacs process, open a .fut file and C-c C-l, there is no error, but if I first open a haskell file in the futhark project, run interactive-haskell-mode and C-c C-z, I get the error above. interactive-haskell-mode seems to create a buffer named *futhark*, same as the one created by futhark-mode. Perhaps that could be the cause of the problem?

Wait, Emacs 25.2.2? Why so old?

Blame your favorite combination of Ubuntu and Science IT.

[athas]

Yes, interactive-haskell-mode is the problem. futhark-mode expects that any *futhark* buffer belongs to it.

[Munksgaard]

I see that the futhark process and buffer names are hard-coded in futhark-comint.el. Perhaps we should be a bit more clever about this. I see that interactive-haskell-mode smartly creates a new buffer *futhark <0>* when it is run after running futhark-comint-load-file, although it does kill the old futhark process,