Ticket #72 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

Sub name navigation and text searching broken for UTF8-containing files

Reported by: patspam Owned by:
Priority: major Milestone:
Component: editor Version:
Keywords: Cc: dam@…

Description

Clicking on sub name in right panel sub list generates the following error to STDERR:

(padre:7916): Gtk-WARNING : /build/buildd/gtk+2.0-2.12.9/gtk/gtkwidget.c:8547: widget class GtkPizza' has no property named row-ending-details'

mmmmm Pizza...

Revision: 250
Running on Ubuntu 8.04 with system perl.

Attachments

test.pl (248 bytes) - added by dam 5 years ago.

Change History

comment:1 Changed 6 years ago by szabgab

It's working for me on Ubuntu 8.04 with system perl using

Wx 0.84 and
Alien::wxWidgets 0.35_01

Which version of Wx and Alien::wxWidgets do you have?

comment:2 Changed 6 years ago by szabgab

  • Status changed from new to closed
  • Resolution set to not a bug

could not reproduce

comment:3 Changed 5 years ago by dam

  • Cc dam@… added
  • Status changed from closed to reopened
  • Resolution not a bug deleted
  • Summary changed from Sub name navigation broken to Sub name navigation and text searching broken

I can reproduce it. The Find dialog also cannot find anything (like sub some) -- marks some irrelevant text pages away from the definition of function some.

Wx Version: 0.86 wxWidgets 2.8.7
Alien::wxWidgets 0.41

The script I am experiencing the bug with contains UTF8-encoded text (in perl comments).

No warnings on the terminal.

comment:4 Changed 5 years ago by dam

Trying text search and function definition location on a plain ASCII file works. There must be something wrong with the handling of wide characters.

For example if I have the line

# © 2008

and place the caret right after the ©, the information in the bottom right states L: 3 Ch: 4 while it should state Ch: 3.

Seems like it counts bytes, not characters.

Yes, if I search for a text that is before the first UTF8 character, it works. If I search for something after the ©, it sort of works too, but the text marked as found is shifted one character to the left from the actual match.

comment:5 follow-up: ↓ 6 Changed 5 years ago by szabgab

can you please try it on a version checked out from SVN?
There was some UTF-8 related fix but I am not sure if it works well.
Alternatively, I'd appreciate if you could send a small file that shows
the problem.

Changed 5 years ago by dam

comment:6 in reply to: ↑ 5 Changed 5 years ago by dam

  • Summary changed from Sub name navigation and text searching broken to Sub name navigation and text searching broken for UTF8-containing files

Replying to szabgab:

can you please try it on a version checked out from SVN?

Applying the patch in r553 to 0.14 didn't help

There was some UTF-8 related fix but I am not sure if it works well.
Alternatively, I'd appreciate if you could send a small file that shows
the problem.

See the attached test.pl. Open it in padre and double-click on the test function or try finding something after the Cyrillic text.

comment:7 follow-up: ↓ 8 Changed 5 years ago by szabgab

r1561 makes this working but I am not sure if this is the right solution

comment:8 in reply to: ↑ 7 Changed 5 years ago by dam

Replying to szabgab:

r1561 makes this working but I am not sure if this is the right solution

Recoding the whole file on each search certainly doesn't feel right :)

I don't know any Wx foo, but can't Wx-Perl work with Perl's (is_utf8 == true) strings?

I mean, give an utf8-aware string to the text control and later when you find that the search matched 40th character tell Wx to focus on that, no matter that it is really at 50th byte.

Sorry if this is completely off-track...

comment:9 Changed 5 years ago by szabgab

  • Status changed from reopened to closed
  • Resolution set to fixed

works well for me on Ubuntu 9.04 and Padre 0.38 r5770, please reopen if it does not work on your system

Note: See TracTickets for help on using tickets.