From dak at gnu.org Thu May 1 08:26:32 2008 From: dak at gnu.org (David Kastrup) Date: Thu, 01 May 2008 17:26:32 +0200 Subject: bug#174: 23.0.60; Bug in vc-register with interactive arg Message-ID: <85prs6rqon.fsf@lola.goethe.zz> Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug at gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: C-u C-x v i Debugger entered--Lisp error: (wrong-type-argument stringp (4)) get-file-buffer((4)) vc-register((4)) call-interactively(vc-register nil nil) In GNU Emacs 23.0.60.8 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2008-05-01 on lola Windowing system distributor `The X.Org Foundation', version 11.0.10400090 configured using `configure '--prefix=/usr/local/emacs-21' '--without-toolkit-scroll-bars' 'CFLAGS=-g -O2 -fno-crossjumping'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Debugger Minor modes in effect: shell-dirtrack-mode: t TeX-PDF-mode: t desktop-save-mode: t minibuffer-electric-default-mode: t iswitchb-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-u C-x v i M-x r e p o r t - e m a c s - b u Recent messages: Press C-c C-c when you are done editing. Registering /home/tmp/akt/Historismus_III.tex... Entering debugger... Back to top level. Quit Type C-x 4 C-o RET to restore the other window, C-M-v to scroll help. Entering debugger... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From dak at gnu.org Thu May 1 10:45:45 2008 From: dak at gnu.org (David Kastrup) Date: Thu, 01 May 2008 19:45:45 +0200 Subject: bug#175: 23.0.60; VCS problem when loading Message-ID: <853ap1c3zq.fsf@lola.goethe.zz> Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug at gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: This happens when loading the desktop, but is likely not related. Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size") find-auto-coding("/home/dak/tex/tr/troeltsch.cls,v" 8192) set-auto-coding("/home/dak/tex/tr/troeltsch.cls,v" 8192) insert-file-contents("/home/dak/tex/tr/troeltsch.cls,v" nil 0 8192) vc-insert-file("/home/dak/tex/tr/troeltsch.cls,v" "^[0-9]") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-fetch-master-state("/home/dak/tex/tr/troeltsch.cls") vc-rcs-checkout-model("/home/dak/tex/tr/troeltsch.cls") vc-rcs-state-heuristic("/home/dak/tex/tr/troeltsch.cls") apply(vc-rcs-state-heuristic "/home/dak/tex/tr/troeltsch.cls") vc-call-backend(RCS state-heuristic "/home/dak/tex/tr/troeltsch.cls") vc-state("/home/dak/tex/tr/troeltsch.cls") vc-default-mode-line-string(RCS "/home/dak/tex/tr/troeltsch.cls") apply(vc-default-mode-line-string RCS "/home/dak/tex/tr/troeltsch.cls") vc-call-backend(RCS mode-line-string "/home/dak/tex/tr/troeltsch.cls") vc-mode-line("/home/dak/tex/tr/troeltsch.cls") vc-find-file-hook() run-hooks(find-file-hook) after-find-file(nil t) find-file-noselect-1(# "~/tex/tr/troeltsch.cls" nil nil "~/tex/tr/troeltsch.cls" (32463 65037)) find-file-noselect("/home/dak/tex/tr/troeltsch.cls") desktop-buffer-preview("/home/dak/tex/tr/troeltsch.cls" "troeltsch.cls" nil) #[nil " ?A??\n\f#?" [desktop-buffer-major-mode desktop-buffer-mode-handlers desktop-buffer-file-name desktop-buffer-name desktop-buffer-misc desktop-restore-file-buffer] 4]() desktop-create-buffer(206 "/home/dak/tex/tr/troeltsch.cls" "troeltsch.cls" latex-mode (auto-fill-mode reftex-mode) 1 (nil nil) nil nil ((indent-tabs-mode) (buffer-file-coding-system . iso-latin-1-unix))) eval-buffer(# nil "/home/dak/.emacs.desktop" nil t) ; Reading at buffer position 66494 load-with-code-conversion("/home/dak/.emacs.desktop" "/home/dak/.emacs.desktop" t t) load("/home/dak/.emacs.desktop" t t t) desktop-read() #[nil "?? ??? \"?)\n?? ????" [key command-line-args desktop-save-mode inhibit-startup-screen "--no-desktop" delete nil desktop-read t] 4]() run-hooks(after-init-hook) command-line() normal-top-level() If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /usr/local/emacs-21/share/emacs/23.0.60/etc/DEBUG for instructions. In GNU Emacs 23.0.60.8 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2008-05-01 on lola Windowing system distributor `The X.Org Foundation', version 11.0.10400090 configured using `configure '--prefix=/usr/local/emacs-21' '--without-toolkit-scroll-bars' 'CFLAGS=-g -O2 -fno-crossjumping'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Debugger Minor modes in effect: TeX-PDF-mode: t desktop-save-mode: t minibuffer-electric-default-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: > < M-x r e p o r t Recent messages: Sorting environment... Removing duplicates... done Applying style hooks... done Applying style hooks... done Sorting environment... Removing duplicates... done Applying style hooks... done Entering debugger... Mark set [2 times] Making completion list... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From drew.adams at oracle.com Thu May 1 13:20:47 2008 From: drew.adams at oracle.com (Drew Adams) Date: Thu, 1 May 2008 13:20:47 -0700 Subject: bug#176: 23.0.60; comment in dired-x.el Message-ID: <008801c8abc8$d7931a50$c2b22382@us.oracle.com> In dired-x.el: ;;; Brief Description: ;;; ;;; `dired-do-shell-command' is bound to `!' by dired.el. ;;; ;;; * Redefine `dired-do-shell-command' so it calls ;;; `dired-guess-shell-command'. There are no other occurrences of `dired-do-shell-command' in the file, so I don't see how it could be redefined there. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-04-19 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' From drew.adams at oracle.com Thu May 1 13:51:07 2008 From: drew.adams at oracle.com (Drew Adams) Date: Thu, 1 May 2008 13:51:07 -0700 Subject: bug#177: 23.0.60; doc for read-from-minibuffer Message-ID: <008f01c8abcd$14683c40$c2b22382@us.oracle.com> Arg DEFAULT can now be a list. This is not reflected in the doc string. And the Elisp manual doc is not clear about what happens with non-nil READ and list-valued DEFAULT: If READ is non-`nil', then DEFAULT is also used as the input to `read', if the user enters empty input. Does this mean the whole list DEFAULT is passed to `read'. Allow me to mention also that letting DEFAULT be a list also breaks code that I have, FWIW... In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-04-19 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' From drew.adams at oracle.com Thu May 1 14:02:17 2008 From: drew.adams at oracle.com (Drew Adams) Date: Thu, 1 May 2008 14:02:17 -0700 Subject: bug#178: 23.0.60; C-h i puts point at end of dir menu, not start [eom] Message-ID: <009401c8abce$a3f1e1d0$c2b22382@us.oracle.com> Subject says it all. This is a regression. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-04-19 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' From dak at gnu.org Thu May 1 14:56:22 2008 From: dak at gnu.org (David Kastrup) Date: Thu, 01 May 2008 23:56:22 +0200 Subject: bug#179: 23.0.60; Menu separators are not displayed Message-ID: <85hcdhadtl.fsf@lola.goethe.zz> Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug at gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I have a menu looking like preview-menu's value is shown below. Documentation: This is the menu for preview-latex. Value: (keymap "Preview" (nil menu-item "Generate previews") ($or\ toggle$\ at\ point menu-item "(or toggle) at point" preview-at-point ([3 16 16] . " C-c C-p C-p")) (for\ environment menu-item "for environment" preview-environment ([3 16 5] . " C-c C-p C-e")) (for\ section menu-item "for section" preview-section ([3 16 19] . " C-c C-p C-s")) (for\ region menu-item "for region" preview-region ([3 16 18] . " C-c C-p C-r") :enable (preview-mark-active)) (for\ buffer menu-item "for buffer" preview-buffer ([3 16 2] . " C-c C-p C-b")) (for\ document menu-item "for document" preview-document ([3 16 4] . " C-c C-p C-d")) (nil menu-item "---") (nil menu-item "Remove previews") (at\ point menu-item "at point" preview-clearout-at-point ([3 16 3 16] . " C-c C-p C-c C-p")) (from\ section menu-item "from section" preview-clearout-section ([3 16 3 19] . " C-c C-p C-c C-s")) (from\ region menu-item "from region" preview-clearout ([3 16 3 18] . " C-c C-p C-c C-r") :enable (preview-mark-active)) (from\ buffer menu-item "from buffer" preview-clearout-buffer ([3 16 3 2] . " C-c C-p C-c C-b")) (from\ document menu-item "from document" preview-clearout-document ([3 16 3 4] . " C-c C-p C-c C-d")) (nil menu-item "---") (nil menu-item "Turn preamble cache") (on menu-item "on" preview-cache-preamble ([3 16 6] . " C-c C-p C-f")) (off menu-item "off" preview-cache-preamble-off ([3 16 3 6] . " C-c C-p C-c C-f")) (nil menu-item "---") (Customize menu-item "Customize" (keymap "Customize" (Browse\ options menu-item "Browse options" menu-function-194 (nil) :key-sequence nil) (Extend\ this\ menu menu-item "Extend this menu" menu-function-195 (nil) :key-sequence nil))) (Read\ documentation menu-item "Read documentation" preview-goto-info-page ([3 16 9] . " C-c C-p TAB")) (Report\ Bug menu-item "Report Bug" preview-report-bug (nil))) [back] and neither the separator lines nor the separator titles are shown. This menu was generated using (easy-menu-define preview-menu LaTeX-mode-map "This is the menu for preview-latex." '("Preview" "Generate previews" ["(or toggle) at point" preview-at-point] ["for environment" preview-environment] ["for section" preview-section] ["for region" preview-region (preview-mark-active)] ["for buffer" preview-buffer] ["for document" preview-document] "---" "Remove previews" ["at point" preview-clearout-at-point] ["from section" preview-clearout-section] ["from region" preview-clearout (preview-mark-active)] ["from buffer" preview-clearout-buffer] ["from document" preview-clearout-document] "---" "Turn preamble cache" ["on" preview-cache-preamble] ["off" preview-cache-preamble-off] "---" ("Customize" ["Browse options" (customize-group 'preview)] ["Extend this menu" (easy-menu-add-item nil '("Preview") (customize-menu-create 'preview))]) ["Read documentation" preview-goto-info-page] ["Report Bug" preview-report-bug])) In GNU Emacs 23.0.60.8 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2008-05-01 on lola Windowing system distributor `The X.Org Foundation', version 11.0.10400090 configured using `configure '--prefix=/usr/local/emacs-21' '--without-toolkit-scroll-bars' 'CFLAGS=-g -O2 -fno-crossjumping'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: LaTeX Minor modes in effect: reftex-mode: t desktop-save-mode: t minibuffer-electric-default-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-x k C-x b b o g i f g o f o < C-/ < C-s h y p p e r r e f C-s C-s C-s

