Issue511

classification
Title Regex search fails with non-ascii characters
Type defect Module core code 21.4
Severity some work obstructed Platform x86
Keywords Nosy List rassy, stephen
explanation
process
These controls should only be changed by committers and tracker administrators.
Status committed   Reason
Superseder  
Priority normal   Assigned To

Created on 2009-03-29.23:54:19 by rassy, last changed 2009-04-01.23:47:39 by rassy.

Files
File name Uploaded Type Edit Remove
system_info.txt rassy, 2009-03-29.23:54:19 text/plain
Messages
msg1172 [hidden] ([hidden]) Date: 2009-04-01.23:47:39
  Message-ID: <1238629659.95.0.742828597409.issue511@xemacs.org>
Dear Bug Team!

Thank you for the quick and kind reply! Unfortunately, the problem still
exists in 21.4.22. However, I found a post on Gmane saying that the
ChangeLog entry about the patch was applied to 21.4.22 while the patch
itself was not
(http://article.gmane.org/gmane.emacs.xemacs.patches/9855/match=18654.1143.304851.782755).

Best regards,
Tilman Rassy
msg1167 [hidden] ([hidden]) Date: 2009-03-30.04:15:19
  Message-ID: <1238386520.02.0.240115886987.issue511@xemacs.org>
This should be fixed in 21.4.22; please upgrade, test, and let us know if you 
still experience problems.  See this entry in src/ChangeLog:

2008-11-01  Stephen J. Turnbull  <stephen@xemacs.org>

         * regex.c (re_search_2): Fix at_dot by changing charpos to bytepos.
         From Julian Bradfield <18654.1143.304851.782775@krk.inf.ed.ac.uk>.

where the angle brackets refer to an xemacs-beta post (probably the easiest 
way to find it is to search on Gmane).  There's a technical explanation of the 
bug in that thread, which (if you still have problems) may be of some help in 
describing why your issue is different from the one fixed by that patch.

BTW, thank you very much for the care you put into your report.  It is greatly 
appreciated!
msg1166 [hidden] ([hidden]) Date: 2009-03-29.23:54:19
Dear Bug Team!

I noticed the following problem: If a buffer contains non-ascii
characters like German umlauts, e.g. ä, or french accented characters,
like è, re-search-forward fails to find regular expressions starting
with "\=". Here is a description how to reproduce the problem:

1. Define a function

(defun my-find-regexp ()
	(interactive)
	(message (if (re-search-forward "\\=foo[0-9]" nil t) "Yes" "No")))

2. Create a new buffer and insert the following text:

DEMO FILE START

foo1

ä

foo2

DEMO FILE END

3. Place the point at the beginning of "foo1" and type

  M-x my-find-regexp RET

The message "Yes" occurs in the minibuffer, indicating that the
regular expression matched.

4. Place the point at the beginning of "foo2" and type

  M-x my-find-regexp RET

The message "No" occurs in the minibuffer, indicating that the
regular expression did _not_ match, though to should have matched.

The problem seems to be related to Mule, since I noticed it on Mule
XEmacen only.

System information: XEmacs 21.4.21 on Ubuntu 8.10, x86 (please find more
detailed information in the attached file).

Best regards,
Tilman Rassy
History
Date User Action Args
2009-04-01 23:47:39rassysetmessages: + msg1172
2009-03-30 04:15:20stephensetstatus: new -> committed
assignedto: stephen
messages: + msg1167
nosy: + stephen
2009-03-29 23:54:19rassycreate