edward@UCBARPA.BERKELEY.EDU (Edward Wang) (10/04/88)
Manifestation: Emacs (version 18.52.4) does not use insert or delete character to update the display on terminals with termcap entries "im" and "ei" but no "ic". Adding the blank "ic=" entry fixes the problem. Fix: In term.c, the flag char_ins_del_ok is not computed correctly. The lines char_ins_del_ok = ((TS_ins_char || TS_ins_multi_chars) && (TS_del_char || TS_del_multi_chars)); should be char_ins_del_ok = ((TS_insert_mode || TS_ins_char || TS_ins_multi_chars) && (TS_del_char || TS_del_multi_chars)); I don't think it is necessary to add TS_delete_mode, since "dc" is required even with "dm" set (it doesn't make sense otherwise). However, "ic" is not required when "im" is set. This exists in all Emacs versions, but char_ins_del_ok is unused until this version.
BOWMAN%PPC.MFENET@CCC.NMFECC.GOV (10/17/89)
Emacs Bug Report
Emacs Version: 18.52.4 Compiled Tue Jun 27, 1989 on _RAX (VAX_VMS)
Machine: USC VAX 8600
Operating system: VMS V5.1-B.
Dear Sir:
I would like to report a rather serious bug (involving an EMACS
crash) I have found and corrected in our VMS implementation of EMACS. To
illustrate the bug, do the following: Execute the function
subprocess-command (usually bound to ESC-$). Then force the subprocess to
send a steady stream of output (e.g. with a $DIRECTORY command or $TYPE a
file). While the subprocess is busy sending output, type a CTRL-G a few
times. The routine sys_abort() will be called from get_display_line(), and
one winds up in the debugger. (No auto-saves are done nor is the user
prompted by the usual emergency escape queries). At this point it seems
that the windowing and/or screen parameters are messed up. The problem
appears to occur in the routine interrupt_signal() in keyboard.c. The
CTRL-G results in a throw, which is undesirable when the subprocess is
sending output. The problem can be circumvented by putting a call to
clear_waiting_for_input() at the beginning of the subprocess input handler
(in file vmsfns.c).
I hope this is enough information for you to understand and replicate the
bug. The fix I mentioned above has not been installed on the system version of
emacs but unless you have a better solution we will eventually install it.
If you need any more information please contact me.
Yours sincerely,
John Bowman
Plasma Physics Lab
P.O. Box 451
Princeton, NJ. 08543
(609)243-2301BOWMAN%PPC.MFENET@ccc.nmfecc.gov (10/20/89)
Re: Emacs Ctl-G bug.
Hi. As I mentioned in my last message, it seems that vmsfns.c was the
wrong place to put in the calls to clear_waiting_for_input and
set_waiting_for_input. Instead, the following routine seems to be the
correct place to make the change. It is taken from sysdep.c and calls
process_command_input, a routine from vmsfns.c. I have initialed my changes.
If I also (setq window-system t) in the input-handler then I get proper
behaviour of both normal Ctl-g and "emergency escape" signals.
The Vinhibit_quit=Qt below also is required for proper handling of emergency
escapes. There are no changes required in vmsfns.c afterall.
-- John Bowman
wait_for_kbd_input ()
{
extern int have_process_input, process_exited;
/* If already something, avoid doing system calls. */
if (detect_input_pending ())
{
return;
}
/* Clear a flag, and tell ast routine above to set it. */
SYS$CLREF (input_ef);
waiting_for_ast = 1;
/* Check for timing error: ast happened while we were doing that. */
if (!detect_input_pending ())
{
/* No timing error: wait for flag to be set. */
SYS$WFLOR (input_ef, input_eflist);
if (!detect_input_pending ())
/* Check for subprocess input availability */
{
int dsp = have_process_input || process_exited;
clear_waiting_for_input();/* Otherwise Ctl-G will cause crash. JCB */
Vinhibit_quit=Qt; /* JCB */
if (have_process_input)
process_command_input ();
if (process_exited)
process_exit ();
if (dsp)
{
RedoModes++;
DoDsp (1);
}
set_waiting_for_input(0); /* JCB */
}
}
waiting_for_ast = 0;
}larry@SHARKEY.CC.UMICH.EDU (Larry Siden) (12/07/89)
Hello,
I am running EMACS version 18.52 and I keep encountering the following
bug whenever I attempt one of the functions 'minibuffer-complete-word' or
'minibuffer-completion' while building an argument to a command that takes
a file-name (e.g. 'find-file'). After typing a complete pathname prefix (e.g.
"/users/larry/", a TAB will produce the message "[Complete, but not unique]"
in the minibuffer, and a space will produce a directory listing in the window
*Completions* . But if I type a space after "/users/larry" (sans final '/')
I will get a message that reads:
"Wrong type argumnent: sequencep, #<EMACS BUG: ILLEGAL DATATYPE (#o 57) Save your"
The message is cut off after the word "your".
Do you know what this is?
Do you have a more up-to-date version of the culprit module (.o file) to send
me that I can re-link with the others?
Here is the output of the *Backtrace* buffer:
Signalling: (wrong-type-argument sequencep #<EMACS BUG: ILLEGAL DATATYPE (#o 57) Save your buffers immediately and please report this bug>)
read-file-name-internal("~/fsf" "~/" nil)
minibuffer-complete-word()
call-interactively(minibuffer-complete-word)
call-interactively(find-file)
note: "fsf" is the name of a directory.