earleh@dartvax.UUCP (Earle R. Horton) (10/27/87)
There is a bug in the display code for MacKermit 0.8(xx) versions, and it's an
obscure one, at that. I have fixed it for 0.8(43A) (where do they get these
version numbers?), perhaps not correctly. This bug affects the ability of
certain VMS editors (EVE, EDT) to display selected text correctly for cut and
paste operations. Here is the description of the bug and my bumbling attempt
at a fix. Perhaps someone would care to forward this to the person in charge
of MacKermit if he doesn't read this newsgroup. Then it might get fixed in
the current version (I'll be d*mned if I will have anything to do with a
compiler that uses 8-bit shorts on a 68000, myself).
The syntax for the ANSI sequence to call for a text mode change is
escape-left bracket-ASCII encoded decimal integer-'m'. According to the VMS
system manager here, an alternate, also correct syntax is
escape-left bracket-semicolon-ASCII encoded decimal integer-'m'. Certain
other ANSI escape sequences use an escape syntax with two ASCII integers
separated by a semicolon. The code for handling escape sequences in ckmcon.c
stores two integers, then passes them to the function corresponding to the
letter opcode. Apparently, if the letter opcode is anything but 'm' and the
left bracket is followed immediately by a semicolon, then it is correct to
interpret this to mean zero-semicolon-other number. If the letter opcode is
'm', however, then this response is incorrect, as evidenced by MackKermit's
inability to highlight text correctly when using EVE. Some examples:
"^[[;7m" is apparently the same thing as "^[[7m", however "^[[;21r" is
not the same thing as "^[[21r".
Whether this is a bug in MacKermit, or a perversion in the ANSI standard, I
can't say with any authority, but the following repair causes MacKermit to
work correctly with EVE and EDT, and possibly with other programs. Find the
function text_mode(), and make the following change:
Old code:
<text_mode() /**** */
<{
< switch(num1)
< {
New code:
>text_mode() /**** */
>{
> switch(num1 + num2)
> {
Aside: I appreciate the effort that went into porting MacKermit to Megamax,
and I think it was definitely a worthwhile thing to do. The source code for
xkmker 0.8(35) no longer will compile under summac, however. Please, if you
are considering porting a program to another compiler/operating system/planet,
try not to destroy the original in the process. (Not that I actually follow
this advice, myself!)
Cheers.
--
*********************************************************************
*Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 *
*********************************************************************earleh@dartvax.UUCP (Earle R. Horton) (10/28/87)
In article <7486@dartvax.UUCP>, earleh@dartvax.UUCP (Earle R. Horton) writes: > There is a bug in the display code for MacKermit 0.8(xx) versions, and it's an > obscure one, at that. I have fixed it for 0.8(43A) (where do they get these ... > Aside: I appreciate the effort that went into porting MacKermit to Megamax, > and I think it was definitely a worthwhile thing to do. The source code for > xkmker 0.8(35) no longer will compile under summac, however. The guy who runs the VMS machine at the engineering school here wants a good vt100 emulator for the Mac which he can distribute for reasonable or no cost. So far, he considers MacKermit to be the only acceptable alternative, especially if it can be made to work properly with the editors which he has on the VMS machine. (I am not especially fond of VMS, but I have to admit their editors do a real good job of using the display abilities of a vt100.) I have the latest (?) version of the sources, 0.8(35) from June 1987, but I can't or won't compile them because they are in Megamax. (Apparently, 0.8(35) is a later version than 0.8(43A).) The sources which I have, that I can compile, are in sumacc but are about a year older than the latest version. I would like to incorporate the changes in the new version with my bug fix which allows MacKermit to work with the "Extensible VAX Editor (EVE)". I was toying with the idea of porting it to LightspeedC, until I looked at the header file which now contains preprocessor directions for both sumacc and Megamax. I would like to get something running here in a finite amount of time. ************************************************************************** Excuse me, Mr. C compiler developer, why didn't you all use the same data structure declarations? It's harder to make a Megamax program work with LightspeedC than it is to make a 4.3 BSD program work! ************************************************************************** Can anyone think of a reason why I shouldn't fix up the latest sources so they actually work with sumacc, then apply our local bug fixes and modifications? I haven't heard much about the sumacc compiler lately, but I really like it myself. Aside from some weird idiosyncrasies, it has some very endearing features: You can specify "-O" on the command line, and I'll bet it does something. (Optimizes things.) It uses /lib/cpp, which has predictable behavior. (This point can be argued, but I am used to it.) I can compile the sources IN THE BACKGROUND. None of this fake MultiFinder stuff, my C compiles run as completely detached processes on a VAX running real vmunix. (Apple, are you there yet?) It seems to produce a fairly compact final executable, probably as good as LightspeedC. Perhaps someone would care to enlighten me as to why the sumacc compiler has apparently fallen into disuse. Is it solely the inconvenience of having to download the compiled program (I can live with that) or is there something wrong with it? Cheers. -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************