my current status

my net connection has been down for a number of days, and is continuing 
to be down.  as of today i've finally scraped up a dial-in connection 
until the DSL gets fixed ("maybe end of the week? it should just 
magically fix itself.  If nothing happens by then, call us back.") 
YUCKKKKKKKK!!!!!!

So i just noticed that there are a number of bug reports and crashes, 
some of them for 21.4. [those look process-oriented; we need to get the 
appropriate patches from event-msw.c, which are very short and well 
tested.  i'll try to get to these bugs.

Meanwhile, with no net connection and no feedback, I started working on 
some other things that need to get done.  Currently I have three 
projects, more or less:

1] Merge in my stderr-proc WS.  This gets you a separate stderr from 
stdout in processes -- not clear it's useful, but it's needed to 
completely emulate call-process.  With this working, we'll switch 
entirely to using the Lisp call-process and junk
 callproc.c.  However, the more important part of this workspace is 
greatly improved error trapping -- the old call_with_suspended_errors() 
has been replaced by a new call_trapping_errors() or something that lets 
you specify exactly what you want trapped or inhibited.  this can 
include inhibit GC; disallow deletion or modification of existing 
buffers, windows, frames, devices, or consoles (but new ones can be 
created and then deleted); disallow any modification to the buffer text 
of existing buffers; inhibit entering the debugger on error; etc.  There 
are enough things you
can inhibit or restrict that it's possible to set up an environment in 
which it's possible to call ELisp from Redisplay safely.

See docs below:



/* This is equivalent to (*fun) (arg), except that various conditions
   can be trapped or inhibited, according to FLAGS.

   If FLAGS does not contain NO_INHIBIT_ERRORS, when an error occurs,
   the error is caught and a warning is issued, specifying the
   specific error that occurred and a backtrace.  In that case,
   WARNING_STRING should be given, and will be printed at the
   beginning of the error to indicate where the error occurred.

   If FLAGS does not contain NO_INHIBIT_THROWS, all attempts to
   `throw' out of the function being called are trapped, and a warning
   issued. (Again, WARNING_STRING should be given.)

   (If FLAGS contains INHIBIT_WARNING_ISSUE, no warnings are issued;
   this applies to recursive invocations of call_trapping_problems, too.

   If FLAGS contains ISSUE_WARNINGS_AT_DEBUG_LEVEL, warnings will be
   issued, but at level `debug', which normally is below the minimum
   specified by `log-warning-minimum-level', meaning such warnings will
   be ignored entirely.  The user can change this variable, however,
   to see the warnings.)

   Note: If neither of NO_INHIBIT_THROWS or NO_INHIBIT_ERRORS is
   given, you are *guaranteed* that there will be no non-local exits
   out of this function.

   If FLAGS contains INHIBIT_QUIT, QUIT using C-g is inhibited.  (This
   is *rarely* a good idea.  Unless you use NO_INHIBIT_ERRORS, QUIT is
   automatically caught as well, and treated as an error; you can
   check for this using EQ (problems->error_conditions, Qquit).

   If FLAGS contains UNINHIBIT_QUIT, QUIT checking will be explicitly
   turned on. (It will abort the code being called, but will still be
   trapped and reported as an error, unless NO_INHIBIT_ERRORS is
   given.) This is useful when QUIT checking has been turned off by a
   higher-level caller.

   If FLAGS contains INHIBIT_GC, garbage collection is inhibited.
   This is useful for Lisp called within redisplay or inside of the
   QUIT macro (where GC is generally not expected), for example.

   If FLAGS contains INHIBIT_EXISTING_PERMANENT_DISPLAY_OBJECT_DELETION,
   Lisp code is not allowed to delete any window, buffers, frames, devices,
   or consoles that were already in existence at the time this function
   was called. (However, it's perfectly legal for code to create a new
   buffer and then delete it.)

   #### It might be useful to have a flag that inhibits deletion of a
   specific permanent display object and everything it's attached to
   (e.g. a window, and the buffer, frame, device, and console it's
   attached to.

   If FLAGS contains INHIBIT_EXISTING_BUFFER_TEXT_MODIFICATION, Lisp
   code is not allowed to modify the text of any buffers that were
   already in existence at the time this function was called.
   (However, it's perfectly legal for code to create a new buffer and
   then modify its text.)

       [These last two flags are implemented using global variables
       Vdeletable_permanent_display_objects and Vmodifiable_buffers,
       which keep track of a list of all buffers or permanent display
       objects created since the last time one of these flags was set.
       The code that deletes buffers, etc. and modifies buffers checks
   
       (1) if the corresponding flag is set (through the global variable
       inhibit_flags or its accessor function get_inhibit_flags()), and
   
       (2) if the object to be modified or deleted is not in the
       appropriate list.
   
       If so, it signals an error.
   
       Recursive calls to call_trapping_problems() are allowed.  In
       the case of the two flags mentioned above, the current values
       of the global variables are stored in an unwind-protect, and
       they're reset to nil.]
   
   If FLAGS contains INHIBIT_ENTERING_DEBUGGER, the debugger will not
   be entered if an error occurs inside the Lisp code being called,
   even when the user has requested an error.  In such case, a warning
   is issued stating that access to the debugger is denied, unless
   INHIBIT_WARNING_ISSUE has also been supplied.  This is useful when
   calling Lisp code inside redisplay, in menu callbacks, etc. because
   in such cases either the display is in an inconsistent state or
   doing window operations is explicitly forbidden by the OS, and the
   debugger would causes visual changes on the screen and might create
   another frame.

   If FLAGS conatins INHIBIT_ANY_CHANGE_AFFECTING_REDISPLAY, no
   changes of any sort to extents, faces, glyphs, buffer text,
   specifiers relating to display, other variables relating to
   display, splitting, deleting, or resizing windows or frames,
   deleting buffers, windows, frames, devices, or consoles, etc. is
   allowed.  This is for things called absolutely in the middle of
   redisplay, which expects things to be *exactly* the same after the
   call as before.  This isn't completely implemented and needs to be
   thought out some more to determine exactly what its semantics are.
   For the moment, turning on this flag also turns on

        INHIBIT_EXISTING_PERMANENT_DISPLAY_OBJECT_DELETION
        INHIBIT_EXISTING_BUFFER_TEXT_MODIFICATION
        INHIBIT_ENTERING_DEBUGGER
        INHIBIT_WARNING_ISSUE
        INHIBIT_GC

   #### The following five flags are defined, but unimplemented:

   #define INHIBIT_EXISTING_CODING_SYSTEM_DELETION (1<<6)
   #define INHIBIT_EXISTING_CHARSET_DELETION (1<<7)
   #define INHIBIT_PERMANENT_DISPLAY_OBJECT_CREATION (1<<8)
   #define INHIBIT_CODING_SYSTEM_CREATION (1<<9)
   #define INHIBIT_CHARSET_CREATION (1<<10)

   If PROBLEM is non-zero, it should be a pointer to a structure into
   which exact information about any occurring problems (either an
   error or an attempted throw past this boundary).

   If a problem occurred and aborted operation (error, quit, or
   invalid throw), Qunbound is returned.  Otherwise the return value
   from the call to (*fun) (arg) is returned.  */

Lisp_Object
call_trapping_problems (Lisp_Object warning_class,
            const CIntbyte *warning_string,
            int flags,
            struct call_trapping_problems_result *problem,
            Lisp_Object (*fun) (void *),
            void *arg)




2] Various things in my main workspace:

