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.
| Summary: | I18N - CVS diff encoding error | ||
|---|---|---|---|
| Product: | utilities | Reporter: | tetsu <tetsu> |
| Component: | Diff | Assignee: | diff-issues@utilities <diff-issues> |
| Status: | RESOLVED INVALID | ||
| Severity: | blocker | CC: | jf4jbug, kfrank |
| Priority: | P2 | Keywords: | I18N |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | Windows XP | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
screenshot
resolve window showing not ok mbyte in editor, not correct mbyte was inserted for reference, the correct mbyte in editor |
||
|
Description
tetsu
2008-03-16 03:12:40 UTC
marking as p2 since encoding issue. problem like this has been seen in the past, but had been fixed for that case. to issue filer tetsu: - if you don't do resolve conflicts, but just use diff menu choice while doing other editing, does the japanese characters show ok in left and right sides ? - if you have a separate, new project using win31j encoding, does same situation of this issue happen ? (you need to change project encoding in some other project to win31j, then create a new project; dont change encoding of your existing project and use that one for this experiment) ken.frank@sun.com dab320c96701 Maros, does the code for subversion, mercurial and clearcase need any changing also for this case ? Was it just related to resolve conflicts or to all diff viewing ? let me know if other issues are needed. ken.frank@sun.com The fix was for all of them. testsu, can you see if fix solves the problem you saw ? the location of build with fix is at http://bits.netbeans.org/netbeans/trunk/nightly/2008-03-25_13-01-24/ thanks. ken.frank@sun.com Sorry but not yet. More precisely part of resovled. I test using nightly building[1]. And found that the non-Enlish characters can be display partly. It seems that the coding is correct but font is not. Whatever, I attached a screenshot. You can understand it at first glance. [1]http://bits.netbeans.org/netbeans/trunk/nightly/2008-03-25_13-01-24/ Created attachment 59270 [details]
screenshot
tetsu: could you answer kfrank's questions? I cannot reproduce the issue in current trunk. About K Frank's question: - if you don't do resolve conflicts, but just use diff menu choice while doing other editing, does the japanese characters show ok in left and right sides ? Yes, japanese characters show ok. The characters only become unreadable when the "Accept/Accept & Next" button (in resolve conlicts windows) is clicked. - if you have a separate, new project using win31j encoding, does same situation of this issue happen ? Sorry, but I cannot finish this test. Because I am the only guy uses Netbeans in my team. And Eclipse does not support win31j encoding. So I cannot make conflicts on my own. I tried your "Accept/Accept Next" scenario but it still works for me. Sorry, but I tested on nightly build 200804010004 and still have this problem. One thing may be worth your attention is that my project is shared with Eclipse, which means other colleagues are using Eclipse while I'm using Netbeans to edit the same project. testsu, thanks for the additional comments. I am removing incomplete keyword. as to the eclipse sharing, does the problem happen for you if its only your own files in netbeans, using the utf-8 encoding of project (and I am assuming the characters used in your project are all utf-8 enc also ?) ? if its that others files are in the project files maybe it could be that those might be in some other encoding ? but I guess not since all other parts show the characters ok. ken.frank@sun.om the problem is seen. using solaris, in ja euc-jp locale but using default utf-8 project encodings. 1. create java project and put under cvs. 2. create another repos for project using a different local directory. 3. both projects are shown in ide explorer 4. change a line in first project file and commit - use multibyte characters. 5. change a line in second project, same file, same line, different mbyte characters and update 6. get the resolve conflicts message. 7. choose resolve conflicts and that window appears. 8. the mbyte is not correct in both windows - see attached. (another attached gif shows the source file with correct looking mbyte for reference) 9. resolve anyway and the incorrect mbyte is saved into the java file. (see another attached gif) I think it can be good if this is fixed in the first patch for 6.1 ken.frank@sun.com Created attachment 60100 [details]
resolve window showing not ok mbyte
Created attachment 60101 [details]
in editor, not correct mbyte was inserted
Created attachment 60102 [details]
for reference, the correct mbyte in editor
please review encoding handling of other such resolve or diff windows for cvs, hg and subversion modules to see if changes/fixes might be needed for those in context of this situation. using java projects with euc-jp project encoding, and same steps as below recent comments, the mbyte shows ok in resolve conflicts windows and in editor after accepting the resolve choice. thus it could be assumption of encoding to be used; perhaps in problem case, its using encoding of the locale user is in vs the project encoding since they are different there (euc-jp encoding of locale but utf-8 of project) but in this case here they are the same (euc-jp of locale and euc-jp of project) ken.frank@sun.com any update on if this can be fixed for first 6.1 patch ? ken.frank@sun.com No, we do not plan to do a patch for 6.1. I cannot reproduce it in current trunk. Without requested information for long time - INVALID. We can't do anything in this case, so please reporter add requested information and reopen issue. Thanks in advance. |