From: SourceForge.net <no...@so...> - 2007-05-09 18:06:06
|
Patches item #1715109, was opened at 2007-05-08 18:31 Message generated for change (Comment added) made by kpouer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1715109&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kazutoshi Satoda (k_satoda) Assigned to: Nobody/Anonymous (nobody) Summary: Feature proposal: Fallback encodings Initial Comment: I locally have a new feature which helps working with various encodings: the "fallback encodings". This feature allows users to tell jEdit what sequence of encodings should be tried when a load request is failed with encoding error. The trial-and-error cycle is automatically done in jEdit as a part of single load operation. This can be a very brilliant feature when a directory search is done for a large tree with mixed encodings. (More detailed description are below.) I'll upload my working (maybe incomplete) patch to this tracker item, and wait acceptance (setting the Resolution as Accepted) by one or more of other developers. If I got it, I'll commit the feature to the svn trunk. Any comments, reviews or advices are also welcome. More detail: At jEdit trunk r9513, if an user opens a file which is encoded in a non-default encoding, an error is reported and the request is aborted. The user is encouraged to use [Reload with Encoding] menu with another encoding. But if the user doesn't know what is the right encoding, some trial-and-error cycle will be required. Since typical users know only a few set of encodings, the sequence of encodings to try will be almost a fixed one. For example, Japanese Windows users (like me) can avoid almost all of encoding errors with the following sequence of encodings: [MS932 EUC-JP ISO-2022-JP UTF-8 windows-1252] I imagine Latin(?) people can be satisfied with the following one: [US-ASCII UTF-8 ISO-8859-1 windows-1252] Some encodings like windows-1252 accept almost arbitrary bytes without encoding error. Such encoding should be put at the last of the sequence. Stricter encoding should be put before others to make the feature effective. ---------------------------------------------------------------------- >Comment By: Matthieu Casanova (kpouer) Date: 2007-05-09 20:06 Message: Logged In: YES user_id=285591 Originator: NO Yes, my proposal is not a replacement for your feature, it is just another idea related with the encodings. Because when I want to switch encoding, it's boring to go through the 5 or 6 pages of encoding to find the 3 encodings I use ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2007-05-09 19:21 Message: Logged In: YES user_id=1483238 Originator: YES How are the selected favorite encodings ordered? Since the order of fallback encodings is very significant (see the bottom of the detail), unordered selections don't suit for this feature. ---------------------------------------------------------------------- Comment By: Matthieu Casanova (kpouer) Date: 2007-05-08 20:55 Message: Logged In: YES user_id=285591 Originator: NO I think the idea is good, and another one of this kind would be to have in the "reload with encoding" menu a small selection of the favorite encodings before having the entire list ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=1715109&group_id=588 |