[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs misbehaves without --unibyte
From: |
Eli Zaretskii |
Subject: |
Re: emacs misbehaves without --unibyte |
Date: |
Wed, 29 May 2002 09:23:11 +0300 (IDT) |
On Wed, 29 May 2002, Paul Stoeber wrote:
> (How is Emacs not a binary file editor when it has hexl mode?)
It's not a binary file editor if you are in a mode other than hexl.
> I started this thread because default emacs wouldn't let me navigate
> filesystems that contain funny filenames, so the "8-bit cleanness"
> discussion only applies to file name handling (although I had also
> mentioned "text/binary files" in a general statement).
For that, Miles gave the solution: you should set up your language
environment correctly, or set file-name-coding-system explicitly.
I replied in addition to what Miles said, thinking that you really meant
8-bit cleanliness throughout.
> Is it reasonable
> for Emacs to refuse to open existing files and to invent new file names
> in place of existing ones?
No. But the ``reasonable'' thing is hard to implement without hints from
the user's environment. Please remember that Emacs decides where a file
name starts and ends in the Dired buffer by using a set of convoluted
regexps designed to parse the "ls -la" output for file's name, date,
time, attributes, etc. A stray 8-bit byte can cause spurious wrong
matches of those regexps, and the net effect is what you reported.