[OS X Emacs] Re: Return of dired mode problems like in Aquaemacs 1.7

[Peter Dyballa]

Am 15.08.2009 um 14:12 schrieb David Reitter:

>> With
>>
>> export LANG=de_DE.ISO8859-15
>>
>> on a Mac (NS port), and a directory that contains a folder named  
>> "Tätää"(i.e. a German umlaut), viewing the directory with `dired'  
>> fails with an error message.

Interestingly this works with the X client version! The problem it  
has, is with the date of a file:

   -rw-r--r--    1 pete  admin    15421 29 Nov  2004  
EnvironmentVars.html
   -rw-r--r--    1 pete  admin    13601 16 M\344r  2005 Georgisch

The other problem is with displaying a directory or file name with  
umlaut in mode-line: instead of using the composed character from the  
font its constituents are taken from various fonts and thrown  
together...


Your problem in Emacs.app is easily reproduced by having a clean 7- 
bit directory with clean 7-bit files – and at least one entry with a  
date that has an umlaut, for example: Mär!

When LC_CTYPE and LANG are de_DE.UTF-8 then this month name does  
*not* produce an error:

   lrwxr-xr-x     1 root  admin       11  7 Mär 13:46 etc -> private/etc

After any error has occurred, this fine presentation is destroyed and  
we're back at M\344r!


When, in Emacs.app with LC_CTYPE and LANG set to de_DE.UTF-8, I visit  
from dired a directory with an umlaut I get:

Debugger entered--Lisp error: (error "File no longer exists; type `g'  
to update dired buffer")
   signal(error ("File no longer exists; type `g' to update dired  
buffer"))
   error("File no longer exists; type `g' to update dired buffer")
   dired-get-file-for-visit()
   dired-find-file()
   call-interactively(dired-find-file nil nil)

When I try to open a file in that directory (completely clean in name  
and date) I get:

Debugger entered--Lisp error: (file-error "Opening directory" "no  
such file or directory" "/Volumes/Halde/_gepr\x00fc\ ft/")
   signal(file-error ("Opening directory" "no such file or directory"  
"/Volumes/Halde/_gepr\x00fc\ ft/"))
   completion--some(#[(style) ......" [style completion-styles-alist  
string table pred point] 5] (basic partial-completion emacs22))
   completion-try-completion("/Volumes/Halde/_gepr\x00fc\ ft/yum"  
read-file-name-internal nil 27)
   completion--do-completion()
   minibuffer-complete()
   call-interactively(minibuffer-complete nil nil)
   completing-read("Find file: " read-file-name-internal nil confirm- 
after-completion "~/" file-name-history "~/")
   read-file-name("Find file: " nil "~/" confirm-after-completion)
   find-file-read-args("Find file: " confirm-after-completion)
   byte-code("\300\301\302 \"\207" [find-file-read-args "Find file: "  
confirm-nonexistent-file-or-buffer] 3)
   call-interactively(find-file nil nil)

In the X client variants of GNU Emacs 22.3 and 23.1.50 I have no such  
problems with this clean file in that dirty directory. There is also  
a difference in behaviour of *shell* buffers: in Emacs.app neither  
Apple's ls nor GNU ls can display the contents of this directory:

pete 378 /\ /bin/ls -wl /Volumes/Halde/_geprüft
ls: /Volumes/Halde/_geprüft: No such file or directory
Exit 1
pete 379 /\ /sw/bin/gls -Nl --color=always  /Volumes/Halde/_geprüft
/sw/bin/gls: Zugriff auf /Volumes/Halde/_geprüft nicht möglich: No  
such file or directory
Exit 2

In Terminal both work, it's only a bit strange how this directory is  
displayed: /Volumes/Halde/_gepru?^?ft...

--
Mit friedvollen Grüßen

   Pete

Theoretischer Unterbau, der:
Aussage über einen Teil einer Fernsehansagerin