Re: emacs misbehaves without --unibyte

[Paul Stoeber]

On Wed, 29 May 2002, Paul Stoeber wrote:
> If you simply want to use dired as a robust filesystem browser
> (like bash, only more comfortable), regardless of your language
> or the language of who created the files, then
> 
>       (setq file-name-coding-system 'no-conversion)
> 
> seems to be a solution.

Alas, this is no longer true:

q@xyz:~$ mkdir -p $'\340/\350'
q@xyz:~$ echo XXX > $'\340/\350/x'
q@xyz:~$ /e/bin/emacs --eval "(progn (setq file-name-coding-system 
'no-conversion) (dired \"~/\"))"

Go to \340.  RET.  Works.  Go to \350.  RET.
"File no longer exists; type `g' to update Dired buffer".

Again, --unibyte fixes this, even when not setting file-name-coding-system.

Emacs docs:
        dired-listing-switches's value is "-al"

        Documentation:
        *Switches passed to `ls' for dired.  MUST contain the `l' option.
        May contain all other options that don't contradict `-l';
        may contain even `F', `b', `i' and `s'.  See also the variable
        `dired-ls-F-marks-symlinks' concerning the `F' switch.

This looks very promising, especially the `b' option.

After

        (setq dired-listing-switches "-alb")

, not using --unibyte, the above bug (changing into \340 but not \350) still
happens, but dired will correctly open the files $'a\340b' and even $'a\nb'
(filename with a newline in it.  and C-x C-s will even write to the correct
file).

So, using the `b' option of ls seems to be the right
way to go for robustness, but the `b' support is still buggy:
dired won't open files with spaces in their name (for example

q@xyz:~$ echo XXX > 'a b'

). It says "File no longer exists; type `g' to update Dired buffer",
and of course *that* is not fixed by --unibyte.

When using the `b' option, dired-do-shell-command passes some filenames
incorrectly to the program: 'a b' and $'a\nb' are both passed as
'ab', but $'a\tb' and $'a\340b' are passed correctly (without --unibyte).