-- allow processes in temacs; this was a trivial change and it allowed 
me to ...
-- delete all the nasty old nt callproc code in ntproc.c, callproc.c, 
and elsewhere.
   i also moved the non-callproc-specific code [e.g. environment 
handling] into          process.c.  Currently on Windows we compile 
without callproc.c.
-- fixed up the doc handling, both in make-docfile.c and in doc.c in 
XEmacs, to
   correctly deal with Japanese in doc strings.
-- some further optimization on Ffuncall.  it's now as blazingly fast as 
it can ever
   get until we eliminate dynamic scoping, so no complaints about slow 
funcalling.
-- a few other changes.

i'm just about ready to commit this but there's a nasty bug being 
introduced by my
changes.  i've narrowed it down to a file, but i still don't have a clue 
as to what's going wrong.

3] i've created an "8-bit mule" ws where i'm implementing the 
8-bit-fixed format for buffers.  we are [or should be] already just as 
fast as non-Mule on pure-ASCII buffers and strings, because of the info 
we keep about them, although it may be a bit buggy.  in this workspace, 
i'm adding the 8-bit-fixed format [which would mostly benefit binary 
files for the moment, although it could eventually benefit any 8-bit 
users when i allow the upper bits to be any dimension-1 charset.].  the 
idea is that we will make Mule the default!!!  There would be no reason 
not to.  In the process I've ended up having to clean up a bunch of 
fairly nasty code written by periodic XEmacs coders [the syntax-cache 
stuff by Matt and the case-table stuff by Yoshiki].  both of these were 
broken in a number of ways, and it doesn't surprise me that there have 
been reports of syntax/indent weirdness.  hopefully when this code goes 
in, all those lingering bugs will fix themselves.

however, as soon as i get [2] checked in to CVS, i'm going to put aside 
the other workspaces and take up the various bugs reported by users. 
 maybe with a round or two of bug fixing, we [stephen] can put out 
another beta -- and the one after that might include my stderr-proc 
changes, which i'm mostly done merging.

sound good?

i'll be in more or less regular email contact from now until further notice.

ben