Closed ellerh closed 7 years ago
Right, there certainly should be feedback. How would you feel about popping up a new window for this? Or, if there is just one or a few lines, display it in the echo area.
My idea was that there should be two separate channels: one for user interaction, and another one for communication between Emacs and Forth. I intended *forth*
to be exclusively for the user.
This isn't at all set in stone. I'm interested in opinions on this.
How would you feel about popping up a new window for this?
As a stopgap I currently trace forth-interaction-send
so that the output is in fact displayed in a seperate window. The problem with popping up windows is that somebody has to close them. Automatically closing windows is a fiendishly difficult problem; manually closing them isn't so great either.
Or, if there is just one or a few lines, display it in the echo area.
Yes, that would be good. Especially if the line is just the ok
prompt.
My idea was that there should be two separate channels: one for user interaction, and another one for communication between Emacs and Forth. I intended forth to be exclusively for the user.
It seems to me that in Forth it's difficult/uncommon to have multiple channels because everything seems to be designed around a single connection over a serial line (often to a microcontroller). E.g. stderr and stdout are not separate. So I think the "natural" choice is to use in-band markers (like terminal escape sequences) for the Emacs<->Forth communication. Or maybe I'm not understanding you correctly.
I implemented the feedback. If the output is at most two lines, it's displayed in the echo area, otherwise it's inserted into the *forth*
buffer. (By the way, I didn't find a "display buffer in other window, but don't make it current" function. Is there one?)
You're probably understanding me correctly. You're right that having multiple channels is difficult. I'm thinking "conceptual channels". Those channels would have to be multiplexed onto the single channel we have somehow, but that's an implementation detail.
Fixed in b8024ac331d926a74ad938c508ed38db8f050da7.
forth-load-file
doesn't hides the output of the subprocess which makes it rather diffucult to tell what is going on. I think it should insert the output in the*forth*
buffer and make sure that the*forth*
buffer is visible.