This one is a little obscure, but I thought I’d post anyhow…
FrobTads works fine almost everywhere, but there is an issue if you run it within an Emacs ansi-term (or multi-term) buffer: after the first full or even partially full screen, more or less, some of the text starts to get scrambled — words out of order, words missing, stray stuff, etc. The only thing that works reliably is the “-i plain” option.
The problem is at least as likely to be in Emacs and/or components as it is to be in FrobTads, and I’m trying to track it down. But I wonder if anyone else has seen this? I realize this is not exactly a mainstream method of running FrobTads, but when I get in Emacs I kind of like to live there; it’s typical of Emacs fanaticism.
This is, by the way, with the latest FrobTads (from the FrobTads site), Emacs 23.1, Ubuntu 10.04, Gnome.
Without knowing really anything about the underlying implementation of both FrobTads and Emacs, it sounds to me like a bug in memory allocation/reallocation for the scrollback buffer. Since the problem only exists in FrobTads and Emacs can be considered to be quite mature, I think we can assume that it’s somewhere in the FrobTads code.
Is FrobTads written purely in Emacs Lisp or does it have portions written in C?
(FrobTADS is written in C++ (T3) and C (T2).)
I suspect that it doesn’t get the terminal height right. I will try to reproduce when I get a chance later today.
I found the problem. It is related to terminal dimensions and looks like a bug in Emacs, though I can’t be 100% sure. The problem is that frob sets the LINES and COLUMNS env vars. This isn’t strictly necessary, but solves a bug in some curses versions. However, Emacs seems to get confused when this happens. I will need to ask the Emacs devs about this.
To fix the issue for now, you can edit src/frobtadsappcurses.cc and in lines 259 and 260 find this code:
putenv(linesEnv);
putenv(columnsEnv);
Simply delete or comment-out these two lines.
The fix worked perfectly, thank you very much for taking the time to research and deal with such an obscure issue.
I might spend a little time digging into ansi-term and multi-term to see where the real problem lies, though the very idea of expecting to be able to run literally anything in an Emacs buffer is something only true believers embrace. (Obviously I am one of those.)
At least I was able to take out the ugly workaround in my GGZC bash wrapper which tested for the presence of Emacs as a parent process and forced “-i plain” if so!