karl@sugar.UUCP (Karl Lehenbauer) (11/23/87)
Well, I pulled MicroEMACS 3.9e off of comp.sources.misc and gave them a try under Microport Sys V/286 2.2. After changing the makefile to do a -lcurses in the link rather than a -ltermcap, the linker bombed on an object too big, requiring a recompile with "-Ml" in the CFLAGS in the makefile. One of the modules causes the optimizer to bomb. I invoked the compiler by hand without the -O option and it compiled fine. Everything then linked OK. Anyway, emacs works just fine, but it totally eats CPU time (pretty much all that's available), even when it's just sitting there waiting for keys. Anybody know what's happening? I selected USG and Unix compiler, terminal output as termcap; the rest are defaults. I thought I'd ask around before trying to dig through it myself. -karl --
mumble%karl@tut.cis.ohio-state.edu.UUCP (11/23/87)
There was a bugfix posted a week or so before 3.9 itself was posted. This is it... From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) Newsgroups: comp.emacs Subject: Fixes and enhancements to MicroEMACS 3.9e Date: 9 Nov 87 21:53:40 GMT A few small fixes to the new version 3.9e, shortly to be posted to the net somewhere. I will post my first set of fixes to the documentation in a few days. If you run a SysII/SysV system be sure to grab the fix in termio! This posting has one VMS enhancement, and several small changes. I have only run it on a few SysV machines, and only a few hours total. Looks *really* good. -- Reason for change: Addition of this change allows the emacs.rc file to be in the login directory rather than the current directory. Could also be "sys$login:[bin]" or something like that. Changes to epath.h: 70a71 > "sys$login:", Reason for change: When the VT100 option is selected there is a missing "{". Rather than put it in both places, which messes up my formatter, I placed it on a line by itself. Second change allows RETURN to be a quoted character in search or replace strings without being turned into a newline. This makes adding or deleting returns from files much easier. Changes to input.c: 357c357 < if (c == metac) { --- > if (c == metac) 358a359 > { 413c414 < if (c == (CTRL | 0x4d)) --- > if (c == (CTRL | 0x4d) && !quotef) Reason for change: When the USG (SysIII/V) option is selected, stdin is placed in polling mode without setting the flag to indicate that this has been done. This causes all input to be done in polling mode, making CPU time = the clock time. While this is not obvious on a single user system, on a large system it is not acceptable. This change sets the polling flag when polling mode is used. There was also some code to loop on input, caused by the polling flag error. I removed it. Changes to termio.c: 431,432c431 < while (read(0, &kbdq, 1) != 1) < ; --- > read(0, &kbdq, 1); 489a489 > kbdpoll = TRUE; -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me -=- Karl
karl@sugar.UUCP (Karl Lehenbauer) (11/26/87)
In article <1107@sugar.UUCP>, I wrote about an apparent problem with uEMACS under Unix System V. I dug around and found that they do an fcntl to set read with no delay as a means of getting typeahead in order to figure out to cancel output in progress. I'm not 100% sure that's their object, but that's what it looks like. Anyway, there's a variable, kbdpoll, which is set to TRUE to indicate that the input has been set to no delay, O_NDELAY, via fcntl. When 'typahead' is called, if kbdpoll isn't set, typahead sets it and calls fcntl with O_NDELAY so it can do the read without wait. When 'ttgetc' is called to get a character in the regular manner, if kbdpoll is set, ttgetc does an fcntl to turn off O_NDELAY and clears kbdpoll. The problem is that typahead doesn't set kbdpoll after setting O_NDELAY, so ttgetc never knows to clear it, resulting in a no-delay loop doing "while (read(0, &kbdq, 1) != 1);" Here's the diff: 490a491 > kbdpoll = TRUE; --