No REPL running in

[angrycandy]

With this configured:

  (use-package elixir-mode)
  ;; https://github.com/tonini/alchemist.el/issues/371 Alchemist is dead for now.
  ;; (use-package alchemist
  ;;   :diminish alchemist-mode)
  (use-package erlang)
  (use-package inf-elixir
    :bind (("C-c i i" . 'inf-elixir)
       ("C-c i p" . 'inf-elixir-project)
       ("C-c i l" . 'inf-elixir-send-line)
       ("C-c i r" . 'inf-elixir-send-region)
       ("C-c i b" . 'inf-elixir-send-buffer)))

I run inf-elixir, see the iex buffer start, and then inf-elixir-send-line causes error message No REPL running in.

And I'm just starting to learn elixir with https://elixir-lang.org/getting-started/introduction.html so the directory has just one file, scratch.ex, for the tutorial code.

I'm using:

GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu) of 2020-03-26, modified by Debian
;; Author: Jonathan Arnett <jonathan.arnett@protonmail.com>
;; URL: https://github.com/J3RN/inf-elixir
;; Package-Version: 20210315.1723
;; Package-Commit: b526ce852886d1863163e054fcbbcbb83c55b32a
;; Keywords: languages, processes, tools
;; Version: 2.0.0
;; Package-Requires: ((emacs "25.1"))

[J3RN]

Hi @angrycandy! Thanks for opening this issue. This issue occurs when trying to send Elixir code to a REPL that exists outside of any Mix project. This is a thing that inf-elixir should support, but I've been conflicted as to what approach makes the most sense.

Either:

1. Limit the user to have only one non-project REPL. If the user uses the send-* commands inside a project, the string will be sent that project's REPL (current functionality) and if the user uses the send-* commands outside any Mix project, the string will be sent to the one-and-only non-project REPL.
2. Prompt the user for the REPL they want to send to if there are multiple. This has the nice property that users can send strings from outside of projects into projects and vise versa, as well as the ability to have many non-project REPLs. On the other hand, either the user will have to be prompted each time the try to send a string (inconvenient) or will have to manually switch the receiving REPL manually (akin to sql-set-sqli-buffer-generally). A hybrid where the user sets the recipient REPL once per buffer with the ability to change it manually might make the most sense.

I'd welcome your thoughts on this!

[angrycandy]

Thanks for the quick response @J3RN. My preference is a "hybrid where the user sets the recipient REPL once per buffer with the ability to change it manually".

[ZachFontenot]

Hey, a good place to look for some inspiration may be https://github.com/greghendershott/racket-mode. I don't know if the fact that it's both the major-mode and the repl mode will be a problem or not, but I think the way they handle repl buffers per edit buffer is by attaching each other's names to local vars. In projects, I think it sets the entire project to the one repl, or at least it can.

Also, FWIW, I find racket-mode to be a nice featureful and simple example of an interactive mode for emacs. Less powerful than say SLIME, Cider, or Alchemist, but obviously less complex.

[J3RN]

@ZachFontenot Thanks for the tip! :sparkles:

I think the way they handle repl buffers per edit buffer is by attaching each other's names to local vars.

Yeah, this is how I was thinking of doing it as well, but (IIRC) it implies a considerable rewrite of existing functionality. Sadly this has fallen on the back burner for me, no guarantee as to when I'll be able to get to it :sweat:

[J3RN]

After a little over a year, I've pushed a "fix" for this that I've been using locally for a month or so. I'm pretty happy with it, and I hope others are as well.

The big highlight is that the choosing logic is a bit more thorough and considers more cases. I published a wiki page that illustrates the buffer-choosing process.

The other good thing to know is that I added an inf-elixir-set-repl command that, when invoked, allows the user to choose a an existing REPL or to create a new REPL for inf-elixir-send-* commands to target. The setting is buffer-local, so different buffers can target different REPLs. If all else fails, this relatively brute-force approach should work :grin:

I'm closing this issue as the originally reported issue should be resolved (once the update rolls out on MELPA). If anyone has an issue with REPL-choosing logic going forward, please open a new issue :smiley: