Hello, me again, with more things related to the neverending story of the Emacs mode.
The problem
Right now, the mode communicates with the backend APL interpreted by issuing normal APL commands and waiting for the responses. As I have added more and more features, the preoutput filter (a function that processes all output coming from the APL interpreter) has become an overly complex beast. It's a state machine that has become quite unwieldy.
Since the programmatic interactions with the interpreter runs together with the end-user interactions, there is the potential for interference. For example, if I write a program that asks the user for input, and while waiting for input I try to update a function from the normal editor, the program's input will be clobbered by a call to )SI that is issued by Emacs to check if the function is on the )SI stack.
The solution?
I would very much like to have access to some kind of separate communications channel where I could issue APL commands and read the result. Ideally this would be a listener on a socket (Unix domain, if available otherwise a TCP listener on localhost). Emacs could then connect to this socket, and issue normal APL commands to it. Only output from these commands would be sent back on the socket, making it completely separate from the main interaction.
I'd presume a lock would be needed to prevent the back-channel and the main interaction from running commands at the same time. This would not present any major problem on my end.
What do you think about this? This would make things significantly more robust in the Emacs mode.
Alternative approach
Another approach I was considering was to take advantage of the new native call features to implement this back-channel stuff in APL itself. However, some kind of support for callbacks or threads or something like that would be needed so that Emacs can issue commands while the interpreter is waiting for input from the user.
Regards,
Elias