GNU bug report logs - #2435
23.0.90; customize/whitespace: display stops updating

Previous Next

Full log

View this message in rfc822 format

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 2435 <at> debbugs.gnu.org
Subject: bug#2435: Bug 2435
Date: Wed, 04 Mar 2009 16:47:29 +0900

In article <87ab81293z.fsf <at> cyd.mit.edu>, Chong Yidong <cyd <at> stupidchicken.com> 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 <at> m17n.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.