Last Entry

Thursday, November 6, 2003

I resigned as the Mac maintainer of Emacs on November 4. Being a maintainer sometimes places responsibilities on me outside of programming. Most of that I find uninteresting and even distasteful.

To users of Emacs on Mac OS X, I still stand firmly by my code. If you find bugs in it, please write and let me know and I'll fix them.

I'll also keep this web page around as long as I can.

Emacs.r Problem

Sunday, November 2, 2003

Fixed a small problem with the Rez tool in Panther not knowing how to handle the hfdr resource in mac/src/Emacs.r.

Crash in Menubar Code

Saturday, November 1, 2003

I've received reports of Emacs crashing with crash logs containing the lines:

 [...]
 #24  0x92883974 in MenuSelect (MenuSelect + 96)
 #25  0x0013c7cc in x_activate_menubar (macmenu.c:984)
 [...]

It's caused (again) by Panther generating mouse-up events more accurately. Some of these seem to be omitted in previous versions of OS X. The code in CVS now acts accordingly and the problem should now disappear.

Building on Panther, Dylib Support on X Window

Friday, October 31, 2003

I've been running Panther since yesterday so I can now try out a few things.

Emacs builds and works fine with the --with-carbon --without-x ./configure option.

Since Panther installs texinfo 4.6, it is no longer necessary to install texinfo before building Emacs.

To build ispell, it's still necessary to install the GNU textutils first. But now local.h.samp can be used (as local.h) as is.

Terminal.app sets the TERM environment variable to xterm-color and seems to correctly emulate such a terminal. So Emacs will run with color in terminal mode by default.

Nozomu Ando has contributed a patch to unexmacosx.c that allows Emacs to be built to run under X Window in OS X using dynamic libraries (static X11 libraries used to be necessary). This patch has just been checked in to CVS.

So «out of the box», Emacs can now be configured to use the Carbon API by saying:

./configure --with-carbon --without-x

and use X Window by saying:

./configure --with-x --without-carbon

without any additional steps.

The pty bug seems to be indeed gone.

Pty Problem Disappears in Panther

Thursday, October 30, 2003

Carsten Bormann was the first to report that the pty bug no longer appears in Panther. That means Emacs will work accordingly whether process-connection-type is set to nil or t. Very good news indeed!

The Low-Down on the Pseudo Terminal Bug

Tuesday, October 28, 2003

Judging from recent posts to Emacs related newsgroups, and E-mail messages I've been receiving, I get the impression that more and more less-savvy computer users are trying to use Emacs. Typically, they download a year-old binary, double-click, and post a message that says Emacs is broken in Panther, etc. The fact is, if you checkout or update Emacs from CVS and compile it in Panther, it'll work just fine. Why do I still not make a binary distribution? To that my only answer is: the code is still in CVS! My secret wish is that if you can compile from CVS, you'll write better bug reports and ask more sensible questions. I have already concluded a while ago that this assumption is utterly wrong :-).

Unfortunately the pseudo terminal bug is something I cannot practically fix. I can think of many workarounds but all of them are messy. Perhaps a Darwin developer will read this note and fix the pty implementation. But even then, that won't get into OS X soon. The good news is, if process-connection-type is set to nil in your startup file, everything will work as they should, if you take the right precautions. Let me explain.

The implementation of pty's in Darwin is flawed. If a slave terminates before the master can read all its output, the last part of the output can be lost. A simple program to demonstrate this is as follows (modified from the code in a post in darwin-development).

#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv)
{
  pid_t pid;
  int master;
  char buf[1001];
  int n;

  pid = forkpty(&master, NULL, NULL, NULL);
  if(pid < 0) {
    perror("fork error");
    exit(-1);
  }
  else if(pid == 0) {
    int i;
    for (i = 0; i < 100; i++)
      printf("### This is the child process, line %d ###n", i);
    usleep(100000);		// Shouldn't be needed...
    exit(0);
  }
  else {
    while(n = read(master, buf, 1000)) {
      if(n < 0) {
	perror("read error");
	exit(-1);
      }
      buf[n] = 0;		// Make a string out of our data.
      printf("%s", buf);
    }
  }
  exit(0);
}

As a result an «interactive» program that uses a pty in Emacs, such as ftp or ssh, will work OK, up until the last command (quit, e.g.) sent to it, which usually doesn't matter. However if pty's are used to start a man, diff, latex, or make process, which don't wait for any input, the last part of the output will be lost. Fortunately «pipes» work and will not lose output, and setting process-connection-type to nil enables them by default. Emacs Lisp packages that do require pty's will set the buffer-local variable process-connection-type to t, and everything should work the way they're intended.

So I think I should leave pty support in Emacs as it is, and find a way to set process-connection-type to nil even when Emacs is running in a terminal on OS X. I'll put a description of this problem in etc/PROBLEM and the FAQ. Of course, as always, any contribution that fixes this problem is welcome.

Truncated Process Output Problem When Emacs Runs in Terminal

Wednesday, October 22, 2003

Long-time users of Emacs on Mac OS X will know that the Lisp variable process-connection-type needs to be set to nil. Otherwise some output of processes started by Emacs may be lost. This is due to a broken implementation of pty's in Darwin.

Process-connection-type is set to nil by default in lisp/term/mac-win.el. But when Emacs is started in the terminal by emacs -nw, that code doesn't get executed. I'll probably fix the problem by removing pty support entirely in the future. For now, please add

(setq process-connection-type nil)

to your startup file or site startup file if you're experiencing problems with anything that starts an external process, e.g., tramp, compile, diff, ediff, man, etc.