This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 126322

Summary:	I18N - diff window left side not show multibyte ok when project encoding is not that of users locale
Product:	versioncontrol	Reporter:	Ken Frank <kfrank>
Component:	Mercurial	Assignee:	issues@versioncontrol <issues>
Status:	VERIFIED FIXED
Severity:	blocker	Keywords:	I18N
Priority:	P2
Version:	6.x
Hardware:	Sun
OS:	All
Issue Type:	DEFECT	Exception Reporter:
Attachments:	image proposed patch

Description Ken Frank 2008-01-30 19:39:53 UTC

using pseudo localized netbeans

running in ja locale, solaris

1. project encoding - default is always utf-8 until user changes it

create java project
initialize hg repos of project
modify file by putting multibyte chars in it
update and commit
make another change to file
do a diff

as seen in attached gif, left side has incorect mbyte, right side shows it ok.

2. change project encoding of some other project to euc-jp, which for solaris
is the default encoding for the ja locale, in which one should be running nb
for this, then create another new project (do NOT reuse same project in #1)

do above steps; things look ok.


===> my guess is that the code is assuming the encoding is that of the
encoding of the locale, euc-jp, rather than the project encoding, utf-8
in this case, but could be any other encoding -- thus perhaps feq api needs
to be used.

===> question - was feq api and other encoding handling done for all parts
of the plugin as part of its development (feq is new for nb6) ?
and was it tested for all commands and menu items in which
a. multibyte was used in project name, paths and file contents ?

b. that project encoding might be - utf-8 or that of the locale user is in -
that is, dev and testing need to cover both cases


if not, can the code be reviewed to make sure its ok; we'd rather know about this
now rather than be testing on things that have not been yet implemented.

Comment 1 Ken Frank 2008-01-30 19:41:13 UTC

Created attachment 55788 [details]
image

Comment 2 Padraig Obriain 2008-01-31 11:57:30 UTC

feq api was not used.

Can you point us documentation for feq api and code which uses it in NetBeans?

Comment 3 Ken Frank 2008-01-31 16:33:01 UTC

developers in netbeans team of this project or other nb developers in
netbeans team can point to dev level information on it.

ken.frank@sun.com

Comment 4 Padraig Obriain 2008-02-06 10:58:11 UTC

feq - FileEncodingQuery

just search for it in other vcs (cvs, svn, lh) modules 
(Note from Tomas Stupka)

Comment 5 Padraig Obriain 2008-02-06 13:39:41 UTC

The only use of FileEncodingQuery I can find for cvs or subversion is in
ResolveConflictsExecutor.java.

Accordingly, I would also expect to see this problem in a subversion or cvs controlled project.
Is that so?

Comment 6 Ken Frank 2008-02-06 19:17:32 UTC

I don't see that problem using cvs doing similar steps.

ken.frank@sun.com

Comment 7 Ken Frank 2008-02-06 19:23:18 UTC

not seen using subversion on windows also.

ken.frank@sun.com

Comment 8 Padraig Obriain 2008-02-07 10:04:54 UTC

I need to reinstall with ja locale to determine whether the problem is with mercurial or the plugin.

I will revisit this next week.

Comment 9 Padraig Obriain 2008-02-13 08:13:26 UTC

I have installed ja locale on a Nevada 80 system.

Where will I find pseudo-localized netbeans?

Can you give me exact instructions on how to reproduce?
 For instance, I do not know how to specify a Japanese character or change project encoding.

Comment 10 Padraig Obriain 2008-02-13 10:07:28 UTC

Is this the same problem as described in http://www.netbeans.org/issues/show_bug.cgi?id=85257?

Comment 11 Tomas Stupka 2008-02-13 10:40:50 UTC

seems to be.

the root of the problem in svn was that the files shown in the diffviews left side was located somewhere on the disk
(/tmp/...) and wasn't belonging to the project. Now, the encoding for the right side editor pane is given by the project
the file comes from while the left sides editor pane chooses a different encoding (whatever it may be:)). 

In case this also applies to mercurial then use the o.n.m.versioning.Utils.associateEncoding() api to set the same
encoding for the left sides file as the project locale file has.

the same for the diff bar embedded in the editor window.

Comment 12 Padraig Obriain 2008-02-13 11:11:19 UTC

Created attachment 56587 [details]
proposed patch

Comment 13 Padraig Obriain 2008-02-13 13:45:10 UTC

changeset:   67264:0bca79e3abb7
tag:         tip
user:        padraigob@netbeans.org
date:        Wed Feb 13 11:10:40 2008 +0000
files:       mercurial/src/org/netbeans/modules/mercurial/ui/diff/DiffStreamSource.java
description:
126322: Fix encoding for non-project file

Comment 14 Ken Frank 2008-02-13 15:51:59 UTC

it might be same as that issue, but don't know for sure
since don't know details of code changes or infrastructure
on that issue.

ken.frank@sun.com

Comment 15 Ken Frank 2008-03-06 18:59:49 UTC

verified using 0304 build on solaris, using both utf-8 and euc-jp project encodings.

ken.frank@sun.com