gallaher@topaz.ARPA (Mike Gallaher) (05/30/85)
Here are some bug fixes for Unipress Emacs V2.00 and V2.01.
This is the first of three shar archives. Unpack them into
some directory and read the file README. If you have any
questions, or find something wrong, send mail to unipress!mg.
If there is no fix here for your favorite bug, let me know...
Mike Gallaher
Unipress Software
-----------------------------------------------------------------
# This is a shar archive. Extract with sh.
echo Extracting FORM
cat > FORM << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version:
ident:
date:
posted-to:
fixed-by:
source-files:
Synopsis:
Description:
Repeat-by:
Fix:
__Egregious Trees!!!__
echo Extracting INDEX
cat > INDEX << "__Egregious Trees!!!__"
Fixes for Unipress Emacs V2.00 and V2.01
2.01 -> 2.02
------------
xonflow-2 setting xon/xoff-flow-control in startup files has no effect
variables-3 setting GlobalModeString causes core dump
filecmd-2 insert-file sets buffer read-only if file is write-protected
abbrev-4 expanding abbrev for word > 200 chars causes core dump or hang
hostname-1 Emacs did not use the hostname call under 4.2bsd
abbrev-3 setting auto-write-abbrev-file core dumps
abbrev-2 test-abbrev-expand checked global abbrevs before local
leftoffset-1 incorrect display if left-offset variable > 0
linenum-1 line-number hangs when invoked at end of buffer
mlarith-1 * << >> ^ hang if error in arguments
subproc-1 FilterThrough, ExecBf use variable number of arguments
syntax-1 dot-in-comment returns inverse of what it should
unlink-1 unlink function does not work properly
compiler-2 mlisp compiler trashes last byte of source strings
filecmd-1 write-current-file incorrectly sets up buffer filename
2.01 -> 2.02
------------
kbdmac-1 Keyboard macros defined with incorrect length
kbdmac-2 Keyboard macros have extra characters at end
minibuf-1 core dump on minibuffer commands >40 chars
misc-1 Various minor problems, not too serious
varfix-1 ++, --, +=, -=, etc. don't work with system variables
xonflow-1 not easy to start Emacs in xon/xoff flow control mode
2.00 -> 2.01
------------
abbrev-1 Abbrev tables forgotten across buffer changes
args-1 ++, --, +=, etc. change their string variable arg to integer
buffer-1 buffer modes (including keymaps) lost across buffer changes
defun-1 trying to defun a wired function causes core dump
comswitches-1 command line switches beginning with '+' cause core dump
files-1 read-file incorrectly set up buffer file name
gentty-1 no entry in gentty for SYS_III
keymap-1 get-local-keymap complains about null keymap names
keymap-2 use-local-map complains if given null keymap name
overwrite-1 buffer-is-modified was not being updated
overwrite-2 overwrite mode does not check read-only status
process-1 ProcessID incorrectly reports error
process-2 subproc.c won't compile on 8-character-unique preprocessors
quit-2 bad command line switch causes core dump
ttylock-1 ttylock.c won't compile properly if ONEEMACSPERTTY TRUE
__Egregious Trees!!!__
echo Extracting README
cat > README << "__Egregious Trees!!!__"
This directory contains bug fixes for Unipress Emacs V2.00 and V2.01. They
are listed in the file INDEX. If you have V2.00, all the fixes are
applicable. If you have V2.01, the fixes that have only V2.00 in the
version field have already been applied.
The file FORM contains an empty bug fix form that you can fill out
for fixes of your own.
If you have any questions or want to point out problems, or have new fixes
of your own, please send mail to unipress!mg.
__Egregious Trees!!!__
echo Extracting abbrev-1
cat > abbrev-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: abbrev-1
date:
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: abbrev.c
Synopsis: Abbrev tables forgotten across buffer changes
Description:
The abbrev tables can be local to a particular buffer.
The location of these tables are stored in cache vari-
ables so that they can be accessed and updated faster.
The function SetBfp updates the buffer structure from the
cache values. The problem is that abbrev.c is directly
accessing the buffer structure.
Repeat-by:
Fix:
The fix is to comment out or delete all the lines in the
file abbrev.c with 'bf_cur->b_mode' in them. This can be
done in the following way:
Change the lines that look like this:
bf_cur->b_mode.md_abbrev = mode_cache.md_abbrev = p;
to look like this:
#if 0
bf_cur->b_mode.md_abbrev =
#endif 0
mode_cache.md_abbrev = p;
AND
Change the lines that look like this:
bf_cur->b_mode.md_AbbrevOn = mode_cache.md_AbbrevOn = TRUE;
to look like this:
#if 0
bf_cur->b_mode.md_AbbrevOn =
#endif 0
mode_cache.md_AbbrevOn = TRUE;
__Egregious Trees!!!__
echo Extracting abbrev-2
cat > abbrev-2 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: 2.00, 2.01
ident: abbrev-2
date: 21-May-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: abbrev.c
Synopsis: test-abbrev-expand checked global abbrevs before local
Repeat-by:
1> Execute the following MLisp lines.
(use-abbrev-table "a")
(define-global-abbrev "but" "buttock")
(define-local-abbrev "but" "no buts here")
2> Now type "but " in the buffer; it will expand to "no buts here";
this is correct.
3> Next type 'ESC-x test-abbrev-expand but' this will expand to
"buttock"; this is the incorrect behavior; The correct expansion
would have been "no buts here".
Fix:
There are two places that might need to be fixed depending on which version
of the sources you have. Either way the changes to be made are the same,
they are just made in different places.
The problem is that when Emacs does a test-abbrev-expand, it first checks
the local table and then check the global one. This order must be reversed.
The checking is done in the file abbrev.c; in either the function
TestAbbrevExpand or TstAbrExp2.
The statement to look for is this:
if ((p = lookup(&GlobalAbbrev, abbrev, h)) == NULL &&
(p = lookup(mode_cache.md_abbrev, abbrev, h)) == NULL)
return(NULL);
and you need to change it to this:
if ((p = lookup(mode_cache.md_abbrev, abbrev, h)) == NULL &&
(p = lookup(&GlobalAbbrev, abbrev, h)) == NULL)
return(NULL);
Notice that the two statements are switched.
__Egregious Trees!!!__
echo Extracting abbrev-3
cat > abbrev-3 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: abbrev-3
date: 23-May-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: mlvars.c
Synopsis: setting auto-write-abbrev-file core dumps
Description:
Any attempt to set auto-write-abbrev-file results in a core dump
because the variable was initialized wrong in mlvars.c.
The problem is that the internal system variable
AutoWriteAbbrevFile is initialized to point at a null string in
initialized data space. Setting this variable tries to write
the new value into this string; since it is not writable, this
causes a core dump.
Repeat-by:
1> ESC-x set auto-write-abbrev-file foo
2> Emacs will core dump.
Fix:
1> In mlvars.c$InitMLvars change the extern statement for
AutoWrAbFilename from an char pointer to an array declaration
like this:
extern char AutoWrAbFilename[PATHLEN+1];
2> a little farther down in mlvars.c$InitMLvars is this line:
AutoWrAbFilename = "";
change it to:
*AutoWrAbFilename = '\0';
__Egregious Trees!!!__
echo Extracting abbrev-4
cat > abbrev-4 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: abbrev-4
date: 24-May-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: abbrev.c
Synopsis: expanding abbrev for word > 200 chars causes core dump or hang
Description:
Trying to expand an abbrev phrase more than 200 characters long
caused an array allocated on the stack to overflow, leading to
bizzare behavior or a core dump.
Repeat-by:
1) ESC-x set abbrev-mode 1
2) ^U300g this will insert 300 'g's in the buffer
3) <space> (or any non-word character) this will cause Emacs
to try to expand the abbrev for the word just
typed, and will hang or core dump.
Fix:
In the function abbrev.c$AbbrevExpand there is a line:
while (--n >= 1 && CharIs(c = CharAt(n), WordChar)) {
change it to:
while (p >= buf && --n >= 1 && CharIs(c=CharAt(n), WordChar)) {
^^^^^^^^^^^
--------------- End of patch to abbrev.c ------------------------------
__Egregious Trees!!!__
echo Extracting args-1
cat > args-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: args-1
date: 1-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: mlargs.c
Synopsis: ++, --, +=, etc. change their string variable arg to integer
Description:
When GetArg1 called StrToInt it did not check Emacs_Err
to see if the arg was truly numeric; This resulted in the
type of the variable being changed to integer no matter
what its orginal type was.
Repeat-by:
Execute the MLisp (++ mode-line-format). mode-line-format
will thereafter be an integer rather than a string.
Fix:
In the C function GetArg1, there is a switch statement:
switch (e->exp_type) {
....
}
and inside that there is an if statement:
case IsString:
....
/* intentional fall-through */
right after the call to ReleaseExpr, add the following if
statement:
if (Emacs_Err)
return(NULL);
This checks the error return from StrToInt and returns if
there was an error, preventing the rest of the code
from changing the type to integer.
__Egregious Trees!!!__
echo Extracting buffer-1
cat > buffer-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: buffer-1
date: 1-Apr-85
posted-to:
fixed-by: david medinets (unipress!dm)
source-files: buffer.c
Synopsis: buffer modes (including keymaps) lost across buffer changes
Description:
Some buffer specific information, such as buffer specific
variables, local keymaps, and region restrictions were being
lost across buffer changes.
Repeat-by:
Fix:
The permanent buffer structure of each buffer was not being
updated when SetBfp was called. To fix, add a line of code
to set the permanent buffer structure equal to the cache
buffer structure in SetBfp. Add
bf_cur->b_mode = mode_cache;
to the end of the block inside this code fragment:
if (bf_cur) {
....
}
--------------- End of patch to buffer.c --------------------
__Egregious Trees!!!__
echo Extracting compiler-1
cat > compiler-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: compiler-1
date:
posted-to:
fixed-by: david medinets (unipress!dm)
source-files: mlprims.c
Synopsis:
Description:
When MLisp defuned a function with the same name as
a wired primitive Emacs would core dump. This was be-
cause when changing from an if to a case statement, the
scope of the break statements in the function DefineFunc-
tion were changed.
Repeat-by:
execute this MLisp line: (defun (backward-word (nothing))) and
Emacs should core dump if you have this bug.
Fix:
In the C function DefineFunction, there is a
switch (b->b_binding) {
....
}
in the following case statement:
case ProcBound:
....
break;
change the 'break;' to a 'goto dmm;' and insert this
line:
dmm:
before the line containing:
EI.Nis++;
__Egregious Trees!!!__
echo Extracting compiler-2
cat > compiler-2 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: compiler-2
date: 22-May-85
posted-to:
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
source-files: mlcompile.c
Synopsis: mlisp compiler trashes last byte of source strings
Description:
The MLisp compiler, when called to compile a single string or
word, replaces the last byte of the string with a \377
character.
Repeat-by:
Switch to an empty buffer, insert the string "foo", with the quotes,
and do execute-mlisp-buffer. It will turn the last quote into a \377.
This also shows up when you do (execute-mlisp-line "foo"); it
will report the string executed as "fo\377".
Fix:
The problem is that while yylex (in mlcompile.c) is reading
the source string via GETC, after reading EOF it pushes back
the EOF via UNGETC. The current version of SrcUnGetC, which
does the dirty work of UNGETC, merrily overwrites the last
character with the EOF indicator, which is -1. The fix
is to modify SrcUnGetC to refuse to do anything if the character
is the EOF marker. Change the code as if FIXED were defined
nonzero (this is only for illustration, the preprocessor will not
accept this because of the backslashes quoting the newlines):
#define SrcUnGetC(c, src) ((src)->strflg \
#if FIXED
? ((src)->snc && c != EOF \
#else
? ((src)->snc \
#endif
? ((src)->snc--,\
*--((src)->ssp) = c)\
: EOF)\
: ungetc(c, (src)->sfp)\
)
--------------- End of patch to mlcompile.c --------------------------
__Egregious Trees!!!__
echo Extracting comswitches-1
cat > comswitches-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: comswitches-1
date: 1-Apr-85
posted-to:
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
source-files: emacs.c
Synopsis: command line switches beginning with '+' cause core dump
Description:
Emacs core dumps if given a command line switch beginning with
a '+', as in +457 (start at line 457) or +/vorm (start at string
vorm).
Repeat-by:
Invoke Emacs using this command:
emacs +100 foo.c
Emacs will core dump if your version has this bug.
Fix:
In the file emacs.c, search for the code
case '/':
sstring = (*targv) + 2;
break;
default:
if (isdigit(*targv[1])) {
....
}
change the if condition to:
if (isdigit((*targv)[1])) {
....
}
--------------- End of patch to emacs.c ------------------------------
__Egregious Trees!!!__
echo Extracting defun-1
cat > defun-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: defun-1
date: 1-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: mlprims.c
Synopsis: trying to defun a wired function causes core dump
Description:
When MLisp defuned a function with the same name as
a wired primitive Emacs core dumps.
Repeat-by:
Execute the MLisp line
(defun (backward-word (nothing)))
Emacs will core dump if you have this bug.
Fix:
In the C function mlprims.c$DefineFunction, look for the statement
switch (b->b_binding) {
....
}
Within that switch, in the case clause
case ProcBound:
....
break;
change the 'break;' to a 'goto dmm;' and insert this
line:
dmm:
before the line containing:
EI.Nis++;
--------------- End of patch to mlprims.c ------------------------------
__Egregious Trees!!!__
echo Extracting filecmd-1
cat > filecmd-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.01
ident: filecmd-1
date: 30-Apr-85
posted-to:
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
source-files: filecmds.c
Synopsis: write-current-file incorrectly sets up buffer filename
Description:
When write-current-file (usually bound to ^X^S by default)
is invoked in a buffer that has no associated file, it asks
for one and writes that file. However, the next time anything
asks for a file name interactively (e.g. visit-file), the name
typed becomes the name associated with that buffer. Also,
write-current-file will core dump if you type ^G when it
asks you the name of the file to write.
Repeat-by:
^Xbnonexist Switch to a new, file-less buffer.
^X^S/tmp/foo invoke write-current-file
[the buffer will now have that name as its file]
^X^Vgralt visit a new file
[the file gralt will now be visited in the buffer nonexist]
Fix:
The problem is that file names entered interactively are saved
away in a static that gets overwritten the next time something
asks for a file name. WriteCurrentFile just used that static.
The fix is to save the string away in a safe place.
The core dump on ^G happens because the code never checks
to see if the returned argument is 0, as when ^G is typed,
and tries to savestr it anyway.
------------------------------------------------------------------------
filecmds.c
In function WriteCurrentFile, change the code as follows:
#if FIXED
if (! bf_cur->b_fname) {
char *fn = GetFileName(prompt);
if (STRNULL(fn)) {
if (!Emacs_Err) /* if it wasn't aborted by ^G */
error(Err_emptyfilename);
return(NULL);
} else
bf_cur->b_fname = savestr(SaveAbs(fn));
}
#else not FIXED
if (! bf_cur->b_fname) {
if ((bf_cur->b_fname =
SaveAbs(GetFileName(prompt))) == NULL) {
error(Err_emptyfilename);
return(NULL);
}
#endif FIXED
__Egregious Trees!!!__
echo Extracting filecmd-2
cat > filecmd-2 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: 2.00, 2.01
ident: filecmd-2
date: 28-May-85
posted-to:
fixed-by: unipress!dm (david medinets)
source-files: filecmds.c
Synopsis: insert-file sets buffer read-only if file is write-protected
Description:
Functions that read a file set the read-only variable in the
buffer into which the file is being read, so that you will
not try to modify the file. However, insert-file also behaves
this way, which is annoying.
Repeat-by:
insert a file into your buffer that you know is write protected
against you. You will notice that the status of read-only is TRUE.
Fix:
1> In filecmds.c$InsertFile, add the variable declaration:
int save_readonly = mode_cache.md_ReadOnly;
2> at the end of filecmds.c$InsertFile, and the following line:
mode_cache.md_ReadOnly = save_readonly;
--------------- End of patch to filecmd.c ------------------------------
__Egregious Trees!!!__
echo Extracting files-1
cat > files-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: files-1
date: 1-Apr-85
posted-by:
fixed-by:
source-files: fileio.c
Synopsis: read-file incorrectly set up buffer file name
Description:
The function read-file asks whether you want to still
read a file if the buffer that you are in is modified.
The Emacs overwrites the name of the file
that you are trying to read when it asks the question.
Repeat-by:
Visit a file, make some change to it, and say
ESC-x read-file <filename>. Emacs will try to read a
file with a bogus name into the buffer (but will not
change the original file).
Fix:
In the C function fileio.c$ReadFile, change the first if statement
from:
if ((fn = GetFileName(": read-file ")) == NULL) {
...
}
to:
if ((fn = SaveAbs(GetFileName(": read-file "))) == NULL && ! Emacs_Err)
fn = SaveAbs(bf_cur->b_fname);
--------------- End of patch to fileio.c ------------------------------
__Egregious Trees!!!__
echo Extracting gentty-1
cat > gentty-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: 2.00
ident: gentty-1
date: 30-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: gentty.h
Synopsis: no entry in gentty for SYS_III
Description:
The file gentty.h needs a system entry for SYS_III. This is
easily accomplished because the entry for SYS_V will work for
system 3.
Fix:
Find the line '#if SYS_V' and add '| SYS_III' to the end of it.
__Egregious Trees!!!__gallaher@topaz.ARPA (Mike Gallaher) (05/30/85)
# This is a shar archive. Extract with sh.
echo Extracting hostname-1
cat > hostname-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: hostname-1
date: 24-May-85
posted-to:
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
source-files: config.c lispfuncs.c
Synopsis: Emacs did not use the hostname call under 4.2bsd
Description:
Emacs had always depended on the user to set the system
name up in config.c. Under 4.2bsd this is silly, since
there is a system call to return the system name at run time.
Then one copy of Emacs can be moved around to a number of
similar 4.2 machines without recompiling it.
Fix:
config.c
Enclose the initialization of SystemName inside a conditional:
#if SYS_4_2 == 0
char *SystemName = "unipress"; /* under 4.2, this is done instead by
the hostname call in lispfuncs.c,
so don't worry about setting it. */
#endif
***************
lispfuncs.c
Change the extern declaration of SystemName to
#if SYS_4_2
char SystemName[SYSNAMELEN]; /* raw name of system */
#else
extern char *SystemName; /* defined in config.c for non-4.2 */
#endif
---------------
In InitFunc, after the defproc of "mark", there is a block
of code that sets up ConvertedSystemName. Add another
level of braces around it and add the four lines
within the first level so that the code looks like this:
defproc(MarkVal, "mark");
{
#if SYS_4_2
int SysnameLength = sizeof(SystemName);
gethostname(SystemName, &SysnameLength);
#endif
{
char *p = SystemName;
if (*p == 0)
p = "Bogus System Name";
(void) strncpy(ConvertedSystemName, p, sizeof(ConvertedSystemName));
p = ConvertedSystemName;
while (*p) {
if (*p < ' ')
*p = 0;
else if (*p == ' ')
*p = '-';
p++;
}
}
}
***************
__Egregious Trees!!!__
echo Extracting kbdmac-1
cat > kbdmac-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: kbdmac-1
date: 10-Apr-85
fixed-by: barnes@tl-20 (Gary Barnes)
posted-to:
source-files: macros.c
Synopsis: Keyboard Macros defined with incorrect length
Description:
DefineStringMacro left off the last character of the macro.
It turned out that DefMac copied one too few characters for
the macro body. This happened to work for DefineKeyboardMacro
and DefineBufferMacro because they passed a length argument that
was the real length+1, but DefineStringMacro did not do this so
it always got the last character chopped off.
Fix:
Make DefMac copy exactly the number of characters given by the
length argument and fix DefineKeyboardMacro and DefineBufferMacro
to pass exactly the length of the string they want to define.
Apply the changes below, using the code in the #if FIXED sections.
In the file macros.c:
************************
In the function DefMac, change the code as follows:
#if FIXED
while (macrolength--) /* {14} */
*t++ = *q++; /* {14} */
*t = '\0'; /* {14} */
#else
while (--macrolength)
*t++ = *q++;
#endif
-------------
In function EditMacro, change the code as follows:
#if FIXED
while (i--) { /* {14} had been --i */
(void) InsertAt(dot, *s++);
DotRight(1);
}
#else
while (--i) {
(void) InsertAt(dot, *s++);
DotRight(1);
}
#endif
-------------
In function DefineBufferMacro, change the code as follows:
#if FIXED
(void) DefMac(bf_cur->b_fname, (char *) p1_cache + 1,
MacroBound, s1_cache); /* {14} this had been s1_cache+1 */
#else
(void) DefMac(bf_cur->b_fname, (char *) p1_cache + 1,
MacroBound, s1_cache+1);
#endif
-------------
In function DefineKeyboardMacro, change the code as follows:
#if FIXED
(void) DefMac(name, (char *) KeyMem, MacroBound, MemUsed-1); /* {14} */
#else
(void) DefMac(name, (char *) KeyMem, MacroBound, MemUsed);
#endif
------------ end of patches to macros.c ------------------------------
__Egregious Trees!!!__
echo Extracting kbdmac-2
cat > kbdmac-2 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: kbdmac-2
date: 15-Apr-85
posted-to:
fixed-by: rbbb@rice (David Chase @ Rice University)
source-files: keyboard.c
Synopsis: Keyboard macros have extra characters at the end
Description:
Keyboard macros had spurious characters tacked onto the end
if the stop-remembering that ended them was invoked by a multi-key
sequence. The old code had just subtracted one from the length,
assuming that stop-remembering was bound to a two-key sequence.
Fix:
The fix, from David Chase @ Rice, uses a variable MemAtLastStroke
to save the value of MemUsed when ProcessKeys started reading
the last command sequence.
In the file keyboard.c:
*************************
Add the following variable definition after that of MemPtr:
hidden int MemAtLastStroke; /* records MemUsed when ProcessKeys begins
to walk keymaps {13} */
---------
In function ProcessKeys, change the code as follows (new code is as if
FIXED were defined non-zero):
#if FIXED
if (NextGlobalKeymap == NULL) {
NextGlobalKeymap = CurrentGlobalMap;
MemAtLastStroke = MemUsed; /* {13} */
}
#else
if (NextGlobalKeymap == NULL)
NextGlobalKeymap = CurrentGlobalMap;
#endif
---------------
In function GetChar:
#if FIXED
MemUsed = MemAtLastStroke; /* {13} had been MAXKBDMACLEN */
#else
MemUsed = MAXKBDMACLEN;
#endif
---------------
In function StartRemembering:
MemUsed = 0;
#if FIXED
MemAtLastStroke = 0; /* {13} */
#endif
message(FALSE, Msg_remembering);
----------------
In function StopRemembering:
#if 1
MemUsed = MemAtLastStroke; /* get rid of keystroke ending def {13} */
#else
MemUsed -= 1; /* get rid of the ^x from ^xe (puke!) */
#endif
---------------- end of patch to keyboard.c -------------------------
__Egregious Trees!!!__
echo Extracting keymap-1
cat > keymap-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: 2.00
ident: keymap-1
date: 1-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: keymap.c
Synopsis: get-local-keymap complains about null keymap names
Description:
get-local-keymap generates an error if there is no local keymap.
It should return a null string.
Repeat-by:
Execute (get-local-keymap) in a buffer that has no local keymap.
It will signal an error.
Fix:
Replace the definition of keymap.c$GetLocalKeymap with the
following code:
visible int
GetLocalKeymap()
{
char *name = MD_KEYS && MD_KEYS->name ? MD_KEYS->name : "";
MLvalue->exp_release = FALSE;
ReturnStr(name);
return(NULL);
}
__Egregious Trees!!!__
echo Extracting keymap-2
cat > keymap-2 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: keymap-2
date: 1-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: keymap.c
Synopsis: use-local-map complains if given null keymap name
Description:
The old behavior of use-local-map when given a null
string [ie. (use-local-map "") ] was to give an error
message saying that "" was not a keymap. A more useful
behavior is for the function to remove whatever local
keymap exists. For example:
(setq oldmap (current-local-keymap))
(use-local-map "foo")
....
MLisp code
.......
(use-local-map oldmap)
This code fragment will change the local keymap and then
replace it with the old one, even if there was no old
keymap.
Repeat-by:
Fix:
In the C function UseLocalMap, an enclosing if statement
must be added. Find the code fragment:
if (b->b_binding != KeyBound) {
....
}
else
....
and put that fragment inside this if statement where the
four dots are;
if (b->b_name[0]) {
....
}
else
MD_KEYS = NULL;
The if tests to see if the name of the boundname passed
back by ProcArg is null.
--------------- End of patches to keymap.c ------------------------------
__Egregious Trees!!!__
echo Extracting leftoffset-1
cat > leftoffset-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: leftoffset-1
date: 29-Apr-85
posted-to:
fixed-by: nsc!glenn (Glenn Skinner @ National Semiconductor)
source-files: buffer.h display.c
Description:
Buffers are not displayed properly if left-offset > 0,
and the mode line is affected by the left-offset value.
Repeat-by:
Set left-offset to some non-zero value.
Fix:
In the file buffer.h, the definition of the MD_LEFTOFFSET
macro is incorrectly ended with a semicolon. Remove the
semicolon.
In the file display.c, find the function setpos. The two
statements at the beginning that manipulate LeftOffset are
interchanged. The proper code should look like
DSskip = MD_LEFTOFFSET - col + 1;
col -= MD_LEFTOFFSET;
__Egregious Trees!!!__
echo Extracting linenum-1
cat > linenum-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: 2.00, 2.01
ident: linenum-1
date: 21-May-85
posted-to:
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
source-files: lispfuncs.c
Synopsis: line-number hangs when invoked at end of buffer
Description:
The function line-number hangs if invoked when dot
is at the end of a buffer.
Repeat-by:
(end-of-file)
(line-number)
Be prepared to kill the emacs from another terminal.
Fix:
In the file lispfuncs.c, the function LineNumber.
The while loop depends on the NextLine always advancing
dot, which does not happen if dot is already at the end
of the buffer. Add a test after line is incremented to
exit the loop if dot has reached its starting point.
------- begin patch to lispfuncs.c -------------------------------
while (dot <= old_dot) {
NextLine();
line++;
#if FIXED
if (dot == old_dot)
break;
#endif
}
------- End patch to lispfuncs.c -------------------------------
__Egregious Trees!!!__
echo Extracting macros-1
cat > macros-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: macros-1
date: 28-May-85
posted-to:
fixed-by: barnes@tl-20.arpa (Gary Barnes @ Tartan Labs)
source-files: macros.c
Synopsis: defun'ing same name as the current local keymap -> core dump
Description:
When a function is defun'ed (or a macro is defined) with the
same name as the current local keymap, Emacs doesn't realize
that the keymap has gone away and tries to do keymap-ish things
to where it used to be, even though its storage has been free'ed.
Repeat-by:
Execute the following MLisp:
(define-keymap "orn")
(use-local-map "orn")
(defun (orn))
(current-local-keymap)
(use-local-map "orn")
Then type any command key.
This will cause bizarre behavior and probably a core dump,
usually the first time but you may need to execute it more
than once to induce death.
Fix:
This one isn't solved yet. Though it doesn't fix the core
dump, here is a fix for an error in code that is very likely
related:
On approximately line #230 in macros.c$DefMac there are
two if-statements whose then clauses are comparisons (==)
but should be assignments (=).
1) Change
CurrentGlobalMap == &GlobalMap;
to
CurrentGlobalMap = &GlobalMap;
2) Change
MD_KEYS == NULL;
to
MD_KEYS = NULL;
(This argues for the NULL == MD_KEYS coding style...)
--------------- End of patch to macros.c ------------------------------
__Egregious Trees!!!__
echo Extracting mchan41-1
cat > mchan41-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: mchan41-1
date: 29-May-85
posted-to:
fixed-by: tjalk!sjoerd (Sjoerd Mullender)
source-files: mchan4.1.c
Synopsis: subprocesses inherit open files with fd > 2
Description:
Subprocesses started by emacs inherit open files with file
descriptors above 2.
Fix:
In the file mchan4.1.c, in the function start_process,
look for the following code:
(void)dup(newfd);
(void)close(2);
(void)dup(newfd);
execlp(shname, shname, "-c", command,
strcmp(shname+strlen(shname)-3,"csh")==0 ? "-f" : 0, 0);
(void)write(1, "Couldn't exec the shell\n", 24);
Add the following two lines just before the execlp line:
for (newfd = 3; newfd < 20; newfd++)
(void)close(newfd);
--------------- End of patches to mchan4.1.c -------------------------------
__Egregious Trees!!!__
echo Extracting minibuf-1
cat > minibuf-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
ident: minibuf-1
Emacs version: 264, 2.00, 2.01
date: 13-May-85
posted-to:
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
source-files: minibuf.c
Synopsis: core dump on minibuffer commands >40 chars
Description:
Emacs core dumps when strings longer than 40 characters
are inserted into the minibuffer all at once and then read as
a command (or by anything that does getword).
Repeat-by:
Type ESC-x followed by some string more than 40 characters long
with no embedded spaces (typing an unquoted space terminates the
read). The same problem arises if you use ^Y to insert long
strings into the minibuffer. When you type carriage return,
Emacs tries to read the string as a command and core dumps.
Fix:
The problem is that the local prefix in getword was being
overflowed by a strcpy.
The fix is to ensure that the string does not grow too big
by using strncpy and setting the last character position to \000.
In the file minibuf.c in the function getword, change the code
as follows:
------Begin patch to minibuf.c --------------------------------------------
Ding();
#if BUG
(void) strcpy(prefix, word);
#else
(void) strncpy(prefix, word, sizeof(prefix)-1); /* {28} */
prefix[sizeof(prefix)-1] = '\0'; /* {28} */
#endif
if (nfound == FALSE) {
------End patch to minibuf.c --------------------------------------------
__Egregious Trees!!!__
echo Extracting misc-1
cat > misc-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: misc-1
posted-to:
date: 10-May-85
source-files: minibuf.c display.c mlprims.c errlog.c
Synopsis: Various minor problems, not too serious
Description:
Miscellaneous fixes.
-----------------------------------------------------------------------
minibuf.c change declaration of word from int to char *
in function print_table. From nsc!glenn.
minibuf.c at the end of BrGetstr, move the STATE(STATE_NORMAL)
macro inside the block that did the STATE(STATE_MINIBUFINPUT).
display.c A local variable in UpdateLine was not being initialized
because the line was "... od = od = 0" where it should
have been "... od = nd = 0". From nsc!glenn.
mlprims.c In ProgN, the automatic rv is not being set in all cases.
Change "int rv, saverr" to "int rv = 0, saverr".
From nsc!glenn.
errlog.c error-message-format had its default binding pointing at a
string in pure space, so trying to set the default value
caused core dump. Fixed by creating static DflErrorMsgFmt
array:
- enclose the DefStrVar's for [default-]error-message-format
in curly braces
- add the following lines just after the open brace:
static char DflErrorMessageFormat[MAXERRFMTLEN];
(void) strcpy(DflErrorMessageFormat, DFL_ERRFORMAT);
- while you are at it you can move the line
strcpy(ErrorMessageFormat, DFL_ERRFORMAT);
there too.
---------------
__Egregious Trees!!!__
echo Extracting mlarith-1
cat > mlarith-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: 264, V2.00
ident: mlarith-1
date: 15-Mar-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: mlarith.c
Description:
The functions <<, >>, *, and ^ will hang if an error occurs
while they are evaluating their arguments.
Repeat-by:
Execute the MLisp line
(* some-undefined-variable bar)
and be prepared to kill your Emacs from another terminal.
Fix:
The problem is that these functions never check the global
error variable Emacs_Err (err under 264). If an error occurs
while they are processing their arguments, they never notice
and continue to try evaluating them.
In the file mlarith.c (arithmetic.c in 264), in each of the functions
shiftleft
shiftright
times
xor
there is a while loop. Change the condition of that while loop
to terminate if Emacs_Err is TRUE, as in
while (! Emacs_Err && EI.ArgN < EI.ArgMax)
-------------------------------------------------------------------------
__Egregious Trees!!!__
echo Extracting mlisp-1
cat > mlisp-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: mlisp-1
date:
posted-to:
fixed-by: david medinets (unipress!dm)
source-files: mlprims.c
Synopsis: trying to defun a wired function causes core dump
Description:
When MLisp defuned a function with the same name as
a wired primitive Emacs would core dump. This was be-
cause when changing from an if to a case statement, the
scope of the break statements in the function DefineFunc-
tion were changed.
Repeat-by:
Execute the MLisp line
(defun (backward-word (nothing)))
Emacs will core dump if you have this bug.
Fix:
In the C function DefineFunction, there is a
switch (b->b_binding) {
....
}
in the following case statement:
case ProcBound:
....
break;
change the 'break;' to a 'goto dmm;' and insert this
line:
dmm:
before the line containing:
EI.Nis++;
__Egregious Trees!!!__
echo Extracting overwrite-1
cat > overwrite-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: overwrite-1
date: 1-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: simplecoms.c
Synopsis: buffer-is-modified not being updated in overwrite mode
Description:
When making changes while in overwrite mode the
buffer-is-modified variable was not getting updated
(hence the '*' does not appear in the modeline).
Repeat-by:
1> set a buffer in overwrite mode.
2> set buffer-is-modified to 0.
3> make some changes;
4> notice that the modeline has no '*' in it.
Fix:
In the C function simplecoms.c$SelfInsert, look for the if statement;
if (mode_cache.md_Overwrite && CharAt(dot)!='0 && dot <= NumCharacters) {
....
}
Add the following lines to the end of the block:
if (modified_buffer_cache == 0)
Cant1LineOpt = TRUE;
modified_buffer_cache++;
This will update the buffer-is-modified variable and the
test makes sure that the mode line is only updated for
the first change.
--------------- End of patch to simplecoms.c ------------------------------
__Egregious Trees!!!__
echo Extracting overwrite-2
cat > overwrite-2 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: overwrite-2
date: 1-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: simplecoms.c
Synopsis: overwrite mode does not check read-only status
Description:
The Overwrite mode did not check to see if a buffer had
read-only set before making changes.
Repeat-by:
1> set a buffer read-only.
2> try to type something, notice that you can't.
3> put the buffer into overwrite mode.
4> try to type something, notice that you can.
Fix:
In the C function simplecoms.c$SelfInsert, look for the if statement;
if (mode_cache.md_Overwrite && CharAt(dot)!='0 && dot <= NumCharacters) {
....
}
Add the following lines to the beginning of the block:
if (mode_cache.md_ReadOnly) {
(void) sprintf(Err_buf, Err[Err_bufreadonly], bf_cur->b_name);
error(Err_see_errbuf);
return;
}
NOTE: This fix only applies to FULL_EMACS (as opposed to Minimacs).
--------------- End of patch to simplecoms.c ------------------------------
__Egregious Trees!!!__
echo Extracting process-1
cat > process-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: process-1
date: 1-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: mchan4.2.c
Synopsis: ProcessID incorrectly reports error
Description:
In the C function ProcessID there is a mistake in the
call to error.
Repeat-by:
Fix:
In the C function mchan4.2.c$ProcessID, look for the if statment:
if ((p_name = getstr(FALSE, Msg_getprocname)) == NULL) {
....
}
Change the block inside it to these two lines;
(void) sprintf(Err_buf, "I need a process name.");
error(Err_see_errbuf);
__Egregious Trees!!!__gallaher@topaz.ARPA (Mike Gallaher) (05/30/85)
# This is a shar archive. Extract with sh.
echo Extracting process-2
cat > process-2 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: process-2
date: 1-Apr-85
posted-to:
fixed-by: Jamie Watson
source-files: subproc.[ch]
Synopsis: subproc.c won't compile on 8-character-unique preprocessors
Description:
There are some preprocessors that want the defines to be
unique in eight (8) characters. The define WAITCHILD had
a conflict with WAITCHILDNH.
Fix:
The fix is to change WAITCHILD to WAITCHLD in the files
subproc.c and subproc.h.
__Egregious Trees!!!__
echo Extracting quit-1
cat > quit-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: quit-1
date:
posted-to:
fixed-by: jamie watson
source-files: emacs.c
Synopsis:
Description:
A newline was generated even when Emacs did not print
an exiting message. This is sometimes annoying, this fix
is to not print the newline unless a message is really
being printed.
Repeat-by:
Fix:
Change the code segment in the function quit from:
if (message)
printf(message);
to:
if (! STRNULL(message))
printf("%s\n", message);
__Egregious Trees!!!__
echo Extracting quit-2
cat > quit-2 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: quit-2
date: 1-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: emacs.c
Synopsis: bad command line switch causes core dump
Description:
Since all exits from Emacs are done by calling quit, the
display may not have been initialized when quit is
called. This happens, for instance, when a bad switch is
given on the command line; the bad switch is detected and
quit is called before InitWin is called.
Repeat-by:
Invoke Emacs with a bad command line switch, for example
emacs -@
Emacs will core dump.
Fix:
The fix is to check to see if the display subsystem has been
initialized before trying to call DoDsp. In quit, the call
to DoDsp is done only if DisplayInitialized is TRUE. The test
is done in quit rather than in DoDsp to save time in DoDsp.
In the function quit, in the file emacs.c, change the
following line:
DoDsp();
to look like this:
if (DisplayInitialized)
DoDsp();
__Egregious Trees!!!__
echo Extracting subproc-1
cat > subproc-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: 2.00, 2.01
ident: subproc-1
date: 20-May-85
posted-to:
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
source-files: compat.c subproc.c
Synopsis: FilterThrough, ExecBf use variable number of arguments
Description:
The functions FilterThrough and ExecBf in subproc.c accept a
variable number of arguments, which does not work on all machines.
In particular, this does not work on the HP9000 series 500 because
the stack grows in the direction opposite to that of other
machines, so that argument lists built on the stack cannot
be passed to functions like execvp that want an array of char
pointers.
Fix:
The solution is to make all functions that call FilterThrough
and ExecBf set up the arguments in an array of char pointers,
and to call ExecBfp and FilterThroughp with a pointer to that
array. The functions FilterThrough and ExecBf can be eliminated.
Change the code according to the following patches, as if FIXED
was defined non-zero.
----------- Begin patches to subproc.c -----------------------------------
In the function FilterRegion:
if (s = getstr(FALSE,": filter-region (through command) ")) {
#if FIXED
char saveit[MAXSHCOMLEN+1];
char *commands[MAXCOMWORDS];
char **cp = commands;
(void) strncpy(saveit, s, MAXSHCOMLEN);
*cp++ = shell();
*cp++ = "-c";
*cp++ = saveit;
*cp = NULL;
FilterThroughp(ToMark(bf_cur->b_mark) - dot, commands);
}
#else
FilterThrough(ToMark(bf_cur->b_mark) - dot, shell(), "-c", saveit, 0);
#endif
-------------------
In the function ExecuteMonitorCommand:
if ((com = getstr(FALSE,"Unix command: ")) != NULL)
#if FIXED
{
char *command[4];
char **cp = command;
*cp++ = shell();
*cp++ = "-c";
*cp++ = com;
*cp = NULL;
ExecBfp("Command execution", 1, "/dev/null", 1, command);
}
#else
ExecBf("Command execution", 1, "/dev/null", 1, shell(), "-c", com, 0);
#endif
--------------------
Remove the definitions of the functions ExecBf and FilterThrough.
-------------- End patches to subproc.c ------------------------------
*************
-------------- Begin patches to compat.c -----------------------------
In the function IndentCProcedure:
if (nest == 0) {
#if FIXED
char *command[6];
char **cp = command;
SetDot(ScanBf('\n', spos, -1));
*cp++ = "indent";
*cp++ = "-st";
*cp = NULL;
FilterThroughp(pos - dot, command);
#else
SetDot(ScanBf('\n', spos, -1));
FilterThrough(pos - dot, "indent", "-st", 0);
#endif
}
------------
In the function CompileIt:
static char CompileCommand[MAXSHCOMLEN+1];
#if FIXED
char *command[4];
char **cp = command;
if (ModWrite()) {
/*
* this test really shouldn't be done this way, all the prefix
* numeric argument stuff needs to be rationalized
*/
if (ArgState == HaveArg || !interactive) {
if ((com = getstr(FALSE,"Compilation command: ")) == NULL)
return(NULL);
if (*com)
(void) strcpy(CompileCommand, com);
*cp++ = shell();
*cp++ = "-c";
*cp++ = CompileCommand;
} else {
*cp++ = "make";
*cp++ = "-k";
}
*cp = NULL;
ExecBfp("Error log", 1, "/dev/null", 1, command);
#else
if (ModWrite()) {
/*
* this test really shouldn't be done this way, all the prefix
* numeric argument stuff needs to be rationalized
*/
if (ArgState==HaveArg || !interactive) {
if ((com = getstr(FALSE,"Compilation command: ")) == NULL)
return(NULL);
if (*com)
(void) strcpy(CompileCommand, com);
ExecBf("Error log", 1, "/dev/null", 1,shell(),"-c", CompileCommand, 0);
}
else
ExecBf("Error log",1,"/dev/null", 1, "make", "-k", 0);
#endif
-------------- End patches to compat.c -----------------------------
__Egregious Trees!!!__
echo Extracting syntax-1
cat > syntax-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: syntax-1
date: 15-May-85
posted-to:
fixed-by:
source-files: syntax.c
Synopsis: dot-in-comment returns inverse of what it should
Description:
The dot-in-comment function is undocumented, but here is a fix
for it anyway. It returned the inverse of the value it should.
It is also possible to greatly simplify its logic.
Repeat-by:
Use dot-in-comment in some buffer that has had its comment
characters set in its syntax table. A quick way to do this
is to run elec-c-mode.
Fix:
In the file syntax.c, in the function DotInComment, change
the code as follows, as if FIXED were defined as 1:
#if FIXED
MLvalue->exp_int = (p > q);
#else
if (q == FAIL && p == FAIL)
MLvalue->exp_int = FALSE;
else if (p < q)
MLvalue->exp_int = TRUE;
else MLvalue->exp_int = FALSE;
#endif
Also, there is a redundant line
MLvalue->exp_type = IsInteger;
There is one before a comment block, one after. Remove the one
before the comment block.
__Egregious Trees!!!__
echo Extracting ttylock-1
cat > ttylock-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: ttylock-1
date: 1-Apr-85
posted-to:
fixed-by: unipress!dm (David Medinets @ Unipress Software)
source-files: ttylock.c
Synopsis: ttylock.c won't compile properly if ONEEMACSPERTTY TRUE
Description:
When ONEEMACSPERTTY was set to TRUE, ttylock.c would not
compile. Some compilers also complain because fgets is
cast to (char *).
Repeat-by:
Connect to the Emacs source directory and type
make ttylock.o
Fix:
To make ttylock.c compile with ONEEMACSPERTTY set to TRUE:
1) Add the line:
extern char MyTtyName[];
to the beginning of the C function LockTty.
2) Change the declaration of LockTty from hidden to visible.
3) Include the file <stdio.h> at the begining of the file.
To remove the cast of fgets:
1) change the line of code that reads
c = (char *) fgets(buf, sizeof(buf), stdin);
to
c = fgets(buf, sizeof(buf), stdin);
2) change the variable declaration at the beginning of that
same block to:
char buf[10], *c, *fgets();
3) as long as you are in this file, you may as well change
the if statment to read as follows:
if (STRNULL(c) || (*c != 'y' && *c != 'Y'))
quit(FAIL, NULL);
--------------- End of patches to ttylock.c ------------------------------
__Egregious Trees!!!__
echo Extracting unlink-1
cat > unlink-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: 2.00
ident: unlink-1
date: 14-Mar-85
Posted-to: unix-emacs net.emacs
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
source-files: filecmd.c
Description:
unlink-file did not always work properly because it incorrectly
used the value returned by GetTtyFile, which is actually a
pointer to a static string. The string was getting overwritten
by the call to yes.
Fix:
Replace the existing UnlinkFile with the one given below.
------ Begin patch to filecmd.c ----------------------------------------
/* UnlinkFile()
*
* Deletes a file using help facility and file completion.
* There are five cases:
* 1> no file-name given -> raises error.
* 2> file not found interactively -> raises error.
* 3> file deleted interactively -> prints message.
* 4> file not found called by MLisp proc -> returns FAIL.
* 5> file deleted called by MLisp proc -> returns SUCCEED.
*/
hidden int
UnlinkFile()
{
char *fn;
char scratch[MAXDSPLINELEN + 1];
char filename[PATHLEN + 1];
int flag = TRUE;
if ((fn = GetFileName(": unlink-file ")) != NULL && ! Emacs_Err) {
(void) strcpy(filename, fn);
if (interactive) {
(void) sprintf(scratch, "Delete \"%s\"? ", filename);
flag = yes(TRUE, scratch);
}
if (! Emacs_Err && flag) { /* If we should go ahead and rm it */
if (unlink(filename) == FAIL)
if (interactive) { /* it didn't work */
(void) sprintf(Err_buf, Err[Err_nofile], filename);
error(Err_see_errbuf);
} else { /* it did work */
MLvalue->exp_type = IsInteger;
MLvalue->exp_int = FAIL;
}
else
if (interactive)
message(FALSE, Msg_filedeleted);
else
MLvalue->exp_type = IsInteger;
MLvalue->exp_int = SUCCEED;
}
}
else
error(Err_emptyfilename);
return(NULL);
}
------ End patch to filecmd.c ----------------------------------------
__Egregious Trees!!!__
echo Extracting varfix-1
cat > varfix-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: varfix-1
posted-to: net.emacs
date: 15-Mar-85
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
source-files: mlarith.c mlargs.c mlvars.h
Synopsis: ++, --, +=, -=, etc. don't work with system variables
Description:
The ++, --, and assignment/operation operator MLisp
functions (+=, -=, etc.) do not work properly when given
system variables as arguments.
Fix:
There are three files that need to be patched: mlvars.h, mlarith.c,
and mlargs.c.
mlvars.h
--------
1) Change
extern Expression *GetArg1();
to
extern BINDING *GetArg1();
2) Add the following code to mlvars.h, just after the definition
of struct Binding. This defines macros for referencing, reading,
and setting MLisp variables, taking into account whether they are
system or MLisp-defined.
-------------------- start of patch to mlvars.h --------------------
/* Macros for referencing variable values. */
#define IntVarVal(b) (b)->b_exp->exp_int
#define StrVarPtr(b) (b)->b_exp->exp_v.v_string
#define StrVarLen(b) (b)->b_exp->exp_int
#define SysIntVarVal(b) *(int *)((b)->b_exp->exp_v.v_string)
#define SysStrVarPtr(b) (b)->b_exp->exp_v.v_string
#define SysStrVarLen(b) strlen(SysStrVarPtr(b))
/* Macros for reading and setting variable values */
#define GetIntVarVal(b) ((b)->IsSystem ? SysIntVarVal(b) \
: IntVarVal(b))
#define SetIntVarVal(b,n) if ((b)->IsSystem) \
SysIntVarVal(b) = (n);\
else \
IntVarVal(b) = (n)
-------------------- end of patch to mlvars.h --------------------
mlargs.c
--------
Change GetArg1 to return the binding of the first argument rather
than the expression within that binding by doing the following:
1) Change the declared type of the function GetArg from Expression *
to BINDING *.
2) Change the return(e) in GetArg1 [there is only one such return
in this function] to return(b).
mlarith.c
---------
Change plusplus, minusminus, and AsgOp to use the new variable value
macros, and to reflect the change of the type of GetArg1 from Expression to
BINDING. The simplest way to do this is to replace their definitions
entirely with the code below. Following this code in the source file
should be the calls to AsgOp.
-------- begin patch to mlarith.c ------------------------------
/*
* This implements the `++' prefix operator in C. It requires its
* arg to be a varname. It returns the incremented value. (friedl at kentvax)
*/
hidden int
plusplus()
{
register BINDING *b;
register int n;
if ((b = GetArg1()) != NULL) {
n = GetIntVarVal(b);
MLvalue->exp_int = ++n;
SetIntVarVal(b, n);
}
return(NULL);
}
/*
* minusminus()
*
* This implements the -- prefix operator in C. It requires its
* arg to be a varname. It returns the decremented value. (friedl at kentvax)
*/
hidden int
minusminus()
{
register BINDING *b;
register int n;
if ((b = GetArg1()) != NULL) {
n = GetIntVarVal(b);
MLvalue->exp_int = --n;
SetIntVarVal(b, n);
}
return(NULL);
}
/*
* AsgOp(OPNAME, OP)
*
* This macro implements the assignment operator - just
* like those in C. They are of the form
*
* (OP var e1 e2 ...)
*
* where all the expressions are optional. All of them
* return integer values (friedl at Kentvax).
*/
#define AsgOp(OPNAME, OP) \
hidden int \
OPNAME()\
{\
register BINDING *b;\
if ((b = GetArg1()) != NULL)\
{\
register int n = GetIntVarVal(b);\
while (!Emacs_Err && EI.ArgN < EI.ArgMax)\
n OP NumericArg(EI.Nis);\
MLvalue->exp_int = n;\
SetIntVarVal(b, n);\
}\
return(NULL);\
}
-------- end patch to mlarith.c ------------------------------
__Egregious Trees!!!__
echo Extracting variables-3
cat > variables-3 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00
ident: variables-3
date: 1-Apr-85
posted-to:
fixed-by: david medinets (unipress!dm)
source-files: mlvars.c
Synopsis: setting GlobalModeString causes core dump
Repeat-by:
ESC-X set global-mode-string skreltch
Fix:
(The constant MAXDSPLINELEN shown below may have been
changed to MAXGMODESTRLEN in your version of Emacs. If
so, leave it alone and substitute it in the text below.)
display.c or window.c (depending on version number):
the declaration of GlobalModeString should look like this:
char GlobalModeString[MAXDSPLINELEN + 1];
mlvars.c:
The declaration for GlobalModeString must be a
char array with an explicit length, because at least
one compiler (Sun Unix 1.2) generates incorrect code
for any other form of declaration. The declaration
should look like this:
extern char GlobalModeString[MAXDSPLINELEN + 1];
Change the line that initializes it to
GlobalModeString[0] = '\0';
__Egregious Trees!!!__
echo Extracting xonflow-1
cat > xonflow-1 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
Ident: xonflow-1
Date: 7-May-85
fixed-by: unipress!mg (Mike Gallaher @ Unipress Software)
posted-to:
source-files: emacs.c
Synopsis: not easy to start Emacs in xon/xoff flow control mode
Description:
There is no easy way to force Emacs to come up with the
terminal in xon/xoff flow control mode.
Fix:
Add a -x command line option that turns on xon/xoff flow control.
In the file emacs.c, look for the string "case 'h':". This should
be in the command line switch processing code. Just after the
code for the -h switch (i.e., after the break statement), add the
following lines:
case 'x':
{
extern int XonFlow, HalfBaked;
char *s = getmainarg(targc, targv);
HalfBaked = XonFlow = (*s == '0' ? FALSE : TRUE);
}
break;
----
Then add the following lines to the comment above that lists the
command line switches.
* -x[<1|0>] Turns XonFlow and Halbaked on or off.
* Omitting the number turns them on.
------ End of patches to emacs.c -----------------------------------------
__Egregious Trees!!!__
echo Extracting xonflow-2
cat > xonflow-2 << "__Egregious Trees!!!__"
Unipress Emacs Bug Fix
Emacs version: V2.00, V2.01
ident: xonflow-2
date: 29-May-85
posted-to:
fixed-by: tjalk!sjoerd
source-files: mlcompile.c
Synopsis: setting xon/xoff-flow-control in startup files has no effect
Description:
In ExecuteMLispFile the routine DoDsp is called for the L state
indicator. The problem is that when the Globalpro-file is
executed the display is initialized before any initialization file
gets the chance of setting the xon/xoff-flow-control variable.
I have changed this, so that when the display in not yet
initialized the routine DoDsp won't be called.
Repeat-by:
Try to set xon/xoff-flow-control to 1 in a startup file.
It will always be set to 0, no matter what you try to set it to.
Fix:
In the funciton mlcompile.c$ExecuteMLispFile, look for the
following code:
ExecutedDefun = NULL;
if (! STRNULL(fn) && ! Emacs_Err) {
#if 1
GlobalState = STATE_LOADING; /* {8} */
Cant1LineOpt = TRUE;
DoDsp(FALSE);
#endif 1
code = NULL;
Change the code within the #if 1 to the following
extern int DisplayInitialized;
GlobalState = STATE_LOADING; /* {8} */
if (DisplayInitialized) {
Cant1LineOpt = TRUE;
DoDsp(FALSE);
}
--------------- End of patch to mlcompile.c ------------------------------
__Egregious Trees!!!__