setting start-process environment, too much GC, debugging XEmacs

[stephen at xemacs.org]

Nix suggests:

 > (start-process doesn't seem to support running programs with
 > different environments yet, but that can't be too terribly hard to add,
 > and is of general utility.)

    (let ((process-environment an-appropriately-constructed-list))
      (start-process ...))

(Untested but should work.)  I prefer that idiom rather than
cluttering up the start-process API even more than it already is.

 > (Why is XEmacs-21.5.27 choosing to garbage-collect between every word I
 > type? If this is how the incremental GC normally works it's damned
 > annoying. Yes, each GC round only takes about a second, but still, that's
 > an unresponsive second every two seconds...)

Dunno.  I don't use the new GC yet.  File a bug report where Marcus
will see it (M-x report-xemacs-bug).

 > One aside: if XEmacs goes into a tight loop, how do I debug it?
 > I entered a newsgroup a few minutes ago and XEmacs wandered off
 > computing madly, GCing occasionally, and never came back.
 > 
 > The backtrace was, ahem, unhelpful:

Build with --with-union-type.  Source src/.gdbinit.  Type "lbt"
anywhere to get a Lisp backtrace, "lbp count" in frame #4 to find out
how many characters were deleted, and "pobj buf" in frame #2 to get a
peek at the internal structures of the buffer being munged.

The requirement for --with-union-type is an infelicity that appeared
post-3.3 GCC; it used to be that GDB could get at the LISP_CHAR_TYPE
macro, but for some reason it can't now.  So in disunion builds, pobj
can't determine the type of the object, and nothing much works.

 > (I'm considering just oprofiling it next time to get a clue what
 > functions the loop is passing through: would that be a worthwhile
 > approach?)

It might be.

FWIW, there's known breakage in the regexp code that can lead to
looping; it's claimed that simply incrementing the target text pointer
under certain conditions where there is a null match DTRTs, but I've
never been able to convince myself.

Gnus (I assume you're using Gnus to read newsgroups) does a lot of
weird stuff trying to make XEmacs appear to be GNU Emacs to its higher
level code.  I find Gnus code unreadable, and it's rarely commented,
so I've not even been able to formulate a bug report or RFE.