[wx-dev] #9555: regular expression search in wx.stc.StyledTextCtrl - incorrect highlighting for multibyte characters

[wxTrac]

Ticket URL: <http://trac.wxwidgets.org/ticket/9555>

#9555: regular expression search in wx.stc.StyledTextCtrl - incorrect highlighting
for multibyte characters
---------------------------------------------------------------+------------
 Reporter:  vbr                                                |       Owner:         
     Type:  defect                                             |      Status:  new    
 Priority:  normal                                             |   Milestone:         
Component:  wxPython                                           |     Version:  2.8.7.1
 Keywords:  stc, StyledTextCtrl, regular expressions, unicode  |   Blockedby:         
    Patch:  0                                                  |    Blocking:         
---------------------------------------------------------------+------------
 Hi all;
 While writing a simple text editor using wxpython, I encountered a
 surprising behaviour of the searching facility in the stc.StyledTextCtrl.

 It seems, that SearchPrev() and SearchNext() (and possibly other functions
 as well) with the flag wx.stc.STC_FIND_REGEXP don't handle the multibyte
 characters (non-asci) properly in some cases.
 It seems, that the characters over Basic Latin range (>127) are treated as
 of length 2, 3...
 E.g. if the search patern matches a single character (".", "[!^ ]" etc.),
 the search is ok for basic latin characters, but the displayed text is
 distorted, when the search encounters multibyte letters (probably a
 selection of some bytes across the actual characters is tried - an "error"
 square is displayed instead of some characters following the highlighted
 match).

 Equally a patern like ".." matches "aa" or "á";
 "..." matches "aaa" as well as "ậ" (ậ (dec.: 7853)  (hex.: 0x1ead) # LATIN
 SMALL LETTER A WITH CIRCUMFLEX AND DOT BELOW (Letter, Lowercase) (Latin
 Extended Additional))

 As I checked this, I found, that not only my realy simple app has this
 problem, but also much more advanced editors written in wxPython like
 UliPad or Editra.
 Is this a bug or some known peculiarity, which should be handled
 individually?
 (I use Python 2.5.2; wxPython 2.8.7.1 - unicode, WinXPh)

 Regards,
    Vlastimil Brom


--
Ticket URL: <http://trac.wxwidgets.org/ticket/9555>