C-x b p r e v C-g C-x o C-x C-f / h o m e p / t m p / a u c t e x / p r e v i e w / p r v - e m C-x 1 C-g C-s o n C-s m e n u C-s C-s C-s C-x b C-g C-x C-f m e n p r e v i e w . e l C-s m e n u C-s C-s C-s C-s C-s C-s C-h v p r e v i e w - m e n C-x o C-x b b i g f o o t . t e d i s s . t e x

Recent messages: Quit Note: file is write protected Undo! Mark set Mark saved where search started Quit [2 times] Mark saved where search started [2 times] Quit Mark saved where search started Type C-x 1 to delete the help window, C-M-v to scroll help. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum From smcracraft at gmail.com Thu May 1 15:59:50 2008 From: smcracraft at gmail.com (Stuart Cracraft) Date: Thu, 01 May 2008 15:59:50 -0700 Subject: bug#180: GNU Emacs Lisp Message-ID: <481A4B66.9020805@cox.net> Hi All, I see that when running a program in GNU Emacs Lisp that errors in the message area below the mode-line but without a line-number corresponding to the line of the error in the source code being run. So, without the line number, it is hunt-and-peck, much harder to find the section of code with the problem. Is there a way to locate the erring S-expression more quickly? I have used edebug, by the way, and am seeking something like the above as well, unless edebug can stop exactly at the line in the source code where the S-expression is broken, without having to single-step it. Thanks ahead (anyone), Stuart From markus.triska at gmx.at Thu May 1 22:29:01 2008 From: markus.triska at gmx.at (Markus Triska) Date: Fri, 2 May 2008 07:29:01 +0200 (CEST) Subject: bug#181: 23.0.60; OSX: Case insensitive file name completion Message-ID: <20080502052901.C805083E036@mt-computer.local> On OSX 10.4.11, I have ~/Desktop and ~/DES.pdf. Until recently, when I did "C-x C-f ~/Des TAB", it would expand to Desktop. Now, both "DES.pdf" and "Desktop" are considered possible expansions of "Des". I see the point, because the default file system on OSX appears to be case insensitive. Still, it is a regression for me: I find the previous default behaviour of Emacs (which is also the default in 22.2) much better, since it often allows faster expansion if you know the stored case of a file. Is there a way to get it back? Thanks! In GNU Emacs 23.0.60.2 (i386-apple-darwin8.11.1, GTK+ Version 2.12.9) of 2008-04-29 on mt-computer.local Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000 configured using `configure '--disable-font-backend'' From cyd at stupidchicken.com Fri May 2 08:17:03 2008 From: cyd at stupidchicken.com (Chong Yidong) Date: Fri, 02 May 2008 11:17:03 -0400 Subject: bug#180: GNU Emacs Lisp Message-ID: <871w4k91n4.fsf@stupidchicken.com> > I see that when running a program in GNU Emacs Lisp > that errors in the message area below the mode-line but > without a line-number corresponding to the line of the > error in the source code being run. > > So, without the line number, it is hunt-and-peck, much > harder to find the section of code with the problem. Is there > a way to locate the erring S-expression more quickly? Set debug-on-error to t, and you will get a backtrace, which can be used to jump to the function that signalled the error (as well as the functions that called it). From smcracraft at gmail.com Fri May 2 08:29:30 2008 From: smcracraft at gmail.com (Stuart Cracraft) Date: Fri, 02 May 2008 08:29:30 -0700 Subject: bug#180: GNU Emacs Lisp In-Reply-To: <871w4k91n4.fsf@stupidchicken.com> References: <871w4k91n4.fsf@stupidchicken.com> Message-ID: <481B335A.5060400@cox.net> Chong, Thankyou very much. Stuart Chong Yidong wrote: >> I see that when running a program in GNU Emacs Lisp >> that errors in the message area below the mode-line but >> without a line-number corresponding to the line of the >> error in the source code being run. >> >> So, without the line number, it is hunt-and-peck, much >> harder to find the section of code with the problem. Is there >> a way to locate the erring S-expression more quickly? >> > > Set debug-on-error to t, and you will get a backtrace, which can be used > to jump to the function that signalled the error (as well as the > functions that called it). > > From don at donarmstrong.com Fri May 2 09:05:05 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Fri, 2 May 2008 09:05:05 -0700 Subject: Processed: Close In-Reply-To: <87lk2s9031.fsf@stupidchicken.com> References: <87lk2s9031.fsf@stupidchicken.com> Message-ID: Processing commands for control at emacsbugs.donarmstrong.com: > close 180 bug#180: GNU Emacs Lisp 'close' is deprecated; see http://emacsbugs.donarmstrong.com/Developer.html#closing. bug closed, send any further explanations to Stuart Cracraft > thanks Stopping processing here. Please contact me if you need assistance. Don Armstrong (administrator, Emacs bugs database) From don at donarmstrong.com Fri May 2 09:05:07 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Fri, 2 May 2008 09:05:07 -0700 Subject: bug#176: marked as done (23.0.60; comment in dired-x.el) References: <87iqxw8zwq.fsf@stupidchicken.com> <008801c8abc8$d7931a50$c2b22382@us.oracle.com> Message-ID: Your message dated Fri, 02 May 2008 11:54:29 -0400 with message-id <87iqxw8zwq.fsf at stupidchicken.com> and subject line Re: 23.0.60; comment in dired-x.el has caused the Emacs bug report #176, regarding 23.0.60; comment in dired-x.el to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don at donarmstrong.com immediately.) -- 176: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=176 Emacs Bug Tracking System Contact don at donarmstrong.com with problems -------------- next part -------------- An embedded message was scrubbed... From: "Drew Adams" Subject: 23.0.60; comment in dired-x.el Date: Thu, 1 May 2008 13:20:47 -0700 Size: 5823 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080502/cbdb4fa8/attachment.eml -------------- next part -------------- An embedded message was scrubbed... From: Chong Yidong Subject: Re: 23.0.60; comment in dired-x.el Date: Fri, 02 May 2008 11:54:29 -0400 Size: 1343 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080502/cbdb4fa8/attachment-0001.eml From yazicivo at ttmail.com Fri May 2 07:32:55 2008 From: yazicivo at ttmail.com (Volkan YAZICI) Date: Fri, 02 May 2008 17:32:55 +0300 Subject: bug#182: 23.0.60; Broken C-M-\ after ctrl:swapcaps Message-ID: <871w4khj3c.fsf@alamut.mobiliz.com.tr> Hi, I switched my Caps_Lock and Control_L keys via $ setxkbmap -option "ctrl:swapcaps" command on a Turkish (Q Layout) keyboard because of buggy[1] Ctrl_L key of HP Pavilion dv6580et notebook. But this change broke my C-M-\ combination. In emacs, "C-h k C-M-\" doesn't produce anything, it still waits for an input with "Describe key (or click or menu item):" line. I don't know if this is a emacs specific problem, but xev outputs looks right: Pressed Key | xev keysym ----------------+----------- Caps_Lock | Control_L Alt_L | Alt_L AltGr[2] | ISO_Level3_Shift Asterisk | Asterisk AltGr-Asterisk | Backslash By the way, I know if its related but am running emacs within a screen session inside aterm. Here are some related environment variables: declare -x COLORFGBG="default;default;15" declare -x COLORTERM="rxvt-xpm" declare -x LANG="en_US.UTF-8" declare -x SHELL="/bin/bash" declare -x TERM="screen" declare -x TERMCAP="SC|screen|VT 100/ANSI X3.64 virtual terminal:\\ :DO=\\E[%dB:LE=\\E[%dD:RI=\\E[%dC:UP=\\E[%dA:bs:bt=\\E[Z:\\ :cd=\\E[J:ce=\\E[K:cl=\\E[H\\E[J:cm=\\E[%i%d;%dH:ct=\\E[3g:\\ :do=^J:nd=\\E[C:pt:rc=\\E8:rs=\\Ec:sc=\\E7:st=\\EH:up=\\EM:\\ :le=^H:bl=^G:cr=^M:it#8:ho=\\E[H:nw=\\EE:ta=^I:is=\\E)0:\\ :li#54:co#146:am:xn:xv:LP:sr=\\EM:al=\\E[L:AL=\\E[%dL:\\ :cs=\\E[%i%d;%dr:dl=\\E[M:DL=\\E[%dM:dc=\\E[P:DC=\\E[%dP:\\ :im=\\E[4h:ei=\\E[4l:mi:IC=\\E[%d@:ks=\\E[?1h\\E=:\\ :ke=\\E[?1l\\E>:vi=\\E[?25l:ve=\\E[34h\\E[?25h:vs=\\E[34l:\\ :ti=\\E[?1049h:te=\\E[?1049l:us=\\E[4m:ue=\\E[24m:so=\\E[3m:\\ :se=\\E[23m:mb=\\E[5m:md=\\E[1m:mr=\\E[7m:me=\\E[m:ms:\\ :Co#8:pa#64:AF=\\E[3%dm:AB=\\E[4%dm:op=\\E[39;49m:AX:\\ :vb=\\Eg:G0:as=\\E(0:ae=\\E(B:\\ :ac=\\140\\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\\ :po=\\E[5i:pf=\\E[4i:k0=\\E[10~:k1=\\EOP:k2=\\EOQ:k3=\\EOR:\\ :k4=\\EOS:k5=\\E[15~:k6=\\E[17~:k7=\\E[18~:k8=\\E[19~:\\ :k9=\\E[20~:k;=\\E[21~:F1=\\E[23~:F2=\\E[24~:F3=\\E[25~:\\ :F4=\\E[26~:F5=\\E[28~:F6=\\E[29~:F7=\\E[31~:F8=\\E[32~:\\ :F9=\\E[33~:FA=\\E[34~:kb=:K1=\\EOw:K2=\\EOu:K3=\\EOy:\\ :K4=\\EOq:K5=\\EOs:kB=\\E[Z:kE=\\E[8\\^:*4=\\E[3\$:*7=\\E[8\$:\\ :#2=\\E[7\$:#3=\\E2\$:#4=\\E[d:%c=\\E[6\$:%e=\\E[5\$:%i=\\E[c:\\ :kh=\\E[1~:@1=\\E[1~:kH=\\E[4~:@7=\\E[4~:kN=\\E[6~:kP=\\E[5~:\\ :kI=\\E[2~:kD=\\E[3~:ku=\\EOA:kd=\\EOB:kr=\\EOC:kl=\\EOD:km:" Regards. [1] I don't know experience of others but keyboard totally sucks on HP Pavilion dv6000 series. While pressing Control_L continuosly (think C-f, C-b, C-p, C-n scenarios) it skips Control_L too may times. [2] Just on the right next of the space bar. In GNU Emacs 23.0.60.2 (x86_64-unknown-linux-gnu) of 2008-03-13 on alamut configured using `configure '--without-x'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: erc-list-mode: t erc-menu-mode: t erc-autojoin-mode: t erc-ring-mode: t erc-networks-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-track-minor-mode: t erc-match-mode: t erc-button-mode: t erc-fill-mode: t erc-stamp-mode: t erc-netsplit-mode: t gnus-topic-mode: t gnus-undo-mode: t erc-irccontrols-mode: t erc-noncommands-mode: t erc-move-to-prompt-mode: t erc-readonly-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: RET C-x b * G r TAB RET C-u 2 g p p p C-x b * G r TAB RET C-u 2 g p p p p p p p p p SPC n n n q C-u 2 g p p SPC q SPC n n n n n n n n n n n n n n n q ESC x r e p o r t - e m a c s - b u f TAB RET DEL g RET Recent messages: Generating summary...done Retrieving newsgroup: bildirgec... Fetching headers for bildirgec...done Generating summary...done Retrieving newsgroup: slashdot... Fetching headers for slashdot...done Generating summary...done Retrieving newsgroup: reddit-science... Fetching headers for reddit-science...done Generating summary...done From svenjoac at gmx.de Fri May 2 12:45:04 2008 From: svenjoac at gmx.de (Sven Joachim) Date: Fri, 02 May 2008 21:45:04 +0200 Subject: bug#153: 23.0.60; Minibuffer for M-x dired broken In-Reply-To: (Stefan Monnier's message of "Fri, 02 May 2008 13:20:28 -0400") References: <877ieey3ym.fsf@gmx.de> <87tzhiwn9y.fsf@gmx.de> Message-ID: <87r6ckbidb.fsf@gmx.de> On 2008-05-02 19:20 +0200, Stefan Monnier wrote: >>> Start Emacs somewhere, e.g. in your home directory, and type C-x d >>> /usr. The original part of the filename is not greyed out as it's >>> supposed to be with file-name-shadow-mode enabled, and if you press RET, >>> you get an error message: >>> >>> Reading directory: no such file or directory, /home/sven/usr > > Thanks, should be fixed now, Yes, thank you (closing bug #173). BTW, I just discovered your comments on bug #153. They missed me because a) you did not CC me, and I am not subscribed to the Emacs bug tracker; b) I did not even know that I submitted a bug report (it was just a question sent to emacs-devel, and you seem to have resent it to submit at emacsbugs.donarmstrong.com). I do quite like the latest completion code, but can imagine that other people might find it a bit confusing. Also, if a directory has no non-trivial subdirectories, C-x d TAB completes to . and .., which is probably less useful than immediately listing all possible file name completions. Sven From don at donarmstrong.com Fri May 2 12:55:07 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Fri, 2 May 2008 12:55:07 -0700 Subject: bug#173: marked as done (23.0.60; Minibuffer for M-x dired broken) References: <87r6ckbidb.fsf@gmx.de> <877ieey3ym.fsf@gmx.de> Message-ID: Your message dated Fri, 02 May 2008 21:45:04 +0200 with message-id <87r6ckbidb.fsf at gmx.de> and subject line Re: 23.0.60; Minibuffer for M-x dired broken has caused the Emacs bug report #173, regarding 23.0.60; Minibuffer for M-x dired broken to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don at donarmstrong.com immediately.) -- 173: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=173 Emacs Bug Tracking System Contact don at donarmstrong.com with problems -------------- next part -------------- An embedded message was scrubbed... From: Sven Joachim Subject: 23.0.60; Minibuffer for M-x dired broken Date: Thu, 01 May 2008 07:43:13 +0200 Size: 8496 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080502/98628aeb/attachment.eml -------------- next part -------------- An embedded message was scrubbed... From: Sven Joachim Subject: Re: 23.0.60; Minibuffer for M-x dired broken Date: Fri, 02 May 2008 21:45:04 +0200 Size: 2612 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080502/98628aeb/attachment-0001.eml From monnier at iro.umontreal.ca Fri May 2 18:25:15 2008 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Fri, 02 May 2008 21:25:15 -0400 Subject: bug#153: 23.0.60; Minibuffer for M-x dired broken In-Reply-To: <87r6ckbidb.fsf@gmx.de> (Sven Joachim's message of "Fri, 02 May 2008 21:45:04 +0200") References: <877ieey3ym.fsf@gmx.de> <87tzhiwn9y.fsf@gmx.de> <87r6ckbidb.fsf@gmx.de> Message-ID: > I do quite like the latest completion code, Glad to hear it. > but can imagine that other people might find it a bit confusing. Time will tell. > Also, if a directory has no non-trivial subdirectories, C-x d TAB > completes to . and .., which is probably less useful than immediately > listing all possible file name completions. Good point, Stefan From mah at everybody.org Sat May 3 10:41:23 2008 From: mah at everybody.org (Mark A. Hershberger) Date: Sat, 03 May 2008 13:41:23 -0400 Subject: bug#183: 23.0.60; !MEM FULL! and pixbuf errors when viewing SVG without a viewBox Message-ID: <87od7n1e0s.fsf@everybody.org> Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug at gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I have the following super-simple SVG file: When I load this in emacs (using ?emacs -q --no-site-file?), I can hit C-c C-c and view the file without a problem. When I remove the viewBox attribute from the svg element, and hit C-c C-c, I get the following on the console: (emacs:30299): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed (emacs:30299): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed (emacs:30299): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels: assertion `pixbuf != NULL' failed (emacs:30299): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion `pixbuf != NULL' failed Hitting C-c C-c again to return to the xml representation of the image results in ?!MEM FULL!? showing up in the lower left-hand corner of the frame. The text does appear, though. In GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.12.0) of 2008-03-29 on iridium, modified by Debian (emacs-snapshot package, version 1:20080329-1) Windowing system distributor `The X.Org Foundation', version 11.0.10400090 configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.60/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.60/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.0.60/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--enable-font-backend' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 Ideas create idols; only wonder leads to knowing. -- St. Gregory of Nyssa From sand at blarg.net Sat May 3 10:38:19 2008 From: sand at blarg.net (sand at blarg.net) Date: 3 May 2008 17:38:19 -0000 Subject: bug#184: Resolved underline problem needs to be reflected in etc/PROBLEMS Message-ID: <20080503173819.25361.qmail@priss.frightenedpiglet.com> From drew.adams at oracle.com Sat May 3 14:19:27 2008 From: drew.adams at oracle.com (Drew Adams) Date: Sat, 3 May 2008 14:19:27 -0700 Subject: bug#185: 23.0.60; incremental search in Info is broken Message-ID: <002401c8ad63$5eb273a0$0200a8c0@us.oracle.com> emacs -Q C-h i, choose Elisp manual C-s this-command Repeat C-s. It stops at the "File:" occurrence at the beginning of each node. I've also seen it stop after a link that does not contain the sought text - for instance, searching for "minibuffer" it stops after a link with text "mode-line". In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-04-19 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' From don at donarmstrong.com Sat May 3 19:15:04 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Sat, 3 May 2008 19:15:04 -0700 Subject: bug#178: marked as done (23.0.60; C-h i puts point at end of dir menu, not start [eom]) References: <87iqxu6d4m.fsf@stupidchicken.com> <009401c8abce$a3f1e1d0$c2b22382@us.oracle.com> Message-ID: Your message dated Sat, 03 May 2008 22:01:45 -0400 with message-id <87iqxu6d4m.fsf at stupidchicken.com> and subject line Re: 23.0.60; C-h i puts point at end of dir menu, not start [eom] has caused the Emacs bug report #178, regarding 23.0.60; C-h i puts point at end of dir menu, not start [eom] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don at donarmstrong.com immediately.) -- 178: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=178 Emacs Bug Tracking System Contact don at donarmstrong.com with problems -------------- next part -------------- An embedded message was scrubbed... From: "Drew Adams" Subject: 23.0.60; C-h i puts point at end of dir menu, not start [eom] Date: Thu, 1 May 2008 14:02:17 -0700 Size: 5565 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080503/798e2b7d/attachment.eml -------------- next part -------------- An embedded message was scrubbed... From: Chong Yidong Subject: Re: 23.0.60; C-h i puts point at end of dir menu, not start [eom] Date: Sat, 03 May 2008 22:01:45 -0400 Size: 1050 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080503/798e2b7d/attachment-0001.eml From don at donarmstrong.com Sat May 3 19:20:03 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Sat, 3 May 2008 19:20:03 -0700 Subject: bug#171: marked as done (patch for dired-format-columns-of-files) References: <8763tu6ctr.fsf@stupidchicken.com> Message-ID: Your message dated Sat, 03 May 2008 22:08:16 -0400 with message-id <8763tu6ctr.fsf at stupidchicken.com> and subject line Re: patch for dired-format-columns-of-files has caused the Emacs bug report #171, regarding patch for dired-format-columns-of-files to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don at donarmstrong.com immediately.) -- 171: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=171 Emacs Bug Tracking System Contact don at donarmstrong.com with problems -------------- next part -------------- An embedded message was scrubbed... From: "Toru TSUNEYOSHI" Subject: patch for dired-format-columns-of-files Date: Thu, 1 May 2008 02:50:53 +0900 Size: 5110 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080503/70feb4b1/attachment.eml -------------- next part -------------- An embedded message was scrubbed... From: Chong Yidong Subject: Re: patch for dired-format-columns-of-files Date: Sat, 03 May 2008 22:08:16 -0400 Size: 1181 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080503/70feb4b1/attachment-0001.eml From don at donarmstrong.com Sat May 3 19:35:03 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Sat, 3 May 2008 19:35:03 -0700 Subject: bug#177: marked as done (23.0.60; doc for read-from-minibuffer) References: <87lk2q4xor.fsf@stupidchicken.com> <008f01c8abcd$14683c40$c2b22382@us.oracle.com> Message-ID: Your message dated Sat, 03 May 2008 22:20:36 -0400 with message-id <87lk2q4xor.fsf at stupidchicken.com> and subject line Re: 23.0.60; doc for read-from-minibuffer has caused the Emacs bug report #177, regarding 23.0.60; doc for read-from-minibuffer to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don at donarmstrong.com immediately.) -- 177: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=177 Emacs Bug Tracking System Contact don at donarmstrong.com with problems -------------- next part -------------- An embedded message was scrubbed... From: "Drew Adams" Subject: 23.0.60; doc for read-from-minibuffer Date: Thu, 1 May 2008 13:51:07 -0700 Size: 5946 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080503/e91c4bd4/attachment-0002.eml -------------- next part -------------- An embedded message was scrubbed... From: Chong Yidong Subject: Re: 23.0.60; doc for read-from-minibuffer Date: Sat, 03 May 2008 22:20:36 -0400 Size: 1342 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080503/e91c4bd4/attachment-0003.eml From eric at siege-engine.com Sat May 3 18:45:06 2008 From: eric at siege-engine.com (Eric M. Ludlam) Date: Sat, 3 May 2008 21:45:06 -0400 Subject: bug#186: 23.0.50; can't debug `message' Message-ID: <200805040145.m441j6cm016447@projectile.siege-engine.com> I was trying to figure out where a stray output message was coming from, so I tried: M-x debug-on-entry RET message RET but sadly, this put Emacs into a state where I couldn't do anything, and I had to kill it because it kept exceeding it's stack depth. In GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-09-10 on projectile Windowing system distributor `The XFree86 Project, Inc', version 11.0.40300000 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input:

