From unknown Fri Aug 15 14:18:20 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#2435 <2435@debbugs.gnu.org> To: bug#2435 <2435@debbugs.gnu.org> Subject: Status: 23.0.90; customize/whitespace: display stops updating Reply-To: bug#2435 <2435@debbugs.gnu.org> Date: Fri, 15 Aug 2025 21:18:20 +0000 retitle 2435 23.0.90; customize/whitespace: display stops updating reassign 2435 emacs submitter 2435 Jindrich Makovicka severity 2435 normal thanks From makovick@gmail.com Sun Feb 22 08:44:17 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 22 Feb 2009 16:44:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1MGiDMx030414 for ; Sun, 22 Feb 2009 08:44:14 -0800 Received: from mail.gnu.org ([199.232.76.166]:54604 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LbHOy-0006AD-JV for emacs-pretest-bug@gnu.org; Sun, 22 Feb 2009 11:42:00 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LbHR5-0003HI-LS for emacs-pretest-bug@gnu.org; Sun, 22 Feb 2009 11:44:12 -0500 Received: from nat1.suchdol.net ([82.208.33.250]:3762) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbHR5-0003Gd-5f for emacs-pretest-bug@gnu.org; Sun, 22 Feb 2009 11:44:11 -0500 Received: from holly (unknown [10.19.252.3]) by nat1.suchdol.net (Postfix) with ESMTP id 1FB10B65; Sun, 22 Feb 2009 17:44:08 +0100 (CET) Received: from henry by holly with local (Exim 4.69) (envelope-from ) id 1LbHR1-00067W-RW; Sun, 22 Feb 2009 17:44:07 +0100 To: emacs-pretest-bug@gnu.org CC: rfrancoise@debian.org CC: makovick@gmail.com Subject: 23.0.90; customize/whitespace: display stops updating Message-Id: From: Jindrich Makovicka Date: Sun, 22 Feb 2009 17:44:07 +0100 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. When scrolling down the Whitespace group in Customize, the display stops updating, probably when reaching the Hspace Regexp entry containing exotic characters with different character height. However, Emacs is not frozen and just switching to another buffer and back to customize is enough to work the issue around. After the switch, Customize works normally, including the Hspace Regexp entry. Steps to reproduce here: M-x customize-group whitespace press Page Down Customize window now stops updating until I switch to another buffer and back In GNU Emacs 23.0.90.1 (x86_64-pc-linux-gnu, GTK+ Version 2.12.12) of 2009-02-22 on elegiac, modified by Debian (emacs-snapshot package, version 1:20090222-1) Windowing system distributor `The X.Org Foundation', version 11.0.10402000 configured using `configure '--build' 'x86_64-linux-gnu' '--host' 'x86_64-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.90/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.90/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS='' 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: Help Minor modes in effect: show-paren-mode: t server-mode: t global-whitespace-newline-mode: t global-whitespace-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 size-indication-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t view-mode: t Recent input: 0 8 9 0 7 8 9 h f h d f g h d f g h C-c C-c M-x m a i l F r o m : SPC m a k o v i c k @ g m a i l . c o m m a k o v i c k @ g m a i l . c o m s d f a s d f a a s d f a s d f C-c C-c C-h C-g M-x c u s t - g m m a i l M-x s e m a ` 1 e n d m m a i l C-x k l l M-x m a k o v i c k @ g m a i l . c o m v x z v z x c v z x c v z x c C-c C-c M-x b u g Recent messages: To install your edits, invoke [State] and choose the Set operation Mark set byte-code: Beginning of buffer [2 times] Custom-no-edit: You can't edit this part of the Custom buffer [2 times] To install your edits, invoke [State] and choose the Set operation Saving file /home/henry/.emacs... Wrote /home/henry/.emacs Mark set Sending...done call-interactively: Text is read-only From lekktu@gmail.com Mon Feb 23 03:52:56 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 23 Feb 2009 11:52:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1NBqqoG027853 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 03:52:54 -0800 Received: by ug-out-1314.google.com with SMTP id u2so248898uge.14 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 03:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QuQ/7ygqO8aEsTMFasy1uiGPNyZ2Q4Ndw55iFFPIpKU=; b=bFOidF0KM5sManshJRjRXNI0imue74AqNHdPFTjr1HH7+a6nsOsbPfdcHLIu6cgo3/ 2ImxHHof3aljTn4rTgYrRLF27TQNHSA98gst7rLkZx2dBU/3Rzo8JiWbdgb0anNk20xb WUMULj8NMB0jMd7rJSpoOLHXWeTaYrp4hFVuk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GvNXLSoOMbm4y6iujCkAqusGg1PHBauxWTMTPEaerUYyerdwSePKlZ6AsHsrLo32QE DC1ttFDr7G6s0uPVwW0nASeybZBnQAgaWGq3PkrntGLRL35zpMVk4f4Tem8rJGGWbHWN hush8pPEhW76LaxIM5ikYGToQ7TAu5DrUO/bE= MIME-Version: 1.0 Received: by 10.210.105.20 with SMTP id d20mr3396034ebc.84.1235389971904; Mon, 23 Feb 2009 03:52:51 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Feb 2009 12:52:51 +0100 Message-ID: Subject: Re: bug#2435: 23.0.90; customize/whitespace: display stops updating From: Juanma Barranquero To: Jindrich Makovicka Cc: 2435@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Sun, Feb 22, 2009 at 17:44, Jindrich Makovicka wrote: > However, > Emacs is not frozen and just switching to another buffer and back to > customize is enough to work the issue around. If, instead of switching to another buffer and back, you just wait for a few seconds, it does not work? Do you see the same effect when displaying the HELLO file? (C-h h) Juanma From makovick@gmail.com Mon Feb 23 04:04:52 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 23 Feb 2009 12:04:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-fx0-f161.google.com (mail-fx0-f161.google.com [209.85.220.161]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1NC4nbe030299 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 04:04:50 -0800 Received: by fxm5 with SMTP id 5so1837752fxm.1 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 04:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+8C4227jtD60Sj2UiRA1TXbD8VVPrP/MWhOQRJfZkFA=; b=mk4gNEzz5B0ACruQhUdx64PBONNAHyzsFqAZcrLvFdUQoMC3O3ntVuPL0tBI8BaI7I vddLuUZzKsa8K3NT7QGl7zZhyjGsepu1ztMJ+kjO4I2whpD6/NJBjl6lcSQN8+bQaa3t E7vHrKb9+iJ/Tj0tMfJXNX9Il6OQpbtqdqGSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lvWFQC8UQPK/TGHBUyW5Jks+uoiVG0zRdDuDGI1HGluwZpllI2vztXaakvwksfRC6+ BXiy0lrsydVWco3HKimbFQ9VlzmRaoWKrcEY0hT+Fd44lDixK+MBVcV2OSZEPbLuLIW4 RguWfoI1OPb2j8P3taqTxwPIH3hsrL8Lz+euQ= MIME-Version: 1.0 Received: by 10.180.252.8 with SMTP id z8mr1496666bkh.158.1235390683238; Mon, 23 Feb 2009 04:04:43 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Feb 2009 13:04:43 +0100 Message-ID: <5f0e26840902230404t4e747387je2a32bb97ade3b0@mail.gmail.com> Subject: Re: bug#2435: 23.0.90; customize/whitespace: display stops updating From: =?ISO-8859-2?Q?Jind=F8ich_Makovi=E8ka?= To: Juanma Barranquero Cc: 2435@debbugs.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Feb 23, 2009 at 12:52, Juanma Barranquero wrote: > On Sun, Feb 22, 2009 at 17:44, Jindrich Makovicka wrote: > >> However, >> Emacs is not frozen and just switching to another buffer and back to >> customize is enough to work the issue around. > > If, instead of switching to another buffer and back, you just wait for > a few seconds, it does not work? No, the buffer, modeline and scrollbar just stop updating. Otherwise, Emacs seems to behave normally - the point moves, minibuffer reports beginning/end of buffer etc. It just doesn't get displayed. > Do you see the same effect when displaying the HELLO file? (C-h h) No, HELLO is ok. -- Jindrich Makovicka From lekktu@gmail.com Mon Feb 23 04:40:51 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 23 Feb 2009 12:40:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.0 required=4.0 tests=GMAIL,HAS_BUG_NUMBER, IMPRONONCABLE_2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1NCelTD008268 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 04:40:49 -0800 Received: by nf-out-0910.google.com with SMTP id g16so347941nfd.31 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 04:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OgOlQLwMNJzf0XM5Fb9PSN+5IVXPIQEWzm6QdjxgCTE=; b=rRoBe6iUxkYpZzYol/lr5ea4hOyaSEksqvWOgw4ExcJ5T8cYuZ1V3J6UcTauhY1Gp2 4hYpn9hVA4vur9JdlfEj+Nw1kgPCFBo3AC2ba5fcQBFV0eJjcqoXkSwd5Mq/KumP9jUj OsCyTV39dzL8h6fRUZ3/fverlMiYClY6z7S4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q3G//3XLrox3o3ZqxaaFSFjTgnB8dEqprfRMnX41/mcfXtxaHOIPCtpuLwZdZpS3lY inzuFrXzPl7NaswpxqsdjWjx2P2c7WuCbHXe7JG3vuUE5DAnm9uEK+FNyOPXEMGcI25o YF303LhR+KJeQBQlw5NiFoVICbe467EpIgI0k= MIME-Version: 1.0 Received: by 10.210.137.17 with SMTP id k17mr3418099ebd.138.1235392847250; Mon, 23 Feb 2009 04:40:47 -0800 (PST) In-Reply-To: <5f0e26840902230404t4e747387je2a32bb97ade3b0@mail.gmail.com> References: <5f0e26840902230404t4e747387je2a32bb97ade3b0@mail.gmail.com> Date: Mon, 23 Feb 2009 13:40:47 +0100 Message-ID: Subject: Re: bug#2435: 23.0.90; customize/whitespace: display stops updating From: Juanma Barranquero To: =?UTF-8?B?SmluZMWZaWNoIE1ha292acSNa2E=?= Cc: 2435@debbugs.gnu.org, Vinicius Jose Latorre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2009 at 13:04, Jind=C5=99ich Makovi=C4=8Dka wrote: > No, the buffer, modeline and scrollbar just stop updating. Weird. On Windows I see a delay while the font backend looks for suitable fonts, and then Emacs resumes normal behavior. Seems like a bug in the font backend (font detection has generated quite a few bug reports since the Unicode switch, though it works much much better now). You can try to generate a font log (see variable `font-log' and command `font-show-log') to see whether it sheds any light. Vinicius, what is character #x8a0 in `whitespace-hspace-regexp'? Juanma From makovick@gmail.com Mon Feb 23 04:53:07 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 23 Feb 2009 12:53:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=GMAIL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-fx0-f161.google.com (mail-fx0-f161.google.com [209.85.220.161]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1NCr1HN010815 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 04:53:03 -0800 Received: by fxm5 with SMTP id 5so1884900fxm.1 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 04:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iosCteKKRiv9nKKTaybXaCtbmslf8dgFAU8LoSOjrTU=; b=LA47qvxvgyxVii8i77HcGc4ANqfHBPSWXwcEebPDx8VsqlqOIFUDXi5XouK6YLdlVZ NmQZvPvuoaVa+8lT4kbI8YM/6zUSVnIEWd1DO1Q4c3VmtBjJPExEBnteeTxgZNnk0E80 5cyD0WcapQ4JO0FQZxEKS2zGkA93XBJnY9Lz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DfqG3ZWpjk1sKwjnPOV3jIgRgD0OXdp5JkbPaGK7XQ3iDjWmFaWFYGGBAqZ7qP+uGL FZv8N8tn6FLs3SV2G2YM4DyalpZNfFcLQxkGjMdmXEZLjRVyMEb8FqrYdyRQntCZH7n8 ej8RS1l07sR6wgv7hwdNmHDtOOJMlE8Twz+5I= MIME-Version: 1.0 Received: by 10.180.223.8 with SMTP id v8mr1508110bkg.181.1235393576001; Mon, 23 Feb 2009 04:52:56 -0800 (PST) In-Reply-To: References: <5f0e26840902230404t4e747387je2a32bb97ade3b0@mail.gmail.com> Date: Mon, 23 Feb 2009 13:52:55 +0100 Message-ID: <5f0e26840902230452o54520809ua19962ee6aa27dda@mail.gmail.com> Subject: Re: bug#2435: 23.0.90; customize/whitespace: display stops updating From: =?ISO-8859-2?Q?Jind=F8ich_Makovi=E8ka?= To: Juanma Barranquero Cc: 2435@debbugs.gnu.org, Vinicius Jose Latorre Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2009 at 13:40, Juanma Barranquero wrote: > On Mon, Feb 23, 2009 at 13:04, Jind=F8ich Makovi=E8ka wrote: > >> No, the buffer, modeline and scrollbar just stop updating. > > Weird. On Windows I see a delay while the font backend looks for > suitable fonts, and then Emacs resumes normal behavior. Seems like a > bug in the font backend (font detection has generated quite a few bug > reports since the Unicode switch, though it works much much better > now). > > You can try to generate a font log (see variable `font-log' and > command `font-show-log') to see whether it sheds any light. Here it goes (after the display freeze): ftfont-list: -*-Monospace-*-iso8859-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 xfont-list: -*-Monospace-*-*-*-*-*-*-*-*-*-*-iso8859-1 xfont-list: monospace-12 list: -*-Monospace-*-iso8859-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 sort-by: -*-Monospace-normal-normal-normal-*-15-*-iso8859-1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 open: -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-m-0-iso10646-1 ftfont-list: -unknown-DejaVu Sans Mono-*-iso8859-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 xfont-list: -unknown-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-iso8859-1 xfont-list: monospace-12 list: -unknown-DejaVu Sans Mono-*-iso8859-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-iso8859-1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 open: -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-iso8859-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-normal-italic-normal-*-15-*-iso8859-1 xft:-unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 open: -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-normal-oblique-normal-*-15-*-m-0-iso10646-1 ftfont-list: -unknown-DejaVu Sans Mono-*-m-*-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 xfont-list: -unknown-DejaVu Sans Mono-*-*-*-*-*-*-*-*-m-*-iso10646-1 xfont-list: monospace-12 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-light-normal-normal-*-15-*-m-0-iso10646-= 1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 open: -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-light-normal-normal-*-15-*-m-0-iso10646-= 1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-bold-normal-normal-*-15-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 open: -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-bold-normal-normal-*-15-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-light-normal-normal-*-15-*-m-0-iso10646-= 1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-bold-normal-normal-*-15-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-light-normal-normal-*-15-*-m-0-iso10646-= 1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-bold-normal-normal-*-15-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 ftfont-list: -unknown-Sans Serif-*-iso8859-1 -unknown-DejaVu Sans-bold-oblique-semi-condensed-*-0-iso10646-1 -unknown-DejaVu Sans-bold-normal-normal-*-0-iso10646-1 -unknown-DejaVu Sans-bold-oblique-normal-*-0-iso10646-1 -unknown-DejaVu Sans-extra-light-normal-normal-*-0-iso10646-1 -unknown-DejaVu Sans-normal-normal-normal-*-0-iso10646-1 -unknown-DejaVu Sans-bold-normal-semi-condensed-*-0-iso10646-1 -unknown-DejaVu Sans-normal-oblique-semi-condensed-*-0-iso10646-1 -unknown-DejaVu Sans-normal-oblique-normal-*-0-iso10646-1 -unknown-DejaVu Sans-normal-normal-semi-condensed-*-0-iso10646-1 xfont-list: -unknown-Sans Serif-*-*-*-*-*-*-*-*-*-*-iso8859-1 xfont-list: monospace-12 list: -unknown-Sans Serif-*-normal-*-iso8859-1 -unknown-DejaVu Sans-normal-normal-semi-condensed-*-0-iso10646-1 -unknown-DejaVu Sans-bold-normal-semi-condensed-*-0-iso10646-1 -unknown-DejaVu Sans-normal-normal-normal-*-0-iso10646-1 -unknown-DejaVu Sans-extra-light-normal-normal-*-0-iso10646-1 -unknown-DejaVu Sans-bold-normal-normal-*-0-iso10646-1 sort-by: -unknown-Sans Serif-bold-normal-normal-*-18-*-iso8859-1 xft:-unknown-DejaVu Sans-bold-normal-normal-*-0-iso10646-1 open: -unknown-DejaVu Sans-bold-normal-normal-*-0-iso10646-1 xft:-unknown-DejaVu Sans-bold-normal-normal-*-18-*-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-bold-normal-normal-*-15-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-m-0-iso10646= -1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-bold-normal-normal-*-15-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 font for: (2208) ftfont-list: -unknown-DejaVu Sans Mono-*-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 xfont-list: -unknown-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-iso10646-1 xfont-list: monospace-12 list: -unknown-DejaVu Sans Mono-*-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-m-0-iso10646= -1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 open: -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-m-0-iso10646-1 ftfont-list: -unknown-DejaVu Sans Mono-*-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 xfont-list: -unknown-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-iso10646-1 list: -unknown-DejaVu Sans Mono-*-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-m-0-iso10646= -1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 open: -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-m-0-iso10646-1 ftfont-list: -mutt-clearlyu-*-iso10646-1 xfont-list: -mutt-clearlyu-*-*-*-*-*-*-*-*-*-*-iso10646-1 -mutt-clearlyu-medium-r-normal--17-*-100-100-p-123-iso10646-1 list: -mutt-clearlyu-*-iso10646-1 -mutt-clearlyu-medium-r-normal--17-*-100-100-p-123-iso10646-1 open: -mutt-clearlyu-medium-r-normal--17-*-100-100-p-123-iso10646-1 x:-mutt-clearlyu-medium-r-normal--17-120-100-100-p-123-iso10646-1 ftfont-list: -gnu-unifont-*-iso10646-1 xfont-list: -gnu-unifont-*-*-*-*-*-*-*-*-*-*-iso10646-1 -gnu-unifont-medium-r-normal--16-*-75-75-c-80-iso10646-1 list: -gnu-unifont-*-iso10646-1 -gnu-unifont-medium-r-normal--16-*-75-75-c-80-iso10646-1 open: -gnu-unifont-medium-r-normal--16-*-75-75-c-80-iso10646-1 x:-gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1 font for: (2336) ftfont-list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Ddeva list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Ddeva ftfont-list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Ddeva list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Ddeva ftfont-list: -unknown-*-iso10646-1:otf=3Ddeva list: -unknown-*-iso10646-1:otf=3Ddeva ftfont-list: -*-iso10646-1:otf=3Ddeva list: -*-iso10646-1:otf=3Ddeva xfont-list: -unknown-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-iso10646.indian-1 list: -unknown-DejaVu Sans Mono-*-iso10646.indian-1 xfont-list: -*-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-iso10646.indian-1 list: -*-DejaVu Sans Mono-*-iso10646.indian-1 xfont-list: -unknown-*-*-*-*-*-*-*-*-*-*-*-iso10646.indian-1 list: -unknown-*-iso10646.indian-1 xfont-list: -*-*-*-*-*-*-*-*-*-*-*-*-iso10646.indian-1 list: -*-iso10646.indian-1 font for: (3616) ftfont-list: -unknown-TlwgMono-*-tis620.*-* xfont-list: -unknown-TlwgMono-*-*-*-*-*-*-*-*-*-*-tis620.*-* list: -unknown-TlwgMono-*-tis620.*-* ftfont-list: -*-TlwgMono-*-tis620.*-* xfont-list: -*-TlwgMono-*-*-*-*-*-*-*-*-*-*-tis620.*-* list: -*-TlwgMono-*-tis620.*-* ftfont-list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai ftfont-list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai ftfont-list: -unknown-*-iso10646-1:otf=3Dthai list: -unknown-*-iso10646-1:otf=3Dthai ftfont-list: -*-iso10646-1:otf=3Dthai list: -*-iso10646-1:otf=3Dthai ftfont-list: -unknown-DejaVu Sans Mono-*-tis620*-* xfont-list: -unknown-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-tis620*-* list: -unknown-DejaVu Sans Mono-*-tis620*-* ftfont-list: -*-DejaVu Sans Mono-*-tis620*-* xfont-list: -*-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-tis620*-* list: -*-DejaVu Sans Mono-*-tis620*-* ftfont-list: -unknown-*-tis620*-* -unknown-unifont-normal-normal-normal-*-d-0-iso10646-1 xfont-list: -unknown-*-*-*-*-*-*-*-*-*-*-*-tis620*-* list: -unknown-*-tis620*-* -unknown-unifont-normal-normal-normal-*-d-0-iso10646-1 open: -unknown-unifont-normal-normal-normal-*-d-0-iso10646-1 xft:-unknown-unifont-normal-normal-normal-*-15-*-d-0-iso10646-1 font for: (3616) list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -unknown-*-iso10646-1:otf=3Dthai list: -*-iso10646-1:otf=3Dthai font for: (3872) ftfont-list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dtibt list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dtibt ftfont-list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dtibt list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dtibt ftfont-list: -unknown-*-iso10646-1:otf=3Dtibt list: -unknown-*-iso10646-1:otf=3Dtibt ftfont-list: -*-iso10646-1:otf=3Dtibt list: -*-iso10646-1:otf=3Dtibt list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dtibt list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dtibt list: -unknown-*-iso10646-1:otf=3Dtibt list: -*-iso10646-1:otf=3Dtibt ftfont-list: -unknown-mtib-*-iso10646-1 xfont-list: -unknown-mtib-*-*-*-*-*-*-*-*-*-*-iso10646-1 list: -unknown-mtib-*-iso10646-1 ftfont-list: -*-mtib-*-iso10646-1 xfont-list: -*-mtib-*-*-*-*-*-*-*-*-*-*-iso10646-1 list: -*-mtib-*-iso10646-1 list: -unknown-mtib-*-iso10646-1 list: -*-mtib-*-iso10646-1 xfont-list: -unknown-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-muletibetan-2 xfont-list: -unknown-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-muletibetan-0 list: -unknown-DejaVu Sans Mono-*-muletibetan-2 xfont-list: -*-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-muletibetan-2 xfont-list: -*-DejaVu Sans Mono-*-*-*-*-*-*-*-*-*-*-muletibetan-0 list: -*-DejaVu Sans Mono-*-muletibetan-2 xfont-list: -unknown-*-*-*-*-*-*-*-*-*-*-*-muletibetan-2 xfont-list: -unknown-*-*-*-*-*-*-*-*-*-*-*-muletibetan-0 list: -unknown-*-muletibetan-2 xfont-list: -*-*-*-*-*-*-*-*-*-*-*-*-muletibetan-2 xfont-list: -*-*-*-*-*-*-*-*-*-*-*-*-muletibetan-0 list: -*-muletibetan-2 list: -unknown-DejaVu Sans Mono-*-muletibetan-2 list: -*-DejaVu Sans Mono-*-muletibetan-2 list: -unknown-*-muletibetan-2 list: -*-muletibetan-2 font for: (3616) list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -unknown-*-iso10646-1:otf=3Dthai list: -*-iso10646-1:otf=3Dthai font for: (3616) list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -unknown-*-iso10646-1:otf=3Dthai list: -*-iso10646-1:otf=3Dthai font for: (3616) list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -unknown-*-iso10646-1:otf=3Dthai list: -*-iso10646-1:otf=3Dthai font for: (3616) list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -unknown-*-iso10646-1:otf=3Dthai list: -*-iso10646-1:otf=3Dthai font for: (3616) list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -unknown-*-iso10646-1:otf=3Dthai list: -*-iso10646-1:otf=3Dthai font for: (3616) list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -unknown-*-iso10646-1:otf=3Dthai list: -*-iso10646-1:otf=3Dthai font for: (3616) list: -unknown-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -*-DejaVu Sans Mono-*-iso10646-1:otf=3Dthai list: -unknown-*-iso10646-1:otf=3Dthai list: -*-iso10646-1:otf=3Dthai font for: (3872) list: -unknown-DejaVu Sans Mono-*-iso8859-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-oblique-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-iso8859-1 xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-bold-normal-normal-*-15-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-*-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-bold-normal-normal-*-15-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-bold-normal-normal-*-m-0-iso10646-1 list: -unknown-DejaVu Sans Mono-normal-*-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-normal-normal-*-m-0-iso10646-1 -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 sort-by: -unknown-DejaVu Sans Mono-normal-italic-normal-*-15-*-m-0-iso10646= -1 xft:-unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 open: -unknown-DejaVu Sans Mono-normal-oblique-normal-*-m-0-iso10646-1 xft:-unknown-DejaVu Sans Mono-normal-oblique-normal-*-15-*-m-0-iso10646-1 --=20 Jindrich Makovicka From makovick@gmail.com Mon Feb 23 11:47:10 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 23 Feb 2009 19:47:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.0 required=4.0 tests=GMAIL,HAS_BUG_NUMBER, IMPRONONCABLE_2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mail-fx0-f161.google.com (mail-fx0-f161.google.com [209.85.220.161]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1NJl6xk019271 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 11:47:07 -0800 Received: by fxm5 with SMTP id 5so2360432fxm.1 for <2435@emacsbugs.donarmstrong.com>; Mon, 23 Feb 2009 11:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v8GFVnAH5OAFiQwSMpxE+cJYSJsX0ojxJrxnZcFbX5o=; b=IoId6eCEpdFHSGuKBdXvZIPfKDgr/SnT2vgNUN10pFhABOuP+zHoxZTMwO8zGgoSwj U19Gsy4g9s37WbhhmF9SzFqZmtRZSqkmdRHpeR6ruTAOmWXIJe6eEqEHyBLsYqadT3Q6 wHZZwIb5bdqJNwpKJu/mMvBAYu9FjkJCgZjPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YtpVs6V3ZBZQ5lUgTgldUsu6/TKQluZCYSzAWQb4/SxdzDps3rKFpPtonTDKOOJCOq AXvMn8IBhc+X1FfTXndokT8zieYsyl1nmGnFXi8HG/l3cfQV4BKao6U1iBcCAwwyNih1 e+AsPwo4eR9j5OmTbnO3N7tgQ8lsQKXr9iBL0= MIME-Version: 1.0 Received: by 10.181.240.10 with SMTP id s10mr1640412bkr.12.1235418420222; Mon, 23 Feb 2009 11:47:00 -0800 (PST) In-Reply-To: References: <5f0e26840902230404t4e747387je2a32bb97ade3b0@mail.gmail.com> Date: Mon, 23 Feb 2009 20:47:00 +0100 Message-ID: <5f0e26840902231147m4a93a935t3d97e37e840048c@mail.gmail.com> Subject: Re: bug#2435: 23.0.90; customize/whitespace: display stops updating From: =?ISO-8859-2?Q?Jind=F8ich_Makovi=E8ka?= To: Juanma Barranquero Cc: 2435@debbugs.gnu.org, Vinicius Jose Latorre Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2009 at 13:40, Juanma Barranquero wrote: > On Mon, Feb 23, 2009 at 13:04, Jind=F8ich Makovi=E8ka wrote: > >> No, the buffer, modeline and scrollbar just stop updating. > > Weird. On Windows I see a delay while the font backend looks for > suitable fonts, and then Emacs resumes normal behavior. Seems like a > bug in the font backend (font detection has generated quite a few bug > reports since the Unicode switch, though it works much much better > now). > > You can try to generate a font log (see variable `font-log' and > command `font-show-log') to see whether it sheds any light. > > Vinicius, what is character #x8a0 in `whitespace-hspace-regexp'? Update: The bug seems to be triggered by a particular Korean font (UnDotum), contained in a Debian package ttf-unfonts-core , and configured in ~/.emacs by (set-fontset-font (frame-parameter nil 'font) 'korean-ksc5601 '("UnDotum" . "ksc5601.*")) To be sure it's not just the Debian binary, I tried a plain CVS build and the bug is triggered as well. --=20 Jindrich Makovicka From cyd@stupidchicken.com Tue Feb 24 10:44:53 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 24 Feb 2009 18:44:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,IMPRONONCABLE_2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1OIipD5012833 for <2435@emacsbugs.donarmstrong.com>; Tue, 24 Feb 2009 10:44:52 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id ED34C57E1FC; Tue, 24 Feb 2009 13:45:50 -0500 (EST) From: Chong Yidong To: Kenichi Handa Cc: Jindrich Makovicka , 2435@debbugs.gnu.org Subject: Re: 23.0.90; customize/whitespace: display stops updating Date: Tue, 24 Feb 2009 13:45:50 -0500 Message-ID: <87ljrv8yht.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I get a crash with the following recipe, and I think it's related to the new composition code: emacs -Q M-x customize-group RET whitespace RET C-v C-v Breakpoint 1, abort () at emacs.c:432 432 kill (getpid (), SIGABRT); (gdb) bt #0 abort () at emacs.c:432 #1 0x081a9e6d in analyse_first (p=0x8b51b9e "\017", pend=0x8b51bc7 "", fastmap=0x0, multibyte=0) at regex.c:4295 #2 0x081a15f8 in regex_compile ( pattern=0x83560a9 "[\340\275...", size=88, syntax=3408388, bufp=0x83e3a98) at regex.c:2853 #3 0x081b3c06 in re_compile_pattern ( pattern=0x83560a9 "[\340\275...", length=88, bufp=0x83e3a98) at regex.c:6518 #4 0x08196574 in compile_pattern_1 (cp=0x83e3a88, pattern=137243907, translate=138358041, regp=0x0, posix=0) at search.c:160 #5 0x081967dd in compile_pattern (pattern=137243907, regp=0x0, translate=138358041, posix=0, multibyte=1) at search.c:259 #6 0x08197547 in fast_looking_at (regexp=137243907, pos=3726, pos_byte=3732, limit=3742, limit_byte=3750, string=138358041) at search.c:618 #7 0x0824131f in autocmp_chars (cft_element=141223421, charpos=3726, bytepos=3733, limit=3742, win=0x879c4b8, face=0x8ac0e78, string=138358041) at composite.c:957 #8 0x08241fc2 in composition_reseat_it (cmp_it=0xbfb4e364, charpos=3726, bytepos=3733, endpos=5814, w=0x879c4b8, face=0x8ac0e78, string=138358041) at composite.c:1142 #9 0x08079776 in next_element_from_buffer (it=0xbfb4dfac) at xdisp.c:6514 #10 0x08077458 in get_next_display_element (it=0xbfb4dfac) at xdisp.c:5676 #11 0x0808f146 in display_line (it=0xbfb4dfac) at xdisp.c:16605 The abort does not occur if I remove these lines in next_element_from_buffer (xdisp.c:6514), which were added during the 2008-08-29 composition changes: if (CHAR_COMPOSED_P (it, IT_CHARPOS (*it), IT_BYTEPOS (*it)) && next_element_from_composition (it)) { return 1; } From cyd@stupidchicken.com Tue Mar 3 08:39:23 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 3 Mar 2009 16:39:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,IMPRONONCABLE_2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n23GdJcC009709 for <2435@emacsbugs.donarmstrong.com>; Tue, 3 Mar 2009 08:39:21 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id 85E0957E20B; Tue, 3 Mar 2009 11:40:26 -0500 (EST) From: Chong Yidong To: Kenichi Handa Cc: 2435@debbugs.gnu.org Subject: Re: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> Date: Tue, 03 Mar 2009 11:40:26 -0500 In-Reply-To: (Kenichi Handa's message of "Tue, 03 Mar 2009 16:51:44 +0900") Message-ID: <87zlg2a7b9.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Kenichi Handa writes: >> I get a crash with the following recipe, and I think it's related to the >> new composition code: >> >> emacs -Q >> M-x customize-group RET whitespace RET >> C-v C-v > > I can't reproduce the crash with that. It doesn't happen all the time---about once every three or four attempts. Quite strange. > It seems that the regular expression > tibetan-composable-pattern (which starts with "[\340\275..." > and the byte length is surely 88) is being compiled. > Parhaps the display routine is going to display #xF20 > (tibetan character). But, in my case, regex_compile never > calls analyse_first at line 2853. > > 2846 if (many_times_ok) > 2847 { > 2848 boolean simple = skip_one_char (laststart) == b; > 2849 unsigned int startoffset = 0; > 2850 re_opcode_t ofj = > 2851 /* Check if the loop can match the empty string. */ > 2852 (simple || !analyse_first (laststart, b, NULL, 0)) > 2853 ? on_failure_jump : on_failure_jump_loop; > > Here, "simple" is always set to 1, so analyse_first is not > called. When I get the crash, simple is set to 0. (gdb) p b $4 = (unsigned char *) 0x8b927b7 "" (gdb) p laststart $5 = (unsigned char *) 0x8b92786 "\a\201\f" The return value of `skip_one_char (laststart)' is NULL. > Could you please try: > ESC : (re-search-forward tibetan-composable-pattern) RET > in some buffer and checks if analyse_first is called? It's called, not for the search itself but in the error handler: #0 analyse_first ( p=0x8860bc0 "\t\002\037Previous command was not a yank\n\001\005eval-\0164", pend=0x8860be4 "\005eval-\0164", fastmap=0x83e3984 "", multibyte=0) at regex.c:4022 #1 0x081aa0b5 in re_compile_fastmap (bufp=0x83e3960) at regex.c:4339 #2 0x081aa2c2 in re_search_2 (bufp=0x83e3960, str1=0x0, size1=0, str2=0x89fa230 "Search failed: \"[\340\275\200-\340\275\251\340\275\252][\340\276\220-\340\276\271\340\276\272\340\276\273\340\276\274]*[\340\275\260\366\220\202\216\340\275\261\340\275\262-\340\275\275\340\276\200\340\276\201\340\276\204]*[\340\275\276\340\276\202\340\276\203\340\276\206-\340\276\213\340\274\231\340\274\265\340\274\267]*\"", size2=105, startpos=0, range=105, regs=0x0, stop=105) at regex.c:4487 #3 0x081aa18c in re_search (bufp=0x83e3960, string=0x89fa230 "Search failed: \"[\340\275\200-\340\275\251\340\275\252][\340\276\220-\340\276\271\340\276\272\340\276\273\340\276\274]*[\340\275\260\366\220\202\216\340\275\261\340\275\262-\340\275\275\340\276\200\340\276\201\340\276\204]*[\340\275\276\340\276\202\340\276\203\340\276\206-\340\276\213\340\274\231\340\274\265\340\274\267]*\"", size=105, startpos=0, range=105, regs=0x0) at regex.c:4393 #4 0x081972f1 in fast_string_match (regexp=139244403, string=138652283) at search.c:505 #5 0x081d3fb6 in skip_debugger (conditions=138346117, data=141320317) at eval.c:1862 #6 0x081d4097 in maybe_call_debugger (conditions=138346117, sig=138556777, data=141320309) at eval.c:1889 #7 0x081d41e0 in find_handler_clause (handlers=138402201, conditions=138346117, sig=138556777, data=141320309) at eval.c:1961 #8 0x081d3c34 in Fsignal (error_symbol=138556777, data=141320309) at eval.c:1700 From handa@m17n.org Tue Mar 3 18:16:18 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 4 Mar 2009 02:16:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: ** X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=2.6 required=4.0 tests=FOURLA,IMPRONONCABLE_2,MONEY, STOCKLIKE autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n242GEq3008807 for <2435@emacsbugs.donarmstrong.com>; Tue, 3 Mar 2009 18:16:15 -0800 Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n242GC7G029999; Wed, 4 Mar 2009 11:16:12 +0900 (JST) env-from (handa@m17n.org) Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n242GCUo001224; Wed, 4 Mar 2009 11:16:12 +0900 (JST) env-from (handa@m17n.org) Received: by smtp2.aist.go.jp with ESMTP id n242GBje013451; Wed, 4 Mar 2009 11:16:11 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LegfF-0006kQ-1v; Wed, 04 Mar 2009 11:16:53 +0900 From: Kenichi Handa To: Chong Yidong CC: 2435@debbugs.gnu.org In-reply-to: <87zlg2a7b9.fsf@cyd.mit.edu> (message from Chong Yidong on Tue, 03 Mar 2009 11:40:26 -0500) Subject: Re: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> Message-Id: Date: Wed, 04 Mar 2009 11:16:53 +0900 In article <87zlg2a7b9.fsf@cyd.mit.edu>, Chong Yidong writes: >>> emacs -Q >>> M-x customize-group RET whitespace RET >>> C-v C-v > > > > I can't reproduce the crash with that. > It doesn't happen all the time---about once every three or four > attempts. Quite strange. I tried more than 10 times without crash. > > 2846 if (many_times_ok) > > 2847 { > > 2848 boolean simple = skip_one_char (laststart) == b; > > 2849 unsigned int startoffset = 0; > > 2850 re_opcode_t ofj = > > 2851 /* Check if the loop can match the empty string. */ > > 2852 (simple || !analyse_first (laststart, b, NULL, 0)) > > 2853 ? on_failure_jump : on_failure_jump_loop; > > > > Here, "simple" is always set to 1, so analyse_first is not > > called. > When I get the crash, simple is set to 0. > (gdb) p b > $4 = (unsigned char *) 0x8b927b7 "" > (gdb) p laststart > $5 = (unsigned char *) 0x8b92786 "\a\201\f" That is different in my case. When the execution reaches the above code (three or four times while displaying that Tibetan char), laststart is always "\004\200". Here the first byte \004 means `charset' OP, and that is reasonable because we are now handling '*' after "[...]". But '\a' (== 7 == stop_memory) is very strange. Please show me these values when simple is set to 0. (gdb) p bufp->buffer $58 = (unsigned char *) 0xa905aa0 "\004\200" (gdb) p laststart $59 = (unsigned char *) 0xa905ab2 "\004\200" (gdb) p bufp->buffer[0]@(b - bufp->buffer) $60 = "\004\200\000\000\002\000@\017\000i\017\000j\017\000j\017\000\004\200\000\000\004\000\220\017\000\271\017\000\272\017\000\272\017\000\273\017\000\273\017\000\274\017\000\274\017" (gdb) p laststart[0]@(b-laststart) $61 = "\004\200\000\000\004\000\220\017\000\271\017\000\272\017\000\272\017\000\273\017\000\273\017\000\274\017\000\274\017" Here, "\220\017\000" => 0xF90 "\271\017\000" => 0xFB9 "\272\017\000" => 0xFBA "\273\017\000" => 0xFBB "\274\017\000" => 0xFBC So, we are now processing the '*' just after the second [...] of tibetan-composable-pattern. --- Kenichi Handa handa@m17n.org From cyd@stupidchicken.com Tue Mar 3 20:40:00 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 4 Mar 2009 04:40:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: ** X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=2.6 required=4.0 tests=FOURLA,IMPRONONCABLE_2,MONEY, STOCKLIKE autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n244dvTc013429 for <2435@emacsbugs.donarmstrong.com>; Tue, 3 Mar 2009 20:39:58 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id 4145D57E20B; Tue, 3 Mar 2009 23:41:04 -0500 (EST) From: Chong Yidong To: Kenichi Handa Cc: 2435@debbugs.gnu.org Subject: Re: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> Date: Tue, 03 Mar 2009 23:41:04 -0500 In-Reply-To: (Kenichi Handa's message of "Wed, 04 Mar 2009 11:16:53 +0900") Message-ID: <87ab81293z.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Kenichi Handa writes: >> It doesn't happen all the time---about once every three or four >> attempts. Quite strange. > > I tried more than 10 times without crash. Here are my specs (latest CVS, no modifications): In GNU Emacs 23.0.91.29 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-03-03 on furry Windowing system distributor `The X.Org Foundation', version 11.0.10502000 configured using `configure 'CC=gcc' 'CFLAGS=-g'' LANG is en_US.UTF-8 I can reproduce it with `emacs -Q'. Do you at least see the redisplay problem reported by the OP? >> When I get the crash, simple is set to 0. > >> (gdb) p b >> $4 = (unsigned char *) 0x8b927b7 "" >> (gdb) p laststart >> $5 = (unsigned char *) 0x8b92786 "\a\201\f" > > That is different in my case. When the execution reaches > the above code (three or four times while displaying that > Tibetan char), laststart is always "\004\200". Here the > first byte \004 means `charset' OP, and that is reasonable > because we are now handling '*' after "[...]". > > But '\a' (== 7 == stop_memory) is very strange. Please show > me these values when simple is set to 0. (gdb) f 2 #2 0x081a1798 in regex_compile ( pattern=0x8356085 "[\340\275\200-\340\275\251\340\275\252][\340\276\220-\340\276\271\340\276\272\340\276\273\340\276\274]*[\340\275\260\366\220\202\216\340\275\261\340\275\262-\340\275\275\340\276\200\340\276\201\340\276\204]*[\340\275\276\340\276\202\340\276\203\340\276\206-\340\276\213\340\274\231\340\274\265\340\274\267]*", size=88, syntax=3408388, bufp=0x83e3210) at regex.c:2853 2853 ? on_failure_jump : on_failure_jump_loop; (gdb) p bufp->buffer $8 = (unsigned char *) 0x8b931d0 "\0169" (gdb) p laststart $10 = (unsigned char *) 0x8b93206 "\a\201\f" (gdb) p bufp->buffer[0]@(b-bufp->buffer) $11 = "\0169\000\002\002.Z\016.\000\006\001\016\006\000\002\001~\r!\000\002\002.~\004\b\000\000\000\000\000\000\377\003\022\r\000\004\b\000\000\000\000\000\000\377\003\r\360\377\002\001~\a\201\f\000\000\a\000p\017\000p\017\000\216\000\031\216\000\031q\017\000q\017\000r\017\000}\017\000\200\017\000\200\017\000\201\017\000\201\017\000\204\017\000\204\017" (gdb) p laststart[0]@(b-laststart) $12 = "\a\201\f\000\000\a\000p\017\000p\017\000\216\000\031\216\000\031q\017\000q\017\000r\017\000}\017\000\200\017\000\200\017\000\201\017\000\201\017\000\204\017\000\204\017" From handa@m17n.org Tue Mar 3 23:46:54 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 4 Mar 2009 07:46:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: ** X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=2.6 required=4.0 tests=FOURLA,IMPRONONCABLE_2,MONEY, STOCKLIKE autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n247knIf030649 for <2435@emacsbugs.donarmstrong.com>; Tue, 3 Mar 2009 23:46:51 -0800 Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n247kmBg015317; Wed, 4 Mar 2009 16:46:48 +0900 (JST) env-from (handa@m17n.org) Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n247kmus007486; Wed, 4 Mar 2009 16:46:48 +0900 (JST) env-from (handa@m17n.org) Received: by smtp2.aist.go.jp with ESMTP id n247klxM021023; Wed, 4 Mar 2009 16:46:47 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LelpB-0007tx-PR; Wed, 04 Mar 2009 16:47:29 +0900 From: Kenichi Handa To: Chong Yidong CC: 2435@debbugs.gnu.org In-reply-to: <87ab81293z.fsf@cyd.mit.edu> (message from Chong Yidong on Tue, 03 Mar 2009 23:41:04 -0500) Subject: Re: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> Message-Id: Date: Wed, 04 Mar 2009 16:47:29 +0900 In article <87ab81293z.fsf@cyd.mit.edu>, Chong Yidong writes: > Here are my specs (latest CVS, no modifications): > In GNU Emacs 23.0.91.29 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-03-03 on furry > Windowing system distributor `The X.Org Foundation', version 11.0.10502000 > configured using `configure 'CC=gcc' 'CFLAGS=-g'' > LANG is en_US.UTF-8 > I can reproduce it with `emacs -Q'. Mine are the same: In GNU Emacs 23.0.91.3 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-02-27 on etlken Windowing system distributor `The X.Org Foundation', version 11.0.10502000 configured using `configure 'CFLAGS=-g'' and can't reproduce it with 'LANG=en_US.UTF-8 emacs -Q'. > Do you at least see the redisplay problem reported by the OP? No. There are 5 non-ASCII characters on the line of "Whitespace Hspace Regexp:". The first one is shown as "\240", the second one by an empty box, the others are by proper fonts, and Emacs doesn't stop. > (gdb) f 2 > #2 0x081a1798 in regex_compile ( > pattern=0x8356085 > "[\340\275\200-\340\275\251\340\275\252][\340\276\220-\340\276\271\340\276\272\340\276\273\340\276\274]*[\340\275\260\366\220\202\216\340\275\261\340\275\262-\340\275\275\340\276\200\340\276\201\340\276\204]*[\340\275\276\340\276\202\340\276\203\340\276\206-\340\276\213\340\274\231\340\274\265\340\274\267]*", > size=88, syntax=3408388, bufp=0x83e3210) at regex.c:2853 > 2853 ? on_failure_jump : on_failure_jump_loop; > (gdb) p bufp->buffer > $8 = (unsigned char *) 0x8b931d0 "\0169" > (gdb) p laststart > $10 = (unsigned char *) 0x8b93206 "\a\201\f" > (gdb) p bufp->buffer[0]@(b-bufp->buffer) > $11 = "\0169\000\002\002.Z\016.\000\006\001\016\006\000\002\001~\r!\000\002\002.~\004\b\000\000\000\000\000\000\377\003\022\r\000\004\b\000\000\000\000\000\000\377\003\r\360\377\002\001~\a\201\f\000\000\a\000p\017\000p\017\000\216\000\031\216\000\031q\017\000q\017\000r\017\000}\017\000\200\017\000\200\017\000\201\017\000\201\017\000\204\017\000\204\017" > (gdb) p laststart[0]@(b-laststart) > $12 = "\a\201\f\000\000\a\000p\017\000p\017\000\216\000\031\216\000\031q\017\000q\017\000r\017\000}\017\000\200\017\000\200\017\000\201\017\000\201\017\000\204\017\000\204\017" It seems that `pattern' is correct, but `bufp->buffer' is the compiled code for some of jkr-compr related regexp. Could you please find why that happens? This is the disassembled code of the head of bufp->buffer. on_failer_jump #x39 exactn 2 ".Z" on_failer_jump #x2E start_memory 1 on_failer_jump #x06 exactn 1 "~" jump #x21 exactn 2 ".~" charset "0-9" on_failure_jump_smart 0x08 charset "0-9" jump -0x10 exactn 1 "~" stop_memory \201 <-- should not happen --- Kenichi Handa handa@m17n.org From cyd@stupidchicken.com Wed Mar 4 20:08:43 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 5 Mar 2009 04:08:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=IMPRONONCABLE_2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n2548eNU025253 for <2435@emacsbugs.donarmstrong.com>; Wed, 4 Mar 2009 20:08:41 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id 8690757E1FC; Wed, 4 Mar 2009 23:09:48 -0500 (EST) From: Chong Yidong To: Kenichi Handa Cc: 2435@debbugs.gnu.org Subject: Re: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> Date: Wed, 04 Mar 2009 23:09:48 -0500 In-Reply-To: (Kenichi Handa's message of "Wed, 04 Mar 2009 16:47:29 +0900") Message-ID: <878wnk7gqb.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Kenichi Handa writes: > It seems that `pattern' is correct, but `bufp->buffer' is > the compiled code for some of jkr-compr related regexp. > Could you please find why that happens? I think the problem is that regex_compile can call load_charset, which can call regex_compile. I think regex_compile is not designed to be called recursively, leading to memory corruption. Here is a backtrace (I inserted some debugging code to detect when regex_compile is called recursively): #0 abort () at emacs.c:432 #1 0x08196965 in compile_pattern (pattern=139288251, regp=0x0, translate=138358041, posix=0, multibyte=0) at search.c:262 #2 0x0819727d in fast_string_match (regexp=139288251, string=138555267) at search.c:509 #3 0x0817eb9f in Ffind_file_name_handler (filename=138555267, operation=138416225) at fileio.c:380 #4 0x0817f5b3 in Fexpand_file_name (name=138555267, default_directory=141645459) at fileio.c:859 #5 0x081fb92e in openp (path=138676461, str=138555267, #suffixes=138926685, storeptr=0x0, predicate=138358041) at lread.c:1425 #6 0x080b95f6 in load_charset_map_from_file (charset=0x84b4acc, mapfile=138555267, control_flag=1) at charset.c:515 #7 0x080b9bb1 in load_charset (charset=0x84b4acc, control_flag=1) at charset.c:652 #8 0x080bdce8 in maybe_unify_char (c=1638542, val=138788937) at charset.c:1679 #9 0x080eb5fa in string_char ( p=0x83560ac "\340\275\261\340\275\262-\340\275\275\340\276\200\340\276\201\340\276\204]*[\340\275\276\340\276\202\340\276\203\340\276\206-\340\276\213\340\274\231\340\274\265\340\274\267]*", advanced=0x0, len=0xbfc70d28) at character.c:236 #10 0x081a2ac9 in regex_compile ( pattern=0x8356085 "[\340\275\200-\340\275\251\340\275\252][\340\276\220-\340\276\271\340\276\272\340\276\273\340\276\274]*[\340\275\260\366\220\202\216\340\275\261\340\275\262-\340\275\275\340\276\200\340\276\201\340\276\204]*[\340\275\276\340\276\202\340\276\203\340\276\206-\340\276\213\340\274\231\340\274\265\340\274\267]*", size=88, syntax=3408388, bufp=0x83e3210) at regex.c:2982 #11 0x081b3dca in re_compile_pattern ( pattern=0x8356085 "[\340\275\200-\340\275\251\340\275\252][\340\276\220-\340\276\271\340\276\272\340\276\273\340\276\274]*[\340\275\260\366\220\202\216\340\275\261\340\275\262-\340\275\275\340\276\200\340\276\201\340\276\204]*[\340\275\276\340\276\202\340\276\203\340\276\206-\340\276\213\340\274\231\340\274\265\340\274\267]*", length=88, bufp=0x83e3210) at regex.c:6518 #12 0x08196714 in compile_pattern_1 (cp=0x83e3200, pattern=137244011, translate=138358041, regp=0x0, posix=0) at search.c:160 #13 0x08196996 in compile_pattern (pattern=137244011, regp=0x0, translate=138358041, posix=0, multibyte=1) at search.c:265 From cyd@stupidchicken.com Wed Mar 4 20:41:40 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 5 Mar 2009 04:41:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=FOURLA,MURPHY_DRUGS_REL8 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n254fbDj001283 for <2435@emacsbugs.donarmstrong.com>; Wed, 4 Mar 2009 20:41:38 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id EE5F057E1FC; Wed, 4 Mar 2009 23:42:45 -0500 (EST) From: Chong Yidong To: Kenichi Handa Cc: 2435@debbugs.gnu.org Subject: Re: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> Date: Wed, 04 Mar 2009 23:42:45 -0500 In-Reply-To: (Kenichi Handa's message of "Wed, 04 Mar 2009 16:47:29 +0900") Message-ID: <877i34shq2.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii The following patch tries to avoid the problem by updating the regexp list before using the regexp cell. It seems to fix the problem; or do have a different suggestion? *** trunk/src/search.c.~1.237.~ 2009-02-12 16:45:29.000000000 -0500 --- trunk/src/search.c 2009-03-04 23:38:35.000000000 -0500 *************** *** 134,140 **** char *val; reg_syntax_t old; ! cp->regexp = Qnil; cp->buf.translate = (! NILP (translate) ? translate : make_number (0)); cp->posix = posix; cp->buf.multibyte = STRING_MULTIBYTE (pattern); --- 134,140 ---- char *val; reg_syntax_t old; ! cp->regexp = Qt; cp->buf.translate = (! NILP (translate) ? translate : make_number (0)); cp->posix = posix; cp->buf.multibyte = STRING_MULTIBYTE (pattern); *************** *** 239,245 **** nil should never appear before a non-nil entry. */ if (NILP (cp->regexp)) goto compile_it; ! if (SCHARS (cp->regexp) == SCHARS (pattern) && STRING_MULTIBYTE (cp->regexp) == STRING_MULTIBYTE (pattern) && !NILP (Fstring_equal (cp->regexp, pattern)) && EQ (cp->buf.translate, (! NILP (translate) ? translate : make_number (0))) --- 239,246 ---- nil should never appear before a non-nil entry. */ if (NILP (cp->regexp)) goto compile_it; ! if (STRINGP (cp->regexp) ! && SCHARS (cp->regexp) == SCHARS (pattern) && STRING_MULTIBYTE (cp->regexp) == STRING_MULTIBYTE (pattern) && !NILP (Fstring_equal (cp->regexp, pattern)) && EQ (cp->buf.translate, (! NILP (translate) ? translate : make_number (0))) *************** *** 248,273 **** || EQ (cp->syntax_table, current_buffer->syntax_table)) && !NILP (Fequal (cp->whitespace_regexp, Vsearch_spaces_regexp)) && cp->buf.charset_unibyte == charset_unibyte) ! break; /* If we're at the end of the cache, compile into the nil cell we found, or the last (least recently used) cell with a ! string value. */ if (cp->next == 0) { compile_it: compile_pattern_1 (cp, pattern, translate, regp, posix); break; } } - /* When we get here, cp (aka *cpp) contains the compiled pattern, - either because we found it in the cache or because we just compiled it. - Move it to the front of the queue to mark it as most recently used. */ - *cpp = cp->next; - cp->next = searchbuf_head; - searchbuf_head = cp; - /* Advise the searching functions about the space we have allocated for register data. */ if (regp) --- 249,279 ---- || EQ (cp->syntax_table, current_buffer->syntax_table)) && !NILP (Fequal (cp->whitespace_regexp, Vsearch_spaces_regexp)) && cp->buf.charset_unibyte == charset_unibyte) ! { ! /* We found a compiled pattern. Move it to the front of the ! queue to mark it as most recently used. */ ! *cpp = cp->next; ! cp->next = searchbuf_head; ! searchbuf_head = cp; ! break; ! } /* If we're at the end of the cache, compile into the nil cell we found, or the last (least recently used) cell with a ! string value. We must update the queue before calling ! compile_pattern_1, because compile_pattern_1 can end up ! calling compile_pattern recursively (via load_charset). */ if (cp->next == 0) { compile_it: + *cpp = cp->next; + cp->next = searchbuf_head; + searchbuf_head = cp; compile_pattern_1 (cp, pattern, translate, regp, posix); break; } } /* Advise the searching functions about the space we have allocated for register data. */ if (regp) From handa@m17n.org Wed Mar 4 22:38:38 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 5 Mar 2009 06:38:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n256cYdp030857 for <2435@emacsbugs.donarmstrong.com>; Wed, 4 Mar 2009 22:38:36 -0800 Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n256cXsH003366; Thu, 5 Mar 2009 15:38:33 +0900 (JST) env-from (handa@m17n.org) Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n256cXdH013756; Thu, 5 Mar 2009 15:38:33 +0900 (JST) env-from (handa@m17n.org) Received: by smtp4.aist.go.jp with ESMTP id n256cXtC017676; Thu, 5 Mar 2009 15:38:33 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1Lf7Ei-00045X-IU; Thu, 05 Mar 2009 15:39:16 +0900 From: Kenichi Handa To: Chong Yidong CC: 2435@debbugs.gnu.org In-reply-to: <878wnk7gqb.fsf@cyd.mit.edu> (message from Chong Yidong on Wed, 04 Mar 2009 23:09:48 -0500) Subject: Re: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <878wnk7gqb.fsf@cyd.mit.edu> Message-Id: Date: Thu, 05 Mar 2009 15:39:16 +0900 In article <878wnk7gqb.fsf@cyd.mit.edu>, Chong Yidong writes: > Kenichi Handa writes: > > It seems that `pattern' is correct, but `bufp->buffer' is > > the compiled code for some of jkr-compr related regexp. > > Could you please find why that happens? > I think the problem is that regex_compile can call load_charset, which > can call regex_compile. I think regex_compile is not designed to be > called recursively, leading to memory corruption. Ah! That is a likely cause of the bug. I'll find a way to avoid loading charset at that moment. --- Kenichi Handa handa@m17n.org From handa@m17n.org Thu Mar 5 03:22:44 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 5 Mar 2009 11:22:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=IMPRONONCABLE_2, MURPHY_DRUGS_REL8 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n25BMf96006553 for <2435@emacsbugs.donarmstrong.com>; Thu, 5 Mar 2009 03:22:42 -0800 Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n25BMePT012758; Thu, 5 Mar 2009 20:22:40 +0900 (JST) env-from (handa@m17n.org) Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n25BMdH6014627; Thu, 5 Mar 2009 20:22:39 +0900 (JST) env-from (handa@m17n.org) Received: by smtp2.aist.go.jp with ESMTP id n25BMbVc027631; Thu, 5 Mar 2009 20:22:37 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LfBfd-0004kz-Bc; Thu, 05 Mar 2009 20:23:21 +0900 From: Kenichi Handa To: Chong Yidong CC: 2435@debbugs.gnu.org In-reply-to: <877i34shq2.fsf@cyd.mit.edu> (message from Chong Yidong on Wed, 04 Mar 2009 23:42:45 -0500) Subject: Re: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> Message-Id: Date: Thu, 05 Mar 2009 20:23:21 +0900 In article <877i34shq2.fsf@cyd.mit.edu>, Chong Yidong writes: > The following patch tries to avoid the problem by updating the regexp > list before using the regexp cell. It seems to fix the problem; or do > have a different suggestion? It will fix the current problem of bufp contents being changed by recursive call, but we still have a danger of Lisp code being called in re_compile_pattern, which may lead to relocation of string data pointed by the arg "pattern". So, I think we must avoid any Lisp calls within re_compile_pattern. --- Kenichi Handa handa@m17n.org From monnier@iro.umontreal.ca Thu Mar 5 08:46:49 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 5 Mar 2009 16:46:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n25GkjSG023910 for <2435@emacsbugs.donarmstrong.com>; Thu, 5 Mar 2009 08:46:47 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEANOQr0nO+KX2/2dsb2JhbACBTtgRhAgGhBI X-IronPort-AV: E=Sophos;i="4.38,308,1233550800"; d="scan'208";a="34737504" Received: from 206-248-165-246.dsl.teksavvy.com (HELO pastel.home) ([206.248.165.246]) by ironport2-out.teksavvy.com with ESMTP; 05 Mar 2009 11:46:40 -0500 Received: by pastel.home (Postfix, from userid 20848) id 9A4487FA2; Thu, 5 Mar 2009 11:46:39 -0500 (EST) From: Stefan Monnier To: Kenichi Handa Cc: 2435@debbugs.gnu.org, Chong Yidong Subject: Re: bug#2435: Bug 2435 Message-ID: References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> Date: Thu, 05 Mar 2009 11:46:39 -0500 In-Reply-To: (Kenichi Handa's message of "Thu, 05 Mar 2009 20:23:21 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > It will fix the current problem of bufp contents being > changed by recursive call, but we still have a danger of > Lisp code being called in re_compile_pattern, which may lead > to relocation of string data pointed by the arg "pattern". > So, I think we must avoid any Lisp calls within > re_compile_pattern. Indeed, tho it's not clear how we could do that. One way that occurs to me is: if we need to `load' or do some such dangerous operation in re_compile_pattern, signal an error so we exit re_compile_pattern. Then catch this error in the calling code where we can do the corresponding operation safely and call re_compile_pattern again. Kind of ugly, but for autoload-style operations it seems acceptable. Stefan From handa@m17n.org Thu Mar 5 19:37:31 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 6 Mar 2009 03:37:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.7 required=4.0 tests=FVGT_m_MULTI_ODD, HAS_BUG_NUMBER,IMPRONONCABLE_1,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n263bOGT026766 for <2435@emacsbugs.donarmstrong.com>; Thu, 5 Mar 2009 19:37:26 -0800 Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id n263bME9014040; Fri, 6 Mar 2009 12:37:22 +0900 (JST) env-from (handa@m17n.org) Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id n263bMnI006046; Fri, 6 Mar 2009 12:37:22 +0900 (JST) env-from (handa@m17n.org) Received: by smtp3.aist.go.jp with ESMTP id n263bMdu021187; Fri, 6 Mar 2009 12:37:22 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LfQsx-00076s-69; Fri, 06 Mar 2009 12:38:07 +0900 From: Kenichi Handa To: Stefan Monnier CC: 2435@debbugs.gnu.org, cyd@stupidchicken.com In-reply-to: (message from Stefan Monnier on Thu, 05 Mar 2009 11:46:39 -0500) Subject: Re: bug#2435: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> Message-Id: Date: Fri, 06 Mar 2009 12:38:07 +0900 In article , Stefan Monnier writes: > > It will fix the current problem of bufp contents being > > changed by recursive call, but we still have a danger of > > Lisp code being called in re_compile_pattern, which may lead > > to relocation of string data pointed by the arg "pattern". > > So, I think we must avoid any Lisp calls within > > re_compile_pattern. > Indeed, tho it's not clear how we could do that. One way that occurs to > me is: if we need to `load' or do some such dangerous operation in > re_compile_pattern, signal an error so we exit re_compile_pattern. > Then catch this error in the calling code where we can do the > corresponding operation safely and call re_compile_pattern again. > Kind of ugly, but for autoload-style operations it seems acceptable. We should take care of re_search_2 and re_match_2_internal too. If the problem is only the call of openp in load_charset_map_from_file, and building various Lisp object is ok, we can change load_charset_map_from_file to open a charset map by itself without using openp. --- Kenichi Handa handa@m17n.org From cyd@stupidchicken.com Thu Mar 5 20:10:24 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 6 Mar 2009 04:10:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n264AM7a003744 for <2435@emacsbugs.donarmstrong.com>; Thu, 5 Mar 2009 20:10:23 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id 695F557E22A; Thu, 5 Mar 2009 23:11:31 -0500 (EST) From: Chong Yidong To: Kenichi Handa Cc: Stefan Monnier , 2435@debbugs.gnu.org Subject: Re: bug#2435: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> Date: Thu, 05 Mar 2009 23:11:31 -0500 In-Reply-To: (Kenichi Handa's message of "Fri, 06 Mar 2009 12:38:07 +0900") Message-ID: <877i33cmto.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Kenichi Handa writes: > We should take care of re_search_2 and re_match_2_internal > too. > > If the problem is only the call of openp in > load_charset_map_from_file, and building various Lisp object > is ok, we can change load_charset_map_from_file to open a > charset map by itself without using openp. Not using openp would be troublesome. How about binding file-name-handler-alist to nil inside load_charset_map_from_file? That prevents find-file-name-handler from performing the regexp compilation and string search. From handa@m17n.org Thu Mar 5 20:48:01 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 6 Mar 2009 04:48:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.9 required=4.0 tests=FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n264lvUn012373 for <2435@emacsbugs.donarmstrong.com>; Thu, 5 Mar 2009 20:47:59 -0800 Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id n264lupC011093; Fri, 6 Mar 2009 13:47:56 +0900 (JST) env-from (handa@m17n.org) Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id n264lu9q018472; Fri, 6 Mar 2009 13:47:56 +0900 (JST) env-from (handa@m17n.org) Received: by smtp3.aist.go.jp with ESMTP id n264ltLS011015; Fri, 6 Mar 2009 13:47:55 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LfRzE-0000uk-Oh; Fri, 06 Mar 2009 13:48:40 +0900 From: Kenichi Handa To: Chong Yidong CC: monnier@iro.umontreal.ca, 2435@debbugs.gnu.org In-reply-to: <877i33cmto.fsf@cyd.mit.edu> (message from Chong Yidong on Thu, 05 Mar 2009 23:11:31 -0500) Subject: Re: bug#2435: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> <877i33cmto.fsf@cyd.mit.edu> Message-Id: Date: Fri, 06 Mar 2009 13:48:40 +0900 In article <877i33cmto.fsf@cyd.mit.edu>, Chong Yidong writes: > Kenichi Handa writes: > > We should take care of re_search_2 and re_match_2_internal > > too. > > > > If the problem is only the call of openp in > > load_charset_map_from_file, and building various Lisp object > > is ok, we can change load_charset_map_from_file to open a > > charset map by itself without using openp. > Not using openp would be troublesome. How about binding > file-name-handler-alist to nil inside load_charset_map_from_file? That > prevents find-file-name-handler from performing the regexp compilation > and string search. That's a good idea if "building various Lisp object is ok" is true. Stefan, what do you think? --- Kenichi Handa handa@m17n.org *** charset.c.~1.169.~ 2009-01-30 21:29:36.000000000 +0900 --- charset.c 2009-03-06 13:44:24.000000000 +0900 *************** *** 494,499 **** --- 494,509 ---- extern void add_to_log P_ ((char *, Lisp_Object, Lisp_Object)); + extern Lisp_Object Vfile_name_handler_alist; + + static Lisp_Object + load_charset_map_from_file_restore (arg) + Lisp_Object arg; + { + Vfile_name_handler_alist = arg; + return Qnil; + } + static void load_charset_map_from_file (charset, mapfile, control_flag) struct charset *charset; *************** *** 508,518 **** --- 518,533 ---- Lisp_Object suffixes; struct charset_map_entries *head, *entries; int n_entries; + int count = SPECPDL_INDEX (); suffixes = Fcons (build_string (".map"), Fcons (build_string (".TXT"), Qnil)); + record_unwind_protect (load_charset_map_from_file_restore, + Vfile_name_handler_alist); + Vfile_name_handler_alist = Qnil; fd = openp (Vcharset_map_path, mapfile, suffixes, NULL, Qnil); + unbind_to (count, Qnil); if (fd < 0 || ! (fp = fdopen (fd, "r"))) { From monnier@iro.umontreal.ca Thu Mar 5 21:07:58 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 6 Mar 2009 05:07:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n2657sXk018017 for <2435@emacsbugs.donarmstrong.com>; Thu, 5 Mar 2009 21:07:56 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAEM+sElFxKsx/2dsb2JhbACBTtYVhAgGhBI X-IronPort-AV: E=Sophos;i="4.38,312,1233550800"; d="scan'208";a="34775833" Received: from 69-196-171-49.dsl.teksavvy.com (HELO pastel.home) ([69.196.171.49]) by ironport2-out.teksavvy.com with ESMTP; 06 Mar 2009 00:07:48 -0500 Received: by pastel.home (Postfix, from userid 20848) id 905057FA2; Fri, 6 Mar 2009 00:07:48 -0500 (EST) From: Stefan Monnier To: Kenichi Handa Cc: Chong Yidong , 2435@debbugs.gnu.org Subject: Re: bug#2435: Bug 2435 Message-ID: References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> <877i33cmto.fsf@cyd.mit.edu> Date: Fri, 06 Mar 2009 00:07:48 -0500 In-Reply-To: (Kenichi Handa's message of "Fri, 06 Mar 2009 13:48:40 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> > We should take care of re_search_2 and re_match_2_internal >> > too. >> > >> > If the problem is only the call of openp in >> > load_charset_map_from_file, and building various Lisp object >> > is ok, we can change load_charset_map_from_file to open a >> > charset map by itself without using openp. >> Not using openp would be troublesome. How about binding >> file-name-handler-alist to nil inside load_charset_map_from_file? That >> prevents find-file-name-handler from performing the regexp compilation >> and string search. > That's a good idea if "building various Lisp object is ok" > is true. AFAIK building objects is perfectly fine, yes. I wonder why you use record_unwind_protect rather than specbind, tho. Also if we do that, we should add a note in the docstring of charset-map-path that it does not obey file-name-handler-alist. Stefan From handa@m17n.org Thu Mar 5 21:20:20 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 6 Mar 2009 05:20:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=FVGT_m_MULTI_ODD, HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n265KHb9021667 for <2435@emacsbugs.donarmstrong.com>; Thu, 5 Mar 2009 21:20:18 -0800 Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id n265KGwG028016; Fri, 6 Mar 2009 14:20:16 +0900 (JST) env-from (handa@m17n.org) Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id n265KGdi023505; Fri, 6 Mar 2009 14:20:16 +0900 (JST) env-from (handa@m17n.org) Received: by smtp1.aist.go.jp with ESMTP id n265KG0l000926; Fri, 6 Mar 2009 14:20:16 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LfSUX-00010M-GS; Fri, 06 Mar 2009 14:21:01 +0900 From: Kenichi Handa To: Stefan Monnier CC: cyd@stupidchicken.com, 2435@debbugs.gnu.org In-reply-to: (message from Stefan Monnier on Fri, 06 Mar 2009 00:07:48 -0500) Subject: Re: bug#2435: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> <877i33cmto.fsf@cyd.mit.edu> Message-Id: Date: Fri, 06 Mar 2009 14:21:01 +0900 In article , Stefan Monnier writes: > AFAIK building objects is perfectly fine, yes. > I wonder why you use record_unwind_protect rather than specbind, tho. Don't we need record_unwind_protect for the case that quit is signaled in emacs_open that is called from openp? > Also if we do that, we should add a note in the docstring of > charset-map-path that it does not obey file-name-handler-alist. Ok. --- Kenichi Handa handa@m17n.org From cyd@stupidchicken.com Fri Mar 6 19:59:25 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 7 Mar 2009 03:59:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n273xMFb018978 for <2435@emacsbugs.donarmstrong.com>; Fri, 6 Mar 2009 19:59:23 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id EDCCD57E1D7; Fri, 6 Mar 2009 23:00:32 -0500 (EST) From: Chong Yidong To: Kenichi Handa Cc: Stefan Monnier , 2435@debbugs.gnu.org Subject: Re: bug#2435: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> <877i33cmto.fsf@cyd.mit.edu> Date: Fri, 06 Mar 2009 23:00:32 -0500 In-Reply-To: (Kenichi Handa's message of "Fri, 06 Mar 2009 14:21:01 +0900") Message-ID: <87ab7y6kyn.fsf@cyd.mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Kenichi Handa writes: >> AFAIK building objects is perfectly fine, yes. >> I wonder why you use record_unwind_protect rather than specbind, tho. > > Don't we need record_unwind_protect for the case that quit > is signaled in emacs_open that is called from openp? Please go ahead and check in the patch, thanks. From monnier@iro.umontreal.ca Sat Mar 7 15:07:29 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 7 Mar 2009 23:07:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n27N7PCw006164 for <2435@emacsbugs.donarmstrong.com>; Sat, 7 Mar 2009 15:07:27 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAOOMsklLd/DG/2dsb2JhbACBTtFahAUGhCI X-IronPort-AV: E=Sophos;i="4.38,320,1233550800"; d="scan'208";a="34843876" Received: from 75-119-240-198.dsl.teksavvy.com (HELO pastel.home) ([75.119.240.198]) by ironport2-out.teksavvy.com with ESMTP; 07 Mar 2009 18:07:20 -0500 Received: by pastel.home (Postfix, from userid 20848) id 940377FC2; Sat, 7 Mar 2009 18:07:19 -0500 (EST) From: Stefan Monnier To: Kenichi Handa Cc: cyd@stupidchicken.com, 2435@debbugs.gnu.org Subject: Re: bug#2435: Bug 2435 Message-ID: References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> <877i33cmto.fsf@cyd.mit.edu> Date: Sat, 07 Mar 2009 18:07:19 -0500 In-Reply-To: (Kenichi Handa's message of "Fri, 06 Mar 2009 14:21:01 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> AFAIK building objects is perfectly fine, yes. >> I wonder why you use record_unwind_protect rather than specbind, tho. > Don't we need record_unwind_protect for the case that quit > is signaled in emacs_open that is called from openp? specbind does the same thing (except that it's specially designed for the job at hand of temporarily modifying a variable). >> Also if we do that, we should add a note in the docstring of >> charset-map-path that it does not obey file-name-handler-alist. > Ok. Thanks, Stefan From handa@m17n.org Sun Mar 8 18:12:02 2009 Received: (at 2435) by emacsbugs.donarmstrong.com; 9 Mar 2009 01:12:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.6 required=4.0 tests=FOURLA,FVGT_m_MULTI_ODD, HAS_BUG_NUMBER,IMPRONONCABLE_1,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n291Bw7o030417 for <2435@emacsbugs.donarmstrong.com>; Sun, 8 Mar 2009 18:12:00 -0700 Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n291BvG4016291; Mon, 9 Mar 2009 10:11:57 +0900 (JST) env-from (handa@m17n.org) Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n291BuC2004021; Mon, 9 Mar 2009 10:11:57 +0900 (JST) env-from (handa@m17n.org) Received: by smtp2.aist.go.jp with ESMTP id n291Bu9e001351; Mon, 9 Mar 2009 10:11:56 +0900 (JST) env-from (handa@m17n.org) Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LgU2D-00013e-2T; Mon, 09 Mar 2009 10:12:01 +0900 From: Kenichi Handa To: Stefan Monnier CC: cyd@stupidchicken.com, 2435@debbugs.gnu.org In-reply-to: (message from Stefan Monnier on Sat, 07 Mar 2009 18:07:19 -0500) Subject: Re: bug#2435: Bug 2435 References: <87fxhvcmvf.fsf@cyd.mit.edu> <87zlg2a7b9.fsf@cyd.mit.edu> <87ab81293z.fsf@cyd.mit.edu> <877i34shq2.fsf@cyd.mit.edu> <877i33cmto.fsf@cyd.mit.edu> Message-Id: Date: Mon, 09 Mar 2009 10:12:01 +0900 In article , Stefan Monnier writes: >>> AFAIK building objects is perfectly fine, yes. >>> I wonder why you use record_unwind_protect rather than specbind, tho. > > Don't we need record_unwind_protect for the case that quit > > is signaled in emacs_open that is called from openp? > specbind does the same thing (except that it's specially designed for > the job at hand of temporarily modifying a variable). Ah! I see. Ok, I've just installed this change. 2009-03-09 Kenichi Handa * charset.c (Qfile_name_handler_alist): Extern it. (load_charset_map_from_file): Temporarily bind `file-name-handler-alist' to nil while calling openp. Index: charset.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/charset.c,v retrieving revision 1.169 retrieving revision 1.170 diff -u -r1.169 -r1.170 --- charset.c 4 Feb 2009 01:55:07 -0000 1.169 +++ charset.c 9 Mar 2009 01:09:23 -0000 1.170 @@ -477,6 +477,7 @@ return n; } +extern Lisp_Object Qfile_name_handler_alist; /* Return a mapping vector for CHARSET loaded from MAPFILE. Each line of MAPFILE has this form @@ -490,7 +491,10 @@ The returned vector has this form: [ CODE1 CHAR1 CODE2 CHAR2 .... ] where CODE1 is a code-point or a cons of code-points specifying a - range. */ + range. + + Note that this funciton uses `openp' to open MAPFILE but ignores + `file-name-handler-alist to avoid running any Lisp codes. */ extern void add_to_log P_ ((char *, Lisp_Object, Lisp_Object)); @@ -508,11 +512,14 @@ Lisp_Object suffixes; struct charset_map_entries *head, *entries; int n_entries; + int count = SPECPDL_INDEX (); suffixes = Fcons (build_string (".map"), Fcons (build_string (".TXT"), Qnil)); + specbind (Qfile_name_handler_alist, Qnil); fd = openp (Vcharset_map_path, mapfile, suffixes, NULL, Qnil); + unbind_to (count, Qnil); if (fd < 0 || ! (fp = fdopen (fd, "r"))) { --- Kenichi Handa handa@m17n.org From cyd@stupidchicken.com Sun Mar 8 18:46:36 2009 Received: (at control) by emacsbugs.donarmstrong.com; 9 Mar 2009 01:46:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n291kYR8006680 for ; Sun, 8 Mar 2009 18:46:35 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 41B7557E205; Sun, 8 Mar 2009 21:47:46 -0400 (EDT) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 2435 Date: Sun, 08 Mar 2009 21:47:46 -0400 Message-ID: <874oy3a2m5.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii close 2435 thanks From unknown Fri Aug 15 14:18:20 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: $requester Subject: Internal Control Message-Id: bug archived. Date: Mon, 06 Apr 2009 14:24:08 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A log time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator