Dired confused by filenames starting with date-like strings

Dired confused by filenames starting with date-like strings

[kg6mar]

Dired gets confused by certain filenames in which the beginning
resembles a date and there is an embedded space (my photograph naming
convention).  It fails to assemble the entire filename.

Example:

-rw-rw-rw-   1 John     root  1113559 Oct 12  2005 04 Project - Front
caulking.JPG
-r--r--r--   1 John     root  1924322 Sep  5  2005 2005-09-05 002.JPG

Dired correctly interprets the first filename as "04 Project - Front
caulking.JPG" but incorrectly thinks that the second file is named
"002.JPG" instead of "2005-09-05 002.JPG"

The behavior manifests itself in operations like Copy and Rename.

I googled my way to looking at dired-move-to-filename-regexp, but its
value is very complex relative to my regexp skill, and anything I do to
it will likely have unintended consequences.  (Adding the -b flag to
dired-listing-switches did nothing.)

I'm going to dig into it the best I can, but I also want to put it out
here and see if someone else has been here before.

Emacs-version's value is "21.3.1"  Operating system is Windows XP.

I'd rather not rename all my photographs (well, actually, I do, and
that's how I discovered this).

Thanks, and hail Emacs

-- John

Re: Dired confused by filenames starting with date-like strings

[Miles Bader]

kg6mar@gmail.com writes:
> Dired gets confused by certain filenames in which the beginning
> resembles a date and there is an embedded space (my photograph naming
> convention).  It fails to assemble the entire filename.

This works correctly on my system, because dired invokes ls with the
"--dired" option (a feature of GNU ls, which causes ls to output extra
information about where the names are located).

The variable `dired-use-ls-dired' controls whether dired does this or
not.  So to fix this problem, try installing GNU ls (I guess that means
cygwin, as you're on ms-windows?) and setting dired-use-ls-dired to t.

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: Dired confused by filenames starting with date-like strings

[Peter Dyballa]

Am 24.08.2006 um 00:17 schrieb Miles Bader:

> This works correctly on my system, because dired invokes ls with the
> "--dired" option (a feature of GNU ls, which causes ls to output extra
> information about where the names are located).
>
> The variable `dired-use-ls-dired' controls whether dired does this or
> not.

When I do

	(setq dired-use-ls-dired "/sw/bin/gls --dired")

(with or without "/sw/bin/") and then open a directory in dired-mode,  
my GNU Emacsen 22.0.50 and 23.0.0 tell me:

	Debugger entered--Lisp error: (error "Listing directory failed but  
`access-file' worked")
	  signal(error ("Listing directory failed but `access-file' worked"))
	  error("Listing directory failed but `access-file' worked")
	  insert-directory("/Users/pete/" "--dired -al" nil t)
	  dired-insert-directory("/Users/pete/" "-al" nil nil t)
	  dired-readin-insert()
	  dired-readin()
	  dired-internal-noselect("~/" nil)
	  dired-noselect("~/" nil)
	  dired("~/" nil)
	  call-interactively(dired)

and no listing.

--
Greetings

   Pete

Without vi there is only GNU Emacs

Re: Dired confused by filenames starting with date-like strings

[Kevin Rodgers]

Peter Dyballa wrote:
> 
> Am 24.08.2006 um 00:17 schrieb Miles Bader:
> 
>> This works correctly on my system, because dired invokes ls with the
>> "--dired" option (a feature of GNU ls, which causes ls to output extra
>> information about where the names are located).
>>
>> The variable `dired-use-ls-dired' controls whether dired does this or
>> not.
> 
> When I do
> 
>     (setq dired-use-ls-dired "/sw/bin/gls --dired")
> 
> (with or without "/sw/bin/") and then open a directory in dired-mode, my 
> GNU Emacsen 22.0.50 and 23.0.0 tell me:
> 
>     Debugger entered--Lisp error: (error "Listing directory failed but 
> `access-file' worked")
>       signal(error ("Listing directory failed but `access-file' worked"))
>       error("Listing directory failed but `access-file' worked")
>       insert-directory("/Users/pete/" "--dired -al" nil t)
>       dired-insert-directory("/Users/pete/" "-al" nil nil t)
>       dired-readin-insert()
>       dired-readin()
>       dired-internal-noselect("~/" nil)
>       dired-noselect("~/" nil)
>       dired("~/" nil)
>       call-interactively(dired)
> 
> and no listing.

There is no reason to set dired-use-ls-dired to anything but t or nil.
In particular, it does not determine which ls program is run.  Try:

(setq insert-directory-program "/sw/bin/ls"
       dired-use-ls-dired t)

-- 
Kevin

Re: Dired confused by filenames starting with date-like strings

[Miles Bader]

Peter Dyballa <Peter_Dyballa@web.DE> writes:
> When I do
>
> 	(setq dired-use-ls-dired "/sw/bin/gls --dired")

`dired-use-ls-dired' is a boolean, which causes dired to append the
"--dired" option itself.

To tell dired what ls program to use, you have to use a separate
variable, `insert-directory-program'.

So I guess the following should work:

   (setq dired-use-ls-dired t)
   (setq insert-directory-program "/sw/bin/gls")

-Miles

-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Dired confused by filenames starting with date-like strings

[Peter Dyballa]

Am 24.08.2006 um 16:27 schrieb Kevin Rodgers:

> There is no reason to set dired-use-ls-dired to anything but t or nil.
> In particular, it does not determine which ls program is run.  Try:
>
> (setq insert-directory-program "/sw/bin/ls"
>       dired-use-ls-dired t)

Am 24.08.2006 um 16:35 schrieb Miles Bader:

> So I guess the following should work:
>
>    (setq dired-use-ls-dired t)
>    (setq insert-directory-program "/sw/bin/gls")


Oh, yes, these work! Thank you! There isn't much difference compared  
to using Apple's ls; in GNU Emacs 22.0.50 UTF-8 characters are still  
displayed as a series of UTF-8 octets, and in GNU Emacs 23.0.0 I  
still cannot search for file names with German umlauts etc.

Hopefully others have more success!

--
Greetings

   Pete

  "A designer knows he has arrived at perfection not when there is no  
longer anything to add, but when there is no longer anything to take  
away."
                                  -- Antoine de Saint-Exupéry

Dired doesn't decode UTF-8 file names (was: Dired confused by filenames starting with date-like strings)

[Kevin Rodgers]

Peter Dyballa wrote:
> 
> Am 24.08.2006 um 16:27 schrieb Kevin Rodgers:
> 
>> There is no reason to set dired-use-ls-dired to anything but t or nil.
>> In particular, it does not determine which ls program is run.  Try:
>>
>> (setq insert-directory-program "/sw/bin/ls"
>>       dired-use-ls-dired t)
> 
> Am 24.08.2006 um 16:35 schrieb Miles Bader:
> 
>> So I guess the following should work:
>>
>>    (setq dired-use-ls-dired t)
>>    (setq insert-directory-program "/sw/bin/gls")
> 
> 
> Oh, yes, these work! Thank you! There isn't much difference compared to 
> using Apple's ls; in GNU Emacs 22.0.50 UTF-8 characters are still 
> displayed as a series of UTF-8 octets, and in GNU Emacs 23.0.0 I still 
> cannot search for file names with German umlauts etc.

That is the first mention of UTF-8 in this thread.  Mile suggested using
GNU ls --dired to solve the OP's problem with date-like filenames.

Is file-name-coding-system (or default-file-name-coding-system) set
to utf-8?  Should it be?

Is there an entry in process-coding-system-alist for ls?  Should there
be?

-- 
Kevin

Re: Dired confused by filenames starting with date-like strings

[kg6mar]

Miles Bader wrote:
> kg6mar@gmail.com writes:
> > Dired gets confused by certain filenames in which the beginning
> > resembles a date and there is an embedded space (my photograph naming
> > convention).  It fails to assemble the entire filename.
>
> This works correctly on my system, because dired invokes ls with the
> "--dired" option (a feature of GNU ls, which causes ls to output extra
> information about where the names are located).
>
> The variable `dired-use-ls-dired' controls whether dired does this or
> not.  So to fix this problem, try installing GNU ls (I guess that means
> cygwin, as you're on ms-windows?) and setting dired-use-ls-dired to t.

After more testing and advice-following, it still appears to me that ls
is working as required, but dired can't parse this particular filename
correctly from the ls output.  It sounds as if it works on a Unix or
linux emacs implementation but not Windows.

- Emacs 21.3.1 for Windows doesn't appear to have a variable called
dired-use-ls-dired, but I can set dired-listing-switches to "-lD" which
invokes the ls --dired option, achieving the same purpose.

-  I verified that I'm using cygwin's ls.  I tried the --dired option
suggested here, with no different final result.

I tested some more filenames.  Of the following, the only one dired
can't Copy or Rename correctly is the last (which it takes to be
foo.txt).  Again, the problematic name begins with a string that looks
like a date, and has a space after that.  These are cut and pasted from
dired:


-rw-rw-rw-   1 John     root      3 Aug 23 19:34 2006-08-23.txt
-rw-rw-rw-   1 John     root      3 Aug 23 19:34 2006-08-23foo.txt
-rw-rw-rw-   1 John     root      3 Aug 23 19:34 foo 2006-08-23 foo.txt
-rw-rw-rw-   1 John     root      3 Aug 23 19:34 2006-08-23 foo.txt

I appreciate your thinking here.

-- John

Re: Dired doesn't decode UTF-8 file names (was: Dired confused by filenames starting with date-like strings)

[Peter Dyballa]

Am 24.08.2006 um 18:12 schrieb Kevin Rodgers:

> Peter Dyballa wrote:
>> Am 24.08.2006 um 16:27 schrieb Kevin Rodgers:
>>> There is no reason to set dired-use-ls-dired to anything but t or  
>>> nil.
>>> In particular, it does not determine which ls program is run.  Try:
>>>
>>> (setq insert-directory-program "/sw/bin/ls"
>>>       dired-use-ls-dired t)
>> Am 24.08.2006 um 16:35 schrieb Miles Bader:
>>> So I guess the following should work:
>>>
>>>    (setq dired-use-ls-dired t)
>>>    (setq insert-directory-program "/sw/bin/gls")
>> Oh, yes, these work! Thank you! There isn't much difference  
>> compared to using Apple's ls; in GNU Emacs 22.0.50 UTF-8  
>> characters are still displayed as a series of UTF-8 octets, and in  
>> GNU Emacs 23.0.0 I still cannot search for file names with German  
>> umlauts etc.
>
> That is the first mention of UTF-8 in this thread.  Mile suggested  
> using
> GNU ls --dired to solve the OP's problem with date-like filenames.

I remember Miles Bader mentioned some time before that GNU ls could  
solve UTF-8 problems. Then it did not work, for me, so I thought,  
hoped, that now, with 'dired extra switches' it could work better. I  
have problems with non-7 bit US-ASCII characters in the file name and  
in the abbreviated month name (Mär, for March) – at least this one  
*is* solved (3 Mär 13:39 => 2006-03-03 13:39).

>
> Is file-name-coding-system (or default-file-name-coding-system) set
> to utf-8?

No, it is iso-latin-1! Although my language environment in shell is  
set to UTF-8, as it is for GNU Emacs 23.

File-name-coding-system is nil, so default-file-name-coding-system  
should be used, according to the documentation. But – it's still iso- 
latin-1! Ah, here is a difference: it *came* from  '(current-language- 
environment "UTF-8") in the customisation section! (I warned about  
its use, but had it myself still set! Arghh!!!)

>   Should it be?

Yes, it should! The abbreviated month's name is now correctly  
displayed! GNU Emacs 22.0.50 still has problems: German umlauts in  
file names are displayed as [AOUaou]¨ and because ¨ is not found in  
the fontset I see after each vowel an empty box. The same is true for  
other accented characters in file names. GNU ls and Apple ls show no  
difference.

Launching GNU Emacs 22.0.50 in Terminal with no windows the de- 
composed UTF-8 characters are composed correctly!

>
> Is there an entry in process-coding-system-alist for ls?  Should there
> be?

Not directly ...

	(("\\*shell\\*\\'" utf-8 . utf-8)
	 ("\\*.* output\\*\\'" iso-8859-15-unix . iso-8859-15-unix))

The second line is meant for AUCTeX output buffers (although not  
really working, probably I have to find some hook). Is there really  
more needed?

--
Greetings

   Pete

"Let's face it; we don't want a free market economy either."
         James Farley, president, Coca-Cola Export Corp., 1959

Re: Dired confused by filenames starting with date-like strings

[Jesse Alama]

Miles Bader <miles@gnu.org> writes:

> kg6mar@gmail.com writes:
>> Dired gets confused by certain filenames in which the beginning
>> resembles a date and there is an embedded space (my photograph naming
>> convention).  It fails to assemble the entire filename.
>
> This works correctly on my system, because dired invokes ls with the
> "--dired" option (a feature of GNU ls, which causes ls to output extra
> information about where the names are located).
>
> The variable `dired-use-ls-dired' controls whether dired does this or
> not.  So to fix this problem, try installing GNU ls (I guess that means
> cygwin, as you're on ms-windows?) and setting dired-use-ls-dired to t.

After following this discussion I wanted to set this variable to `t'.
I didn't want to use `setq' to I tried setting the variable using
cusomize-variable.  But I see in dired.el that dired-use-ls-dired is
defined as follows:

(defvar dired-use-ls-dired (not (not (string-match "gnu" system-configuration)))
  "Non-nil means Dired should use `ls --dired'.")

Would anything go wrong if this variable were customizable?

Jesse

-- 
Jesse Alama (alama@stanford.edu)

Re: Dired confused by filenames starting with date-like strings

[Eli Zaretskii]

> From: kg6mar@gmail.com
> Newsgroups: gnu.emacs.help
> Date: 24 Aug 2006 10:43:26 -0700
> 
> > The variable `dired-use-ls-dired' controls whether dired does this or
> > not.  So to fix this problem, try installing GNU ls (I guess that means
> > cygwin, as you're on ms-windows?) and setting dired-use-ls-dired to t.
> 
> After more testing and advice-following, it still appears to me that ls
> is working as required, but dired can't parse this particular filename
> correctly from the ls output.  It sounds as if it works on a Unix or
> linux emacs implementation but not Windows.

Are you using the native Windows port of Emacs or the Cygwin port?
What does Emacs display when you type "M-x emacs-version RET"?

If you are using the native Windows port, Emacs does not use the
external `ls' program (because it's generally unavailable on Windows
machines).  Instead, it uses the `ls' emulation in Lisp; see
ls-lisp.el.

ls-lisp.el is preloaded into the native Windows port; to disable it
and force Emacs to use the external `ls' program, set the variable
`ls-lisp-use-insert-directory-program' to a non-nil value.

Re: Dired confused by filenames starting with date-like strings

[Miles Bader]

kg6mar@gmail.com writes:
> - Emacs 21.3.1 for Windows doesn't appear to have a variable called
> dired-use-ls-dired

Hmmm not sure if that change made it into any version of Emacs 21 --
`dired-use-ls-dired' was added to the development sources on 2002-09-14,
and Emacs 21.3 was released on 2003-03-24, but I think the later
releases of Emacs 21 were done from a special release branch which
didn't incorporate most trunk changes.

> but I can set dired-listing-switches to "-lD" which
> invokes the ls --dired option, achieving the same purpose.

It's not enough to just invoke ls --dired -- Emacs also has to correctly
deal with the special info which that command outputs, and I don't know
if dired did so before the change which added the dired-use-ls-dired
variable.

Incidentally, as Eli mentioned, on windows perhaps it should be using
the `ls-lisp.el' lisp implementation of ls -- which _does_ correctly
handle such weird filenames (it always adds the magic property which
dired needs to find things correctly).  But again, I'm not sure how this
stuff relates to older released versions of Emacs.

I think it would a decent idea to try upgrading to Emacs 22 -- it's not
officially released yet, but it's in quite good condition, and there are
precompiled windows binaries available (I forget the exact site, but
last time I looked it took about 30 seconds with google to find it).

-Miles

-- 
自らを空にして、心を開く時、道は開かれる

Re: Dired confused by filenames starting with date-like strings

[B. T. Raven]

"Eli Zaretskii" <eliz@gnu.org> wrote in message
news:mailman.5588.1156462534.9609.help-gnu-emacs@gnu.org...
> > From: kg6mar@gmail.com
> > Newsgroups: gnu.emacs.help
> > Date: 24 Aug 2006 10:43:26 -0700
> >
> > > The variable `dired-use-ls-dired' controls whether dired does this
or
> > > not.  So to fix this problem, try installing GNU ls (I guess that
means
> > > cygwin, as you're on ms-windows?) and setting dired-use-ls-dired to
t.
> >
> > After more testing and advice-following, it still appears to me that
ls
> > is working as required, but dired can't parse this particular filename
> > correctly from the ls output.  It sounds as if it works on a Unix or
> > linux emacs implementation but not Windows.
>
> Are you using the native Windows port of Emacs or the Cygwin port?
> What does Emacs display when you type "M-x emacs-version RET"?
>
> If you are using the native Windows port, Emacs does not use the
> external `ls' program (because it's generally unavailable on Windows
> machines).  Instead, it uses the `ls' emulation in Lisp; see
> ls-lisp.el.
>
> ls-lisp.el is preloaded into the native Windows port; to disable it
> and force Emacs to use the external `ls' program, set the variable
> `ls-lisp-use-insert-directory-program' to a non-nil value.
>
>

I have a similar setup to that of the OP and also have Cygwin installed
but I use the native windows port (21.3.1) except on msw98 rather than xp.
I don't think that emacs can "know" about cygwin unless I explicitly run a
command (program) like ls by going through M-!

M-! dir shows a listing like:

2006\ 08\ 23\ foo.txt  x-test\ test\ test
2006-08-23\ foo.txt    test\ test

M-! ls shows the same but without the backslash before the spaces.

This behavior isn't affected by the setting of
ls-lisp-use-insert-directory-program. With this set to t, it seems like
emacs should be using dir rather than ls. It doesn't know where to find
the ls.exe binary in cygwin.

Using %m in dired
[^ ]+_ [^ ]*
I get the following:

  drwxr-xr-x    2 youwho all             0 Aug 22 19:56 .
  drwxr-xr-x   54 youwho all           0 Dec 31  1969 ..
* -rw-r--r--    1 youwho all               0 Aug 25 16:57 2006 08 23
foo.txt
  -rw-r--r--    1 youwho all               0 Aug 25 16:57 2006-08-23
foo.txt
* -rw-r--r--    1 youwho all               0 Aug 25 17:23 5 002.JPG
* -rw-r--r--    1 youwho all             0 Aug 25 18:19 b-b-b test
 ...
* -rw-r--r--    1 youwho all           234 Aug 25 17:22 test test
* -rw-r--r--    1 youwho all               0 Aug 25 17:23 x 002.JPG
* -rw-r--r--    1 youwho all               0 Aug 25 17:20 x-test test test

4 filenames with 1 space, 1 with 2, 1 with 3. Only the one with numbers
delimited with dashes isn't marked.

Ed

Re: Dired confused by filenames starting with date-like strings

[Eli Zaretskii]

> From: "B. T. Raven" <ecinmn@alcisp.com>
> Newsgroups: gnu.emacs.help
> Date: Fri, 25 Aug 2006 18:28:15 -0500
> 
> This behavior isn't affected by the setting of
> ls-lisp-use-insert-directory-program. With this set to t, it seems like
> emacs should be using dir rather than ls. It doesn't know where to find
> the ls.exe binary in cygwin.

That's a different problem, and it has an easy solution: modify the
value of the Path environment variable so that it includes the Cygwin
bin/ directory.

Re: Dired confused by filenames starting with date-like strings

[B. T. Raven]

"Eli Zaretskii" <eliz@gnu.org> wrote in message
news:mailman.5676.1156594178.9609.help-gnu-emacs@gnu.org...
> > From: "B. T. Raven" <ecinmn@alcisp.com>
> > Newsgroups: gnu.emacs.help
> > Date: Fri, 25 Aug 2006 18:28:15 -0500
> >
> > This behavior isn't affected by the setting of
> > ls-lisp-use-insert-directory-program. With this set to t, it seems
like
> > emacs should be using dir rather than ls. It doesn't know where to
find
> > the ls.exe binary in cygwin.
>
> That's a different problem, and it has an easy solution: modify the
> value of the Path environment variable so that it includes the Cygwin
> bin/ directory.
>
>

I agree that dragging in the Cygwin emulator is a red herring, but that
still leaves the op's original question unanswered: are there any settings
in the w32 build of ver. 21.3.1 that will allow dired to work correctly
with files named like "nnnn-nn-nn xxx*" ?  From what has been said here so
far, it still looks like a bug.

Re: Dired confused by filenames starting with date-like strings

[Miles Bader]

"B. T. Raven" <ecinmn@alcisp.com> writes:
> still leaves the op's original question unanswered: are there any settings
> in the w32 build of ver. 21.3.1 that will allow dired to work correctly
> with files named like "nnnn-nn-nn xxx*" ?  From what has been said here so
> far, it still looks like a bug.

The fix is "upgrade to version 22".

-Miles

-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: Dired doesn't decode UTF-8 file names

[Kevin Rodgers]

Peter Dyballa wrote:
 >
 > Am 24.08.2006 um 18:12 schrieb Kevin Rodgers:
 >> Is there an entry in process-coding-system-alist for ls?  Should there
 >> be?
 >
 > Not directly ...
 >
 >     (("\\*shell\\*\\'" utf-8 . utf-8)
 >      ("\\*.* output\\*\\'" iso-8859-15-unix . iso-8859-15-unix))
 >
 > The second line is meant for AUCTeX output buffers (although not really
 > working, probably I have to find some hook). Is there really more needed?

That doesn't look right at all.  According to its doc string, the car of
the alist elements should be a regexp that matches a program name,
whereas your patterns look like they match buffer names.

-- 
Kevin

Re: Dired doesn't decode UTF-8 file names

[Peter Dyballa]

Am 28.08.2006 um 17:02 schrieb Kevin Rodgers:

> >     (("\\*shell\\*\\'" utf-8 . utf-8)
> >      ("\\*.* output\\*\\'" iso-8859-15-unix . iso-8859-15-unix))
> >
> > The second line is meant for AUCTeX output buffers (although not  
> really
> > working, probably I have to find some hook). Is there really more  
> needed?
>
> That doesn't look right at all.  According to its doc string, the  
> car of
> the alist elements should be a regexp that matches a program name,
> whereas your patterns look like they match buffer names.

OK. So I'll try to use

	(("[bt][ac]sh\\'" utf-8 . utf-8)
	 (".*tex\\'" iso-8859-15-unix . iso-8859-15-unix))

--
Greetings

   Pete

“Computers are good at following instructions, but not at reading  
your mind.”
    - D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

Re: Dired doesn't decode UTF-8 file names

[Kevin Rodgers]

Peter Dyballa wrote:
> 
> Am 28.08.2006 um 17:02 schrieb Kevin Rodgers:
> 
>> >     (("\\*shell\\*\\'" utf-8 . utf-8)
>> >      ("\\*.* output\\*\\'" iso-8859-15-unix . iso-8859-15-unix))
>> >
>> > The second line is meant for AUCTeX output buffers (although not really
>> > working, probably I have to find some hook). Is there really more 
>> needed?
>>
>> That doesn't look right at all.  According to its doc string, the car of
>> the alist elements should be a regexp that matches a program name,
>> whereas your patterns look like they match buffer names.
> 
> OK. So I'll try to use
> 
>     (("[bt][ac]sh\\'" utf-8 . utf-8)
>      (".*tex\\'" iso-8859-15-unix . iso-8859-15-unix))

That should fix your *shell* buffers, and Dired buffers for wildcard
file names.  But non-wildcard Dired buffers invoke ls directly (not
via a shell).

-- 
Kevin

Re: Dired doesn't decode UTF-8 file names

[Peter Dyballa]

Am 28.08.2006 um 22:52 schrieb Kevin Rodgers:

> Peter Dyballa wrote:
>> Am 28.08.2006 um 17:02 schrieb Kevin Rodgers:
>>> >     (("\\*shell\\*\\'" utf-8 . utf-8)
>>> >      ("\\*.* output\\*\\'" iso-8859-15-unix . iso-8859-15-unix))
>>> >
>>> > The second line is meant for AUCTeX output buffers (although  
>>> not really
>>> > working, probably I have to find some hook). Is there really  
>>> more needed?
>>>
>>> That doesn't look right at all.  According to its doc string, the  
>>> car of
>>> the alist elements should be a regexp that matches a program name,
>>> whereas your patterns look like they match buffer names.
>> OK. So I'll try to use
>>     (("[bt][ac]sh\\'" utf-8 . utf-8)
>>      (".*tex\\'" iso-8859-15-unix . iso-8859-15-unix))
>
> That should fix your *shell* buffers, and Dired buffers for wildcard
> file names.  But non-wildcard Dired buffers invoke ls directly (not
> via a shell).

I was thinking of the *shell* buffer and the *output whatsoever*  
buffer from AUCTeX, which did not always work correctly, the latter  
kept using incorrect and inappropriate ISO 8859-1 encoding. The  
*shell* buffer does not show in mode-line any encoding – I have no  
idea whether this is good or bad, I would like to know which 'mood'  
it is in and how to interpret the buffer's contents.

Do I really need to set encodings for each UNIX and GNU UNIX command?  
Can't GNU Emacs learn from the LC_CTYPE environment variable?

--
Greetings

   Pete

"Specifications are for the weak and timid!"

Re: Dired doesn't decode UTF-8 file names

[David Kastrup]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 28.08.2006 um 22:52 schrieb Kevin Rodgers:
>
>> Peter Dyballa wrote:
>>> Am 28.08.2006 um 17:02 schrieb Kevin Rodgers:
>>>> >     (("\\*shell\\*\\'" utf-8 . utf-8)
>>>> >      ("\\*.* output\\*\\'" iso-8859-15-unix . iso-8859-15-unix))
>>>> >
>>>> > The second line is meant for AUCTeX output buffers (although
>>>> not really
>>>> > working, probably I have to find some hook). Is there really
>>>> more needed?
>>>>
>>>> That doesn't look right at all.  According to its doc string, the
>>>> car of
>>>> the alist elements should be a regexp that matches a program name,
>>>> whereas your patterns look like they match buffer names.
>>> OK. So I'll try to use
>>>     (("[bt][ac]sh\\'" utf-8 . utf-8)
>>>      (".*tex\\'" iso-8859-15-unix . iso-8859-15-unix))
>>
>> That should fix your *shell* buffers, and Dired buffers for wildcard
>> file names.  But non-wildcard Dired buffers invoke ls directly (not
>> via a shell).
>
> I was thinking of the *shell* buffer and the *output whatsoever*
> buffer from AUCTeX, which did not always work correctly, the latter
> kept using incorrect and inappropriate ISO 8859-1 encoding.

You are confused.  Multibyte buffers in Emacs are always in Emacs
encoding, never anything else.  There are various encodings for I/O
however: process I/O, file I/O, X cutbuffer and so on.  Those are
independent.

> The *shell* buffer does not show in mode-line any encoding – I have
> no idea whether this is good or bad, I would like to know which
> 'mood' it is in and how to interpret the buffer's contents.

Emacs buffer contents are characters in Emacs' encoding (MULE for
Emacs 22, an UTF-8 variant for Emacs 23).

> Do I really need to set encodings for each UNIX and GNU UNIX
> command?  Can't GNU Emacs learn from the LC_CTYPE environment
> variable?

Emacs uses the LC_CTYPE information unless you explicitly override it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Dired confused by filenames starting with date-like strings

[kg6mar]

Miles Bader wrote:

> The fix is "upgrade to version 22".

This sounds plausible to me.  I've not become familiar with CVS yet,so
I can't test this out immediately, but I will see to it.  It's not an
urgent problem.

Thanks to everyone for thinking about this.

-- John

Re: Dired confused by filenames starting with date-like strings

[Miles Bader]

kg6mar@gmail.com writes:
> This sounds plausible to me.  I've not become familiar with CVS yet,so
> I can't test this out immediately, but I will see to it.  It's not an
> urgent problem.

If you're using windows (as you seem to be), there are windows Emacs
binaries available from:

   http://ourcomments.org/Emacs/EmacsW32.html

In particular, the Emacs 22 build is:

   http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl

-Miles
-- 
"Nah, there's no bigger atheist than me.  Well, I take that back.
I'm a cancer screening away from going agnostic and a biopsy away
from full-fledged Christian."  [Adam Carolla]

Re: Dired confused by filenames starting with date-like strings

[John Olson]

Miles Bader <miles@gnu.org> wrote in
news:mailman.5698.1156642923.9609.help-gnu-emacs@gnu.org: 

> "B. T. Raven" <ecinmn@alcisp.com> writes:
>> still leaves the op's original question unanswered: are
>> there any settings in the w32 build of ver. 21.3.1 that
>> will allow dired to work correctly with files named like
>> "nnnn-nn-nn xxx*" ?  From what has been said here so far,
>> it still looks like a bug. 
> 
> The fix is "upgrade to version 22".
> 
> -Miles
> 

I apologize for the delay.  I finally got around to trying 
version 22, and indeed it parses the filenames correctly.  
Better yet, it even displays the photograph image when I open 
the file.  

Case closed.  Thanks.

-- John