After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 355477 - Snippet Plugin: Multibyte Charactors As $GEDIT_BASENAME Not Displayed Correctly
Snippet Plugin: Multibyte Charactors As $GEDIT_BASENAME Not Displayed Correctly
Status: RESOLVED FIXED
Product: gedit-plugins
Classification: Other
Component: General
2.14.x
Other All
: Normal normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2006-09-11 19:24 UTC by Satoshi Tanabe
Modified: 2019-03-23 20:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Fix format uri for display (3.40 KB, patch)
2006-09-23 16:14 UTC, jessevdk@gmail.com
none Details | Review
Fix basename envvar (618 bytes, patch)
2006-11-13 11:46 UTC, jessevdk@gmail.com
none Details | Review

Description Satoshi Tanabe 2006-09-11 19:24:24 UTC
Please describe the problem:
When I use multibyte letters as $GEDIT_BASENAME (in my case, Japanese) in Snippet plugin, a series of hexadecimal numbers (e.g. %E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E5%90%8D) is displayed when I use the Snippet.

$GEDIT_FILENAME works just fine.

Steps to reproduce:
1. Open Gedit
2. Add a Snippet that contains $GEDIT_BASENAME
3. Save a file in multibyte letters (e.g. "ファイル名" ("filename" in Japanese))
4. Use the Snippet


Actual results:
In the case above, "%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E5%90%8D", not "ファイル名", is displayed.

When I use $GEDIT_FILENAME, "/home/username/Desktop/ファイル名" is displayed just right.

Expected results:
"ファイル名" is displayed.

Does this happen every time?
Yes.

Other information:
Comment 1 jessevdk@gmail.com 2006-09-12 21:30:06 UTC
I've been looking in to the problem and I think I know how to properly fix it. But there also seems to be a bit of a problem in gnomevfs which causes the uri not to be converted to utf-8 properly for remote schemes (Not sure what version of gedit/gnomevfs you're using, but have a look at the tooltip of the document on the  notebook tab). We're working at solving the problem asap.
Comment 2 Satoshi Tanabe 2006-09-13 20:47:33 UTC
Thanks for your reply. It seems I'm using the following versions on Fedora Core 5:

- gnome-vfs2 2.14.2-1 (not sure this is what you meant by "gnomevfs")
- gedit 2.14.3

Keep up the great work!
Comment 3 jessevdk@gmail.com 2006-09-23 16:14:05 UTC
Created attachment 73284 [details] [review]
Fix format uri for display

This patch adds functionality to gedit_utils_format_uri_for_display to manually try to unescape remote uri's testing it for valid utf-8. I'm not sure from what encodings to try to convert from (what does windows use?) from. Currently it first checks if it's already valid utf-8 (after unescaping) and if not it tries to convert from ISO-8859-15.
Comment 4 Satoshi Tanabe 2006-09-25 22:41:14 UTC
I just want to add that the same thing happened with $GEDIT_CURRENT_DOCUMENT_NAME in the external tools plugin ($GEDIT_CURRENT_DOCUMENT_PATH worked fine).

http://live.gnome.org/Gedit/ToolLauncherPlugin
Comment 5 jessevdk@gmail.com 2006-11-13 11:46:44 UTC
Created attachment 76472 [details] [review]
Fix basename envvar

Now that gedit utils is fixed (and therefore uri_for_display on gedit.Doc), we can fix this issue by the proposed patch, any comments?
Comment 6 jessevdk@gmail.com 2006-11-13 15:06:02 UTC
Fixed in HEAD