Hrvoje> It sounds like in one case you get the "file coding" Hrvoje> feature, whereas in the other case you don't. I'm not Hrvoje> sure why that would be the case. I don't see how it can possibly be the case, based on configure.in. The first times that the configure flags are tested is this: test -z "$with_mule" && with_mule=no test -z "$with_file_coding" && with_file_coding=no I'm assuming 21.4, here. file-coding is not optional in current 21.5. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

On Thu, Jan 29, 2004 at 03:29:35PM +0000, Uwe Brauer wrote: End-of-line type detection. Compressed/encrypted file support. That kind of things. Binaries destruction. OG.

On 29 Jan 2004, galibert(a)pobox.com wrote: ok But this is covered by the crypt package! Hm I will see how it interacts with the x-symbol package.

Hrvoje> Uwe Brauer <oub(a)mat.ucm.es&gt; writes: Hrvoje> Without Mule it's AFAIK only used for autodetection of Hrvoje> newlines, but there are other ways to do that. I'd stay Hrvoje> clear of "file coding" unless I had a good reason not to. Uh, there's no way to turn it off in 21.5. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

On 29 Jan 2004, stephen(a)xemacs.org wrote: Ups, you mean no way to turn off file coding or mule? If it is the later, please no this cannot be true.

On 29 Jan 2004, stephen(a)xemacs.org wrote: I agree. And this brings me to another issue we discussed years ago: are there any plans of BIDI support? GNU EMACS will now have it, I think the testing phase is advanced. All I am asking is to keep the --with-mule=no option. Years ago, when RMS decided to put mule into GNU emacs, he did not offer such an option and since this early releases screwed up a lot especially mails, he scared people and some changed to Xemacs. Ups I do not maintain x-symbol, this is Christoph's Wedler excellent brainchild.

Uwe> My question is then, what is this feature good for, Uwe> especially if mule is off? It's called the "file coding" feature because it is a minimal abstraction of Mule coding systems. Ie, it looks at the stream of bytes as they go into the buffer, and does _nothing_. In fact, it doesn't do absolutely nothing. It checks for occurances of the characters or pairs CR, CRLF, and LF, and if one of them predominates (I think the criterion is all of the linebreaks in the first 3000 characters use that convention), then the file is judged to be a Mac, DOS/Windows, or Unix text file, respectively. There are also checks for things like excessively long lines and too many non-whitespace control characters, which will automatically kick the file into "binary" mode. If the file appears to use the Mac convention, then CR->LF conversion is done on input and LF->CR on output. If the file appears to use the Windows convention, then the conversions are CRLF<->LF. If the file appears to be from Unix, then no conversion is done, and the buffer representation is the same as the external file. Uwe> And what sort of harm can be done with the feature enabled? If the file contains the other sort of control characters, then data corruption can occur. Eg, if this file is detected as Windows This is a single line<LF>containing a control character.<CRLF> it will be represented in the buffer as This is a single line<LF>containing a control character.<LF> and converted to This is a single line<CRLF>containing a control character.<CRLF> on output. Unlike Mule, this kind of error is extremely rare because of the stringent requirement that only one of the various conventions occur in the first 3000 characters. Also, if you exchange files with someone who uses a different kind of system, you can get confused because XEmacs will always present you with something that looks like ordinary text, but your correspondent may use an editor that can't handle it. Some people prefer to edit DOS files with a "^M" indicator at the end of every line. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Uwe> I try to talk to the debian package manager and ask him about Uwe> his reasons. That's simple. More Debian users exchange files with Windows systems than edit "binary" files that look like text. Most people only edit text files, and they consider files with embedded control characters other than tabs and whatever the system newline convention is to be already corrupted. The defaults are set up for "most people." If you want to turn it off personally at runtime, you just do (setq file-coding-system-alist '(("" . binary))) in your init file. But all you're really doing by turning off file-coding or mule is guaranteeing that the large set of users who need/want mule or file-coding will never be able to rely on x-symbol, and you won't be able to support them. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Hrvoje Niksic writes: [snip] [snip] The question is, are the binaries different in these two cases. I had very bad experience with mule, especially in connection with the x-symbol-package: the coding got complete screwed up. This is why I really want a mule free xemacs. If it would be only semi-free I would like to know. Now in the official debian packages the mule free xemacs is compiled without any option and therefore it seems the "file coding" feature is included. I think it is of general interest to know what the mulefree version with the "file coding" feature contains.