[gnu.emacs.bug] Problem with emacs on VAX/VMS 18.41.4

rpaul@sedona.intel.com (01/22/90)

I don't know if this is a bug or (most likely) a problem with a variable or
something along that line.

When I log in from home on to our VAX/VMS machine and invoke emacs it locks
up.  I have to relog in through another line and stop the process.

I put in the .emacs file

(debug)

and that's the only line, it start's up show's the *scratch* buffer on top and
the *backtrace* in the bottom window.  After stepping through the startup 
.emacs file it locks up again.  If I use the -q command arg it still locks up.
There is other people here at Intel that have the same problem.

This only happens when logging in from home, through a defender account and
a terminal server system.  Logging in at work through the terminal server there
is no problems.

The version we are running is:  18.41.4

and the variable emacs_term = vt200-80

Logging into a Ultrix system I have no problems either, whether that makes a
difference, I doubt it.

Do you have any suggestions as why, there is no real emacs 'expert' here.

___________________________________________________________________________
| Name:	 Richard Paul                  | Tel: 602 554 2793, Fax: 554 8585 |
| Dept:  ASIC Design Support, SQA      | E-mail: rpaul@sedona.intel.com   |
| Group: Chandler Microcontroller      | US-Mail: 5000 W. Chandler Blvd.  |
| Org:   Intel Corporation, ASIC in the Desert,     Chandler AZ, 85226    |
---------------------------------------------------------------------------

jis@ATHENA.MIT.EDU (Jeffrey I. Schiller) (01/23/90)

	Firstoff: Get a later version. There are a good number of
sometimes subtle problems with running an Emacs that old under VMS. I
brought up a version of 18.44 a few years ago under VMS (when it was
the current version) and ran into several problems. One of them is the
one you describe.

	The problem occurs only when running with a terminal speed of
less then 2400 baud. To fix it in your current version of Emacs add
the following define to s-vms.h:

   #define PENDING_OUTPUT_COUNT(FILE) ((*(FILE))->_ptr - (*(FILE))->_base)

Then in dispnew.c add these lines (abstracted from Emacs 18.54):

   #ifndef PENDING_OUTPUT_COUNT
   /* Get number of chars of output now in the buffer of a stdio stream.
      This ought to be built in in stdio, but it isn't.
      Some s- files override this because their stdio internals differ.  */
   #define PENDING_OUTPUT_COUNT(FILE) ((FILE)->_ptr - (FILE)->_base)
   #endif

Then search for code of the form:

   outq = stdout->_ptr - stdout->_base;

Replace this code with:

   outq = PENDING_OUTPUT_COUNT (stdout);

	This ought to solve your problem. Basically as the comment
above points out, VMS's stdout structure is different then UNIX. What
happens with the unmodified code is that "outq" is computed to be some
huge ridiculous number.  If you are running at less then 2400 baud,
GNU Emacs will sleep for this large number. The sleep isn't
interruptible and you lose.

	Now before you go off and fix this I suggest you also try
using the version of emacs you have to edit a file (that you don't
care about!) that is larger then about 128K. See if the file gets
garbled (extra new-lines added in odd places). If so then you have at
least one more important bug to fix.  The later versions of Emacs have
this problem fixed. Actually the "problem" is in the VMS C runtime
library and the later versions of Emacs have a workaround.

	Enjoy.

				-Jeff
 

rpaul@sedona.intel.com (01/23/90)

Jeff,

     Thanks for your reply.  Here at Intel we appreciate the reply we have
gotten so far.  Our problem has been with us for quite a while now.

     Now, what is the latest version of EMACS released, and where do we send
for a tape.  Also, is the Emacs Manual been changed,  we have the sixth
edition, Version 18, March 1987.

Thank You,

___________________________________________________________________________
| Name:	 Richard Paul                  | Tel: 602 554 2793, Fax: 554 8585 |
| Dept:  ASIC Design Support, SQA      | E-mail: rpaul@sedona.intel.com   |
| Group: Chandler Microcontroller      | US-Mail: 5000 W. Chandler Blvd.  |
| Org:   Intel Corporation, ASIC in the Desert,     Chandler AZ, 85226    |
---------------------------------------------------------------------------