Closed Inc0n closed 1 year ago
Firstly, my gut feeling is that this issue is not related to prompt at all, more about the read of the repl examing spork library at getline-async in netrepl/server. Secondly, this issue is more relevant to spork as of now, would it be more appropriate to move the issue into that repo?
Much more relevant to spork (or the particular emacs packages). Sounds less like a bug and more like a problem with the emacs package - there are better ways to hook up to a repl than some regex hacks
Much more relevant to spork
Thought so too.
(or the particular emacs packages)
I guess this would be as far as I can get on my own. Well there is no particular support from any emacs package for janet with netrepl...
EDIT: check out a-janet-spork-client for netrepl support.
Sounds less like a bug and more like a problem with the emacs package - there are better ways to hook up to a repl than some regex hacks
regex hacks? Hmm, fixing the comint-prompt-regex
in emacs for inferior buffer interaction I thought would be a very standard thing to do, no?
Unless you are refereing to using term
instead as the underlying support for process interaction? I just found julia-repl which does that.
Perhaps off-topic, but for future reference it appears that (the somewhat misnamed) https://github.com/sogaiu/a-janet-spork-client ended up working in this case.
TLDR: Janet repl works normally untill netrepl comes into the play.
Steps on to reproduce issue:
The issue is netrepl has a prompt characteristic like:
[<ip>:<port>]:<nth prompt line>: "
. This maybe considered as irregular for emacs. Here is my regex used for netrepl prompt:"^[^\n]\\[[0-9.]+:[0-9]+\\]:[0-9]+: "
(comint-prompt-regex). However, the process buffer in emacs will just be echoing the inputs. This would all work properly if connected to the netrepl in a terminal.Workarounds I can think of, allow customize of prompt so it could be the same as normal janet repl.