Bug 64139 - Implement a encoding detection
Summary: Implement a encoding detection
Status: RESOLVED DUPLICATE of bug 55355
Alias: None
Product: kate
Classification: Applications
Component: part (show other bugs)
Version: unspecified
Platform: Mandrake RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-12 14:18 UTC by de-chalendarg
Modified: 2003-12-17 23:55 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description de-chalendarg 2003-09-12 14:18:01 UTC
Version:            (using KDE KDE 3.1.3)
Installed from:    Mandrake RPMs
OS:          Linux

[This is quite similar to the closed bug 40813 but different and needs a fix I think, so I open a new bug report.
I saw a comment on another bug saying that the encodings support was quite better in 3.2. I could not test this.]

When an UTF-16 file is opened from the command line, the encoding is detected OK. But:
1. the BOM is kept in the output
    -> I would like the BOM to be hidden
2. the file is then saved with the default encoding
   -> I would like either the file t be saved with the original encoding (UTF-16 here) or to be asked what to choose by a dialog. Loosing the encoding is a bad thing for me
Comment 1 Christoph Cullmann 2003-09-12 23:49:37 UTC
1. we write to the file with disabled unicode header I think 
2. that is the current default behaviour, save the file in the encoding it was opened with 
 
(both points means current state of kde cvs head) 
Comment 2 Christoph Cullmann 2003-09-13 12:22:31 UTC
could somebody retest that, not that the problem is still there, want to have that really 
fixed for 3.2 if there is still some issue in cvs 
Comment 3 Ga 2003-09-15 08:41:47 UTC
Subject: Re:  kate should by default use the encoding of the
	current document to save it

OK. I will try to install 3.2 CVS at home the more quickly I can.
Thanks.

Ga
Comment 4 de-chalendarg 2003-09-17 09:00:08 UTC
Tried with KDE3.2 alpha1 (built with konstruct). The problem is still there. 
Here my test procedure: 
- write a file in iso-latin-1 (test.txt) 
- convert it to UTF-16: recode latin1..utf16 test.txt 
- look at it : UTF-16 
- open the file with kate 
- make a modification 
- save it 
- look at it: latin-1 
 
Will try with CVS if nobody else does it ; But I'd like not to have to do that. 
I'd love to use kate inside of jedit for my UTF-16 files. 
 
Thanks 
 
Ga
Comment 5 Christoph Cullmann 2003-09-17 23:30:30 UTC
? how should kate know that it is utf16 
do you tell kate that in the filedialog or do you have set utf16 as default encoding ? 
Comment 6 de-chalendarg 2003-10-01 22:18:16 UTC
I tried with the KDE CVS of 09/27 and the problem is still there, reproducible by the 
manipulation described above. 
 
I tried to look at the code, but with no hint, I was not able to find exactly where to 
look at.... Where is the content of the file first accessed ? That could enable to add a 
check of the byte order marker and eventually call the QT method that checks if an 
encoding is valid for a stream (don't remember its name right now). 
 
Ga
Comment 7 Christoph Cullmann 2003-10-08 18:10:47 UTC
the problem is that the user not always want that, would need some message box 
which asks the user if he really wants the detected stuff, the place to add that is in 
katebuffer::openFile () or katedocument::openFile 
Comment 8 Christoph Cullmann 2003-12-17 23:53:09 UTC
add this to the wishs
Comment 9 Christoph Cullmann 2003-12-17 23:55:44 UTC

*** This bug has been marked as a duplicate of 55355 ***