M-x r e p o r Recent messages: Making completion list... Invalid face reference: quote [10 times] Making completion list... Invalid face reference: quote [10 times] Making completion list... Invalid face reference: quote [10 times] Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done Invalid face reference: quote [10 times] From ofv at wanadoo.es Sat May 3 17:03:50 2008 From: ofv at wanadoo.es (=?UTF-8?Q?=C3=93scar?= Fuentes) Date: Sun, 04 May 2008 02:03:50 +0200 Subject: bug#187: 23.0.60; Font properties does not apply to international characters. Message-ID: <1w4j540p.fsf@telefonica.net> A non-text attachment was scrubbed... Name: fontbug2.png Type: image/png Size: 1184 bytes Desc: not available Url : http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080504/a8c3de91/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: fontbug.png Type: image/png Size: 177 bytes Desc: not available Url : http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080504/a8c3de91/attachment-0001.png -------------- next part -------------- In GNU Emacs 23.0.60.1 (i386-mingw-nt5.0.2195) of 2008-05-04 on K7 Windowing system distributor `Microsoft Corp.', version 5.0.2195 configured using `configure --with-gcc (4.2) --cflags -It:/emacscvs/include --ldflags -Lt:/emacscvs/lib' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: en value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ESN value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: show-paren-mode: t iswitchb-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-x b s s c r r s c r ? ? n ? C-d i i SPC e x i t

