From: Kazutoshi S. <k_s...@f2...> - 2007-04-30 16:52:20
|
Alan Ezust wrote: > On 4/30/07, Kazutoshi Satoda <k_s...@f2...> wrote: >> I think MiscUtilities.isBinary(Reader) should be deprecated. Binary >> detection can't be done for a Reader. One file can be looked like a >> binary in an encoding, but can be looked like a text in another >> encoding. It should be MiscUtilities.isBinary(InputStream), and should >> be widely customizable by user. Sorry for saying that without a patch. > > I'm not sure what you mean by "widely customizable by the user". Why would > the user need to customize how isBinary works? Sorry, that part might be wrong. It's enought if how jEdit say "a file is binary" is clear for users who use the option "Skip binary files". I thought about a file which looks a binary for a person but also looks a text for another person. For example, a text file encoded in UTF-32 looks a binary file for people who don't know UTF-32. But this problem is ... too difficult to be solved. And "Skip binary files" is an option. Then a clear specification is enough. > Nor do I fully understand why it has to be an InputStream, or why Reader > was > chosen in the first place. Matthieu, do you have comments about this? A Reader is made by a InputStream and an encoding. In general situation where binary detection is required, the encoding of the file is not known. Then I think isBinary(Reader) doesn't make sense unless it is used with autodetect() in jEdit. > Is this something you want to / plan to fix, or shall I open a ticket in > the > tracker? It could be a quick solution to remove the binary detection if there were not explicit request (clear requirement). -- k_satoda |