Experimental branch to replace comint-mode with term-mode

[ellerh]

I think it could be useful to use term-mode instead comint-mode, because term-mode supports cursor positioning. Some form cursor pisitioning is needed if we want to support things like Gforth's status line at the bottom of the window. And I have to admit, that Gforth's status line is kinda useful. Another advantage of term-mode would be, that we get TAB-completion simply because Gforth already has some form of TAB-completion.

This branch adds a file forth-term.el that is basically a replacement for forth-interaction-mode. You can try it out with M-x forth-term. The *forth-term* buffer should work like a normal xterm. The only advantage over running a Forth in a xterm is that we can pop up the *forth-term* window in response to commands like forth-term-include.

There are also very primitive commands that call Gforth's EDIT, BROWSE and WHERE commands from Forth source files. Those rely in some way on compilation-mode and emacsclient. (I have some customizations for compilation-mode to work better with Gforth's error message, but those aren't included yet.)

In case you don't know: term-mode has two minor modes: line-mode and char-mode. The code switches to char-mode by default, but that can be confusing because C-x and almost all other keys are passed directly to the Forth process. Line-mode works more like comint-mode or perhaps like scrollback mode in GNU screen. It's imprtant to remember that C-c C-j and C-c C-k can be used to switch between those two modes.

The file backend/gforth.fth also contains some code that would allow us to send an escape sequence (^Z<command>\n) from Emacs to Forth that GForth interprets when it reads input via KEY. This is just an experiment; I don't know if it's worth it. Using a seperate socket might be better if we really want to have some reliable communication channel.

So what do think about this?

[larsbrinkhoff]

Sounds reasonable enough. It seems that so far, you are adding term-mode as an alternative in addition to comint-mode.

As for socket rather than direct input. Yes, but. Not all Forths have socket I/O. I had some vague idea that forth-mode should "own" the inferior Forth terminal I/O and backends should arrange to make it reliable. But that is probably not implemented.

Also, I worked with Forth programming for a year, and I did not use this forth-mode at all. So if you and/or some other people are active users, I will defer to your wishes in how this project should develop.

[ellerh]

As for socket rather than direct input. Yes, but. Not all Forths have socket I/O. I had some vague idea that forth-mode should "own" the inferior Forth terminal I/O and backends should arrange to make it reliable. But that is probably not implemented.

Yes, Forths vary a lot in what they offer. I guess the question is how can we use features that only some Forths support.

Also, I worked with Forth programming for a year, and I did not use this forth-mode at all. So if you and/or some other people are active users, I will defer to your wishes in how this project should develop.

I don't know how "real" Forth programmers work; I'm just a hobbyist. What I usually do is perhaps best described as test-driven-development: I write tests in a separate file and start a fresh process to run the tests. I use compilation-mode to run the tests because Gforth prints error messages and backtraces with line numbers that Emacs can parse; that helps a bit. AFAIK, other Forths don't print useful line numbers.

This is certainly different from "interactive development" as in Lisp, with a long running REPL session where restaring the Lisp process is less common.

However, I sometimes do use the Forth interpreter interactively, mostly for little, unstructured experiments.

It still would be nice if M-. in a source buffer would "just work" and that it could be used to explore the source code of the Forth system, e.g Gforth, itself. Overall, I think it's more important that M-. works well, than to have Gforth's status line in the *forth* buffer.

I guess, all I'm saying is that I will continue to experiment with this branch and come back if I ever consider forth-term.el a real improvement over forth-interaction-mode.el. Until now it's just different.

Thank you for your comments.