Warning

This page has not been updated in a very long time. An initial
update is forthcoming soon (ca. 2001-12-03), and further updates
will occur regularly thereafter.

Last text update: 2001-11-29Last status update: 2001-07-08

Bug Status: Open

Currently open bugs in the release-21-2 branch (pre-21.4),
categories in rough order of priority. Within category, oldest
report is first. Some attempt is made to collect apparently
similar bug reports together. Please report any classification
errors to the Release Manager.

Bug titles are generally taken from report Subject headers, and
include the approximate date in yyyy-mm-dd format. Better summary
descriptions will be added to the original title (not replace it).

Titles are followed by status, platforms affected, version
information (including CVS checkout date and time when available),
developers addressing the problem, a summary description, and
mailing list references. Where mailing list references are not
hyperlinks, that's because I got to it before MHonArc did.

Bug status values include Reported, Replied (meaning that a
developer has acknowledged the bug), Identified (meaning that the
code causing the bug has been localized), Analysis (meaning that a
developer has said he will fix the bug), (Patch) Pending (meaning
a developer has reported a fix), and Fixed (meaning the fix has
been committed and tested).

Showstoppers

A showstopper is a critical bug that justifies postponing
release until a fix is available or judged infeasible, usually one
that manifests cross-platform.

Yeah, ``the management'' simply moved this whole section into
Critical. Them bugs just don't show up often
enough to stop the show; we'll fix them as soon as possible.
That's why we call this gamma, and continue to maintain
21.1. The XEmacs developers all trust their data to
21.4, though. Therefore we offer you the choice by
making the public release.

Critical

Typical critical bugs include failure to build, failure of the
built executable to start, crashes, program errors potentially
resulting in data loss, and security exploits.

Xlib async reply

Status:
AnalysisPlatforms:Versions:
beta45Developers:
Michael Sperber

Argl, this one's back. I've now seen it 4 times within 1 hour, always
when starting a subprocess:
Xlib: unexpected async reply (sequence 0x3b71)!
Xlib: sequence lost (0x1043b > 0x3b71) in reply type 0x17!
Xlib: sequence lost (0x10421 > 0x3b71) in reply type 0x17!
Xlib: sequence lost (0x10000 > 0x3b71) in reply type 0x0!
xemacs: X Error of failed request: 0
Major opcode of failed request: 113 (X_KillClient)
Serial number of failed request: 0
Current serial number in output stream: 15217
It was gone for a long time before beta45.
I'll try reverting some recent patches as soon as I can.

[...] this creates very long entries in the Tools->Grep submenu,
which lists the ten most recent grep commands. Too long, in
fact -- you get errors reported when you try to invoke an
entry on the Grep submenu. Recently, I tried this by
accident, and got a crash!

command_event_queue was indeed empty, but then the call to
event_stream_event_pending_p (1) puts an event onto the
command_event_queue. Now I don't understand how the misc-user
event that was already invoked and processed is getting seen
again, but clearly something is amiss in this code. since this
twisty windy code was reworked a lot for windows and i don't
yet understand it, could some windows expert help?

Patch Fumbles

Patches that people seem to have lost track of....

Patch for bogus cygwin paths in gnuclient (2001-03-16)

Status:
Patch PendingPlatforms:
CygwinVersions:Developers:
Ben Wing

before the patch, I would see [Cygwin] looking for a file name
of: //E\htdocs\file3.php which doesn't exist as a path
name. However, with this patch, it translates it to
/htdocs/file3.php which is correct!

I believe I've tracked this down. It seems to be a problem with xemacs
-unmapped. The following behavior is repeatable in 21.2.45 on 2 RedHat
7.0 systems without a .emacs or .gnus:
1. xemacs -unmapped -f gnuserv-start &
2. gnuclient
3. M-x gnus
4. quit gnus
5. gnuclient -nw
6. M-x gnus in the tty gnuclient.
7. Enter any group.
8. SPC in the *Summary* buffer (`gnus-summary-next-page') does not
scroll the *Article* buffer.
If one kills the X gnuclient (delete-frame), SPC starts to work again.
Start another X gnuclient and SPC will stop working.
This problem does not exist in XEmacs 21.1.12. Without the -unmapped
option, again there is no problem.

The current version of font-locking font-locks the following
file incorrectly.

The first #+:cmu is fontified as if it were a comment, but
it's not. This doesn't happen with 21.2.44.

To see this, I started xemacs -vanilla. Load the file. (The
buffer is not fontified.) Kill the buffer. Load the file
again. Now the buffer is fontified but fontified incorrectly.
If you do the same with 21.2.44, #+:cmu and following is
fontified correctly as lisp code, not a comment.

MS-Windows XEmacs doesn't see fonts with a number in the font name (2001-03-07)

Status:
Reported
Platforms:
Windows
Versions:Developers:

I have a couple of fonts with numbers in the font face, like
"Monospac821 BT". Because of mswindows-font-regexp, they are
skipped over. Changing (fontname "\\([a-zA-Z0-9 ]+\\)") in the
mswindows-font-regexp definition hopefully fix it.

No matter how much of my work uses Cygwin tools, I still use
some things that expect DOS paths, like "C:/path", even with
the forward slashes instead of the backslashes.
Unfortunately, Cygwin-XEmacs doesn't grok that at all.
Completion doesn't work, and "find-file-at-point" gets
similarly confused.

;; Make Alt+accelerator traverse to the menu in new enough XEmacs
;; versions. Note that this only overrides Meta bindings that would
;; actually invoke a menu, and that none of the most common commands
;; are overridden. You can use ESC+key to access the overridden
;; ones if necessary.
(setq menu-accelerator-enabled 'menu-force)

Despite the comment, these commonly used keys now invoke menus
instead. Brrrr!

Setting menu-accelerator-enabled back to 'menu-fallback in a
running 21.2-b45 XEmacs on native Windows 2000 still activates
menus instead of the bound command.

Does it also happen if you compile without ESD support? To me
it very much looks like you are bitten by the problem where
libesd sets up timeout for some reason and the SIGARLM ends up
in our signal handler.

Here is Ben's patch. I made a comment on xemacs-nt
indicating that I thought there was an alternative approach to
the one outlined in Ben's comment in
the patch, but it turns out that it goes to the same place.
:-)

An alternative patch
<15025.44473.601020.23227@turnbull.sk.tsukuba.ac.jp> by
Martin Buchholz that fixes this bug and similar ones, but is
not a complete fix, has been approved.

The best way to deal with the problem is at the moment
controversial; my current thinking is to have a fix
implemented in 21.5 and backported after review and testing.