d e x i t

A c c e n t e d SPC c h a r a c t e d r r s C-g ? M-x

Recent messages: Loading em-dirs...done Loading em-glob...done Loading em-hist...done Loading em-ls...done Loading em-prompt...done Loading em-script...done Loading em-term...done Loading em-unix...done Quit goto-history-element: Beginning of history; no preceding item Quit -- Oscar From bzg at altern.org Sun May 4 06:04:11 2008 From: bzg at altern.org (Bastien Guerry) Date: Sun, 04 May 2008 15:04:11 +0200 Subject: bug#188: 23.0.60; Custom-save deleting custom file Message-ID: <877ieap6es.fsf@bzg.ath.cx> Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug at gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Saving a change with Custom-save deletes the old custom file (in my case ~/.emacs-custom.el). This is quite annoying if you don't have backups. In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2008-05-04 on bzg.ath.cx Windowing system distributor `The X.Org Foundation', version 11.0.10400090 configured using `configure '--enable-font-backend' '--with-x-toolkit=gtk'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: fr_FR.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-undo-mode: t display-time-mode: t delete-selection-mode: t pc-selection-mode: t shell-dirtrack-mode: t show-paren-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t Recent input: C-e C-a C-e C-a C-e C-a C-e C-a C-e C-z c C-n C-n C-n C-n C-n C-n C-n C-n j e m a . C-u 1 0 0 0 / s c u s t o m

