4 week-old pretest bugs

[Chris Moore]

I've been offline for a week or so, and still have very limited net
connectivity, but since I've been offline I've found a few Emacs bugs
which I thought I should report.  These are from a CVS Emacs 19.22.92
(?) from 22nd or 23rd December, built on GNU/Linux on an Intel 686
system.

These 4 bugs may have been addressed in the last week; I'm unable to
check the current state of the repository, but anyway:

------------------------------------------------------------------------

1. I had a crash after trying the first icon in the gtk toolbar for
the first time.  I used it to find a new file, then typed C-x C-f to
check which directory it had opened it in.  Emacs hung at that point
without displaying the directory.  Here's where:

A program is being debugged already.  Kill it? (y or n) n
Program not killed.
(gdb) where
#0  0xb76aad51 in ?? ()
#1  0x0818ba76 in wait_reading_process_output (time_limit=0, microsecs=0,
   read_kbd=-1, do_display=1, wait_for_cell=137459913, wait_proc=0x0,
   just_wait_proc=0) at process.c:4719
#2  0x080fed51 in read_char (commandflag=1, nmaps=3, maps=0xbfb78780,
   prev_event=137459913, used_mouse_menu=0xbfb78828, end_time=0x0)
   at keyboard.c:4016
#3  0x08101532 in read_key_sequence (keybuf=0xbfb788d4, bufsize=30,
   prompt=137459913, dont_downcase_last=0, can_return_switch_frame=1,
   fix_current_buffer=1) at keyboard.c:9115
#4  0x08102fe5 in command_loop_1 () at keyboard.c:1618
#5  0x08158cfb in internal_condition_case (bfun=0x8102e50 <command_loop_1>,
   handlers=137504569, hfun=0x80fd7f0 <cmd_error>) at eval.c:1481
#6  0x080fcbce in command_loop_2 () at keyboard.c:1329
#7  0x08158dbc in internal_catch (tag=137498553,
   func=0x80fcba0 <command_loop_2>, arg=137459913) at eval.c:1222
#8  0x080fd63e in command_loop () at keyboard.c:1308
#9  0x080fd9c8 in recursive_edit_1 () at keyboard.c:1006
#10 0x080fdab6 in Frecursive_edit () at keyboard.c:1067
#11 0x080f3a32 in main (argc=Cannot access memory at address 0x1d
) at emacs.c:1761
(gdb) q

------------------------------------------------------------------------

2. running 'emacs -Q' and then clicking the first gtk icon sometimes
causes a crash:

Fatal error (6)Aborted

other times it causes this to be printed in the starting terminal,
leaving Emacs hung up:

        Xlib: unexpected async reply (sequence 0x11b5)!

        (emacs:19157): Gdk-CRITICAL **: gdk_window_set_geometry_hints:
assertion `GDK_IS_WINDOW (window)' failed

        (emacs:19157): Gdk-CRITICAL **: gdk_window_move_resize: assertion
`GDK_IS_WINDOW (window)' failed

other times it just displays the 'find file' dialog as it should.

------------------------------------------------------------------------

3. hitting RET on the 'state' button in a customise window prompts for a
character.  hitting <f1> causes a lisp error:

        Debugger entered--Lisp error: (wrong-type-argument stringp [f1])
          string-to-char([f1])
          (setq value (lookup-key overriding-terminal-local-map keys t) char
          (while (not (or ... ...)) (setq unread-command-events (cons 32 unre
          (let ((cursor-in-echo-area t) keys (char 0) (arg 1)) (while (not ..
          (let ((buf ...)) (fit-window-to-buffer (display-buffer buf)) (let (
          (save-window-excursion (let (...) (fit-window-to-buffer ...) (let .
          (let* ((overriding-terminal-local-map ...) (next-digit 48) map choi
          (cond ((and ... event ...) (x-popup-menu event ...)) ((or widget-me
          widget-choose("Operation on Pop Up Windows" ("Set for Current Sessi

------------------------------------------------------------------------

4. My backup-directory-alist's value is (("." . "Backup"))

In the past this has resulted in backups being made in a subdirectory
called 'Backup' of the edited file's directory.
I'm seeing backup files like this in ~/tmp/Backup/:
 -rw-r--r-- 1 chris chris    3 2006-12-22 16:01 !home!chris!tmp!file.txt.~1~
whereas previous the backup file would be simply called "file.txt.~1~"

The docstring for backup-directory-alist tells me:

   DIRECTORY may be relative or absolute.  If it is absolute, so that
   all matching files are backed up into the same directory, the file
   names in this directory will be the full name of the file backed
   up with all directory separators changed to `!' to prevent
   clashes.

my DIRECTORY is "Backup", which is relative, and yet it's being
treated as if it's absolute, due to the
 (setq backup-directory (expand-file-name backup-directory
(file-name-directory file)))
call in make-backup-file-name-1

I can't currently see the CVS repository to examine out recent changes,
but checking lisp/ChangeLog suggests that this change may be the one
which broke this:

   2006-12-17  Richard Stallman  <address@hidden>
        * files.el (make-backup-file-name-1):
        Expand backup-directory explicitly.

Fix:

--- programs/emacs/lisp/files.el        2006-12-22 03:19:57.000000000 +0100
+++ emacs/files.el      2006-12-29 13:15:46.000000000 +0100
@@ -3227,11 +3227,12 @@
(defun make-backup-file-name-1 (file)
  "Subroutine of `make-backup-file-name' and `find-backup-file-name'."
  (let ((alist backup-directory-alist)
-       elt backup-directory)
+       absolute elt backup-directory)
    (while alist
      (setq elt (pop alist))
      (if (string-match (car elt) file)
          (setq backup-directory (cdr elt)
+               absolute (file-name-absolute-p backup-directory)
                alist nil)))
    ;; If backup-directory is relative, it should be relative to the
    ;; file's directory.  By expanding explicitly here, we avoid
@@ -3245,7 +3246,7 @@
          (file-error (setq backup-directory nil))))
    (if (null backup-directory)
        file
-      (if (file-name-absolute-p backup-directory)
+      (if absolute
          (progn
            (when (memq system-type '(windows-nt ms-dos cygwin))
              ;; Normalize DOSish file names: downcase the drive

------------------------------------------------------------------------

I'll be offline again for another few days, so I won't be able to
answer any questions relating to these bugs, but thought it best to
bring them to your attention in case a release was imminent (as if...)