M-x r e p o r b u g C u s t M-x c u s C-x C-x o C-x o C-x o C-g C-g q g M-x c u s a - t C-g M-x c u s - f a

C-h k C-x C-s C-x 1 C-x k g M-x r e p o r b u C u s t o m - s a v e SPC d e l e t e o o d e l e t i n g SPC o l d SPC

d e e l l e t i n g SPC o l d . SPC ~ / C-z c SPC c i u s t o m SPC C-x o C-z c C-x C-f C-x o C-x o s m d l f k s d m f l k s d m f l k s d f C-x o C-x o f i l e C-a C-e

C-e C-a C-e C-a C-e

C-a C-e C-e C-a C-e C-x o C-e C-x o C-g C-g g M-x Recent messages: nnml: Reading incoming mail (no new mail)...done nndiary: Reading incoming mail from file... nndiary: Reading incoming mail (no new mail)...done Killed inactive buffer: *Help*. Entering debugger... [3 times] Quit [2 times] nnml: Reading incoming mail from file... nnml: Reading incoming mail (no new mail)...done nndiary: Reading incoming mail from file... nndiary: Reading incoming mail (no new mail)...done -- Bastien From dann at ics.uci.edu Sun May 4 10:35:36 2008 From: dann at ics.uci.edu (Dan Nicolaescu) Date: Sun, 04 May 2008 10:35:36 -0700 Subject: bug#189: please make byte compiling during bootstrap take advantage of make -j Message-ID: <200805041735.m44HZbxS018196@sallyv1.ics.uci.edu> Multi-core CPUs are already widespread, and will only become more so. Byte compiling all the elisp files is where most of the time is spent during bootstrap. But currently byte compilation does not take advantage of "make -j", which would speed it up a great deal. Can you please implement this? Thanks From cyd at stupidchicken.com Sun May 4 11:45:52 2008 From: cyd at stupidchicken.com (Chong Yidong) Date: Sun, 04 May 2008 14:45:52 -0400 Subject: bug#168: Emacs-22.1 compilation-error-regexp Message-ID: <87iqxtkivz.fsf@stupidchicken.com> > The compilation-error-regexp works for gcc output but not for > Openwatcom. However, it worked fine for emacs-21. It seems the regexp no > longer accepts parentheses around the line number. > > ----- gcc example is ok ---- > -*- mode: compilation; default-directory: "c:/altm/acp-7-3/build/" -*- > ../src/vi/vi_main.c:53: `xint' undeclared (first use in this function) > ../src/vi/vi_main.c:53: (Each undeclared identifier is reported only once > > ------- Open Watcom Make Version 1.7 -- not ok because of line number ====== > ..\src\ctrl\lister.c(109): Error! E1009: Expecting ';' but found '{' > ..\src\ctrl\lister.c(120): Warning! W201: Unreachable code I don't have Openwatcom installed, so I can't test the fix directly. Could you help me with testing? Please add the following code to your .emacs, then try compiling. Does compilation now work for both gcc and openwatcom? If possible, please test with any other back-end to M-x compile that you have available, to ensure that nothing else broke. Thanks. (require 'compile) (push '(openwatcom "^\$[0-9]*[^0-9\n]\\(?:[^\n ]\\| [^-/\n]\$*?\\)(\$[0-9]+\$): ?\ \$?:\\(Warning! ?W[0-9]+:\$\\|\$Error! ?E[0-9]+:\$\\|\$.\$\\)" 1 2 nil (3 . 5)) compilation-error-regexp-alist-alist) (push 'openwatcom compilation-error-regexp-alist) From david.reitter at gmail.com Sun May 4 11:53:12 2008 From: david.reitter at gmail.com (David Reitter) Date: Sun, 4 May 2008 19:53:12 +0100 Subject: bug#166: not a corner case! Message-ID: <53E3A96E-258D-418D-A7BB-9EB081587AC5@gmail.com> this bug is not a corner case. my distribution hides the first frame until everything has been initialized (i.e. the user's .emacs has been read, etc.), in order to avoid ugly jumping frames. any chance somebody who knows what they're doing can fix it? or perhaps point out some possible causes for this...? From don at donarmstrong.com Sun May 4 15:00:04 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Sun, 4 May 2008 15:00:04 -0700 Subject: Processed: close 184 In-Reply-To: <87zlr53fk8.fsf@stupidchicken.com> References: <87zlr53fk8.fsf@stupidchicken.com> Message-ID: Processing commands for control at emacsbugs.donarmstrong.com: > close 184 bug#184: Resolved underline problem needs to be reflected in etc/PROBLEMS 'close' is deprecated; see http://emacsbugs.donarmstrong.com/Developer.html#closing. bug closed, send any further explanations to sand at blarg.net > thanks Stopping processing here. Please contact me if you need assistance. Don Armstrong (administrator, Emacs bugs database) From don at donarmstrong.com Sun May 4 15:30:03 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Sun, 4 May 2008 15:30:03 -0700 Subject: bug#164: marked as done (23.0.60; Broken eshell completion of directory names) References: <87y76p7luo.fsf@stupidchicken.com> <87fxt5z5fp.fsf@localhorst.mine.nu> Message-ID: Your message dated Sun, 04 May 2008 18:20:15 -0400 with message-id <87y76p7luo.fsf at stupidchicken.com> and subject line Re: 23.0.60; Broken eshell completion of directory names has caused the Emacs bug report #164, regarding 23.0.60; Broken eshell completion of directory names to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don at donarmstrong.com immediately.) -- 164: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=164 Emacs Bug Tracking System Contact don at donarmstrong.com with problems -------------- next part -------------- An embedded message was scrubbed... From: David Hansen Subject: 23.0.60; Broken eshell completion of directory names Date: Tue, 29 Apr 2008 05:49:14 +0200 Size: 9294 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080504/b30780a9/attachment.eml -------------- next part -------------- An embedded message was scrubbed... From: Chong Yidong Subject: Re: 23.0.60; Broken eshell completion of directory names Date: Sun, 04 May 2008 18:20:15 -0400 Size: 1229 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080504/b30780a9/attachment-0001.eml From md5i at cs.cmu.edu Sun May 4 16:55:47 2008 From: md5i at cs.cmu.edu (Michael Welsh Duggan) Date: Sun, 04 May 2008 19:55:47 -0400 Subject: bug#190: 23.0.60; vc inflooping Message-ID: <877ie9lj3w.fsf@maru.md5i.com> Please describe exactly what actions triggered the bug and the precise symptoms of the bug: emacs -Q C-x C-f /tmp/foo RET This is a test file C-x C-s C-x v i yes RET C-x v v Symptoms: find-auto-coding: Variable binding depth exceeds max-specpdl-size max-specpdl-size is a variable defined in `C source code'. Its value is 1040 M-: (setq max-specpdl-size 2000) C-x v v [in buffer foo] Same error M-: (setq max-specpdl-size 10000) C-x v v [in buffer foo] find-auto-coding: Lisp nesting exceeds `max-lisp-eval-depth' max-lisp-eval-depth is a variable defined in `C source code'. Its value is 400 M-: (setq max-lisp-eval-depth 10000) Emacs takes a long, long time. C-g M-x toggle-debug-on-quit C-x v v [wait a couple seconds] C-g Bottom of *Bactrace* buffer: vc-rcs-checkout-model(("/tmp/foo")) vc-rcs-fetch-master-state("/tmp/foo") vc-rcs-checkout-model(("/tmp/foo")) vc-rcs-fetch-master-state("/tmp/foo") vc-rcs-checkout-model(("/tmp/foo")) vc-rcs-fetch-master-state("/tmp/foo") vc-rcs-checkout-model(("/tmp/foo")) apply(vc-rcs-checkout-model ("/tmp/foo")) vc-call-backend(RCS checkout-model ("/tmp/foo")) vc-checkout-model(RCS ("/tmp/foo")) vc-next-action(nil) call-interactively(vc-next-action nil nil) So, there's an infloop happening. In GNU Emacs 23.0.60.6 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2008-05-04 on maru Windowing system distributor `The X.Org Foundation', version 11.0.10400090 configured using `configure '--without-toolkit-scroll-bars' '--with-dbus' '--enable-font-backend'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.utf8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: display-time-mode: t shell-dirtrack-mode: t senator-minor-mode: t semantic-idle-summary-mode: t semantic-idle-scheduler-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t Recent input: C-p C-p C-p C-p C-p > C-p C-p C-p C-p C-p C-p C-f C-f M-x d e b u g - o n q M-x C-g C-g C-x C-g q M-x t o g g l e - d e q C-x v v d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d c c c c c d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d c c c c c d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d c c d d d d d d d d d d d d d d d d d d q M-x C-g C-g M-x r e p o r t - e m Recent messages: Entering debugger... Proceeding, will debug on next eval or call. Entering debugger... Proceeding, will debug on next eval or call. Entering debugger... Proceeding, will debug on next eval or call. Entering debugger... Proceeding, will debug on next eval or call. Entering debugger... Back to top level. Don't touch it! It's the History Eraser Button, you fool! [2 times] -- Michael Welsh Duggan (md5i at cs.cmu.edu) From monnier at iro.umontreal.ca Sun May 4 23:41:22 2008 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon, 05 May 2008 02:41:22 -0400 Subject: bug#186: can't debug `message' Message-ID: tag 186 +wontfix Yes, there are many ways to shoot yourself in the foot in Emacs. Not sure what we can do about it, Stefan From don at donarmstrong.com Sun May 4 23:45:04 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Sun, 4 May 2008 23:45:04 -0700 Subject: bug#190: marked as done (23.0.60; vc inflooping) References: <877ie9lj3w.fsf@maru.md5i.com> Message-ID: Your message dated Mon, 05 May 2008 02:38:22 -0400 with message-id and subject line vc inflooping has caused the Emacs bug report #190, regarding 23.0.60; vc inflooping to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don at donarmstrong.com immediately.) -- 190: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=190 Emacs Bug Tracking System Contact don at donarmstrong.com with problems -------------- next part -------------- An embedded message was scrubbed... From: Michael Welsh Duggan Subject: 23.0.60; vc inflooping Date: Sun, 04 May 2008 19:55:47 -0400 Size: 7885 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080504/86fb37e6/attachment.eml -------------- next part -------------- An embedded message was scrubbed... From: Stefan Monnier Subject: vc inflooping Date: Mon, 05 May 2008 02:38:22 -0400 Size: 1535 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080504/86fb37e6/attachment-0001.eml From don at donarmstrong.com Mon May 5 00:10:08 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Mon, 5 May 2008 00:10:08 -0700 Subject: bug#170: marked as done (23.0.60; `crm-select-current-element' is not defined in crm.el) References: <878wyv9s6h.fsf@patagonia.sebmags.homelinux.org> Message-ID: Your message dated Mon, 05 May 2008 03:05:18 -0400 with message-id and subject line `crm-select-current-element' is not defined in crm.el has caused the Emacs bug report #170, regarding 23.0.60; `crm-select-current-element' is not defined in crm.el to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don at donarmstrong.com immediately.) -- 170: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=170 Emacs Bug Tracking System Contact don at donarmstrong.com with problems -------------- next part -------------- An embedded message was scrubbed... From: Sebastian Luque Subject: 23.0.60; `crm-select-current-element' is not defined in crm.el Date: Wed, 30 Apr 2008 12:19:18 -0500 Size: 9120 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080505/ddeda917/attachment-0002.eml -------------- next part -------------- An embedded message was scrubbed... From: Stefan Monnier Subject: `crm-select-current-element' is not defined in crm.el Date: Mon, 05 May 2008 03:05:18 -0400 Size: 1575 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080505/ddeda917/attachment-0003.eml From monnier at iro.umontreal.ca Mon May 5 00:00:00 2008 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon, 05 May 2008 03:00:00 -0400 Subject: bug#179: Menu separators are not displayed Message-ID: Does the patch below fix it? Stefan --- subr.el.~1.594.~ 2008-05-02 12:47:05.000000000 -0400 +++ subr.el 2008-05-05 02:58:00.000000000 -0400 @@ -571,10 +571,14 @@ (let* ((key (car binding)) (item (cdr binding)) (oldbind (assq key bindings))) + (if (null key) + ;; nil keys are/were used by easy-menu for "separator lines and + ;; separator titles". Merging them makes no sense. + (push binding bindings) ;; Newer bindings override older. (if oldbind (setq bindings (delq oldbind bindings))) (when item ;nil bindings just hide older ones. - (push binding bindings)))) + (push binding bindings))))) (nconc map bindings))) (put 'keyboard-translate-table 'char-table-extra-slots 0) From monnier at iro.umontreal.ca Sun May 4 23:48:02 2008 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon, 05 May 2008 02:48:02 -0400 Subject: bug#181: Case insensitive file name completion Message-ID: severity 181 wishlist thanks IIUC you'd like completion to be both case-sensitive (if that matches something) and case-insensitive (if there's no case-sensitive match). Stefan From don at donarmstrong.com Mon May 5 00:20:03 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Mon, 5 May 2008 00:20:03 -0700 Subject: bug#78: marked as done (23.0.60; python-mode indents try...except...finally incorrectly) References: <60c603510803231433r1f694dd7w8731b841ab6e9c4a@mail.gmail.com> Message-ID: Your message dated Mon, 05 May 2008 03:11:03 -0400 with message-id and subject line python-mode indents try...except...finally incorrectly has caused the Emacs bug report #78, regarding 23.0.60; python-mode indents try...except...finally incorrectly to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don at donarmstrong.com immediately.) -- 78: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=78 Emacs Bug Tracking System Contact don at donarmstrong.com with problems -------------- next part -------------- An embedded message was scrubbed... From: "Phil Sung" Subject: 23.0.60; python-mode indents try...except...finally incorrectly Date: Sun, 23 Mar 2008 17:33:25 -0400 Size: 8237 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080505/0cd6259b/attachment.eml -------------- next part -------------- An embedded message was scrubbed... From: Stefan Monnier Subject: python-mode indents try...except...finally incorrectly Date: Mon, 05 May 2008 03:11:03 -0400 Size: 1593 Url: http://lists.donarmstrong.com/pipermail/emacsbugs/attachments/20080505/0cd6259b/attachment-0001.eml From tim.vanholder at gmail.com Mon May 5 04:13:20 2008 From: tim.vanholder at gmail.com (Tim Van Holder) Date: Mon, 05 May 2008 13:13:20 +0200 Subject: bug#191: 23.0.60; vc (CVS backend): vc-directory is broken Message-ID: <87wsm9rokv.fsf@leeloo.anubex.internal> In a CVS HEAD build, C-x v d yields error in process sentinel: Wrong type argument: listp, ".gdbinit" A backtrace shows (with some dir & file names changed, so buffer positions might show discrepancies): Debugger entered--Lisp error: (wrong-type-argument listp ".gdbinit") vc-default-status-printer(CVS ".gdbinit") apply(vc-default-status-printer CVS ".gdbinit") vc-call-backend(CVS status-printer ".gdbinit") vc-generic-status-printer((".gdbinit" edited nil nil nil nil)) #[(G52601 data) "" [G52601 data "\n"] 2](--ewoc--user-pp-- (".gdbinit" edited nil nil nil nil)) apply(#[(G52601 data) "" [G52601 data "\n"] 2] --ewoc--user-pp-- (".gdbinit" edited nil nil nil nil)) (lambda (&rest --cl-rest--) (apply #[... "" [G52601 data "\n"] 2] (quote --ewoc--user-pp--) --cl-rest--))((".gdbinit" edited nil nil nil nil)) ewoc--refresh-node((lambda (&rest --cl-rest--) (apply #[... "" [G52601 data "\n"] 2] (quote --ewoc--user-pp--) --cl-rest--)) [[[[#0 #2 "" #] #1 DL-LIST #] #0 #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] [#0 [#1 [#2 #0 #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] DL-LIST #] "" #] (".gdbinit" edited nil nil nil nil) #] [[[[#0 #2 #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] #1 ... #] #0 "" #] [#0 [#1 [#2 #0 "" #] ... #] #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] DL-LIST #]) ewoc-invalidate([cl-struct-ewoc # (lambda (&rest --cl-rest--) (apply #[... "" [G52601 data "\n"] 2] ... --cl-rest--)) [[[[#1 #3 ... #] #2 "" #] #1 DL-LIST #] [#1 [#2 [#3 #1 DL-LIST #] "" #] ... #] #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] [[[[#1 #3 DL-LIST #] #2 #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] #1 ... #] [#1 [#2 [#3 #1 ... #] #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] DL-LIST #] "" #] [[[[#1 #3 #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] #2 ... #] #1 "" #] [#1 [#2 [#3 #1 "" #] ... #] #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] DL-LIST #] nil (lambda (&rest --cl-rest--) (apply #[... "" [G52601 data "\n"] 2] ... --cl-rest--))] [[[[#0 #2 "" #] #1 DL-LIST #] #0 #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] [#0 [#1 [#2 #0 #("VC backend : CVS\nWorking dir: /blah\nModule : ADD CODE TO PRINT THE MODULE\nRepository : ADD CODE TO PRINT THE REPOSITORY\nBranch : ADD CODE TO PRINT THE BRANCH NAME\n\n" 0 13 ... 13 17 ... 17 30 ... 30 48 ... 48 61 ... 61 90 ... 90 103 ... 103 136 ... 136 149 ... 149 183 ...) #] DL-LIST #] "" #] (".gdbinit" edited nil nil nil nil) #]) vc-dir-update(((".gdbinit" edited) ("foo1" unregistered) ("foo2" unregistered) ("foo3" unregistered) ("foo4" unregistered)) #) #[(G52602 entries &optional more-to-come) "" [G52602 entries more-to-come vc-ewoc remaining mode-line-process vc-dir-update ewoc-collect vc-dir-fileinfo->needs-update vc-dir-refresh-files mapcar vc-dir-fileinfo->name up-to-date nil] 5](--buffer-- ((".gdbinit" edited) ("foo1" unregistered) ("foo2" unregistered) ("foo3" unregistered) ("foo4" unregistered))) apply(#[(G52602 entries &optional more-to-come) "" [G52602 entries more-to-come vc-ewoc remaining mode-line-process vc-dir-update ewoc-collect vc-dir-fileinfo->needs-update vc-dir-refresh-files mapcar vc-dir-fileinfo->name up-to-date nil] 5] --buffer-- ((".gdbinit" edited) ("foo1" unregistered) ("foo2" unregistered) ("foo3" unregistered) ("foo4" unregistered))) (lambda (&rest --cl-rest--) (apply #[... "" [G52602 entries more-to-come vc-ewoc remaining mode-line-process vc-dir-update ewoc-collect vc-dir-fileinfo->needs-update vc-dir-refresh-files mapcar vc-dir-fileinfo->name up-to-date nil] 5] (quote --buffer--) --cl-rest--))(((".gdbinit" edited) ("foo1" unregistered) ("foo2" unregistered) ("foo3" unregistered) ("foo4" unregistered))) vc-cvs-after-dir-status((lambda (&rest --cl-rest--) (apply #[... "" [G52602 entries more-to-come vc-ewoc remaining mode-line-process vc-dir-update ewoc-collect vc-dir-fileinfo->needs-update vc-dir-refresh-files mapcar vc-dir-fileinfo->name up-to-date nil] 5] (quote --buffer--) --cl-rest--))) eval((vc-cvs-after-dir-status (quote (lambda ... ...)))) vc-exec-after((vc-cvs-after-dir-status (quote (lambda ... ...)))) vc-process-sentinel(# "finished\n") From don at donarmstrong.com Mon May 5 12:25:04 2008 From: don at donarmstrong.com (Emacs bug Tracking System) Date: Mon, 5 May 2008 12:25:04 -0700 Subject: bug#185: marked as done (23.0.60; incremental search in Info is broken) References: <87od7kd0sk.fsf@stupidchicken.com> <002401c8ad63$5eb273a0$0200a8c0@us.oracle.com> Message-ID: