From: "Jan D." <jan.h.d@swipnet.se>
Cc: emacs-devel@gnu.org
Subject: Re: Strange behaviour with dired and UTF8
Date: Fri, 2 May 2003 14:44:46 +0200 (CEST) [thread overview]
Message-ID: <200305021336.h42DaHbN022640@stubby.bodenonline.com> (raw)
In-Reply-To: <200305021122.UAA16717@etlken.m17n.org> "from Kenichi Handa at May 2, 2003 08:22:08 pm"
> >> A user may type C-x C-f FILENAME in the dired buffer. With
> >> the above method, we don't know how to encode FILENAME.
>
> > Why would this change? I am only talking about file names that dired
> > reads from a directory. No need to change C-x C-f.
>
> Typing `f' works fine but C-x C-f doesn't, which is not a
> good behaviour.
I think I understand now. You mean if dired uses UTF8, and file system
coding is Latin-1, C-x C-f would then use Latin-1, and possibly fail?
I agree that this is bad, but I am not sure anything can be done
about it. Both KDE and GNOME file managers and file dialogs fail to open
the right file in certain cases. I think it is worse if dired fails on
'f' since in that case the file name is supplied by dired, not the user.
For C-x C-f there is always TAB to see what Emacs thinks the file is called.
>
> >> And, even if one types `f' to visit a file, in that file
> >> buffer, we loose the information of the original
> >> representation.
>
> > Then Emacs as a whole should change.
>
> Yes, my proposal is to change Emacs' behavior as to filename
> handing as a whole in a fairly low cost.
>
I am not sure your case covers all cases. If a file name was
latin-1 and then converted to UTF8 (outside Emacs), Emacs would think it is
still latin-1, no?
It involves a bit of user interaction, making it intrusive.
> By the way, I've just thought of this weird situation. One
> has a file of utf-8 name in a directly of latin-1 name. :-(
> I think we can say sorry in such a case.
But then you would be using non-printable latin-1 characters. I don't
think this is something one has to handle.
Jan D.
next prev parent reply other threads:[~2003-05-02 12:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-24 11:43 Strange behaviour with dired and UTF8 Jan D.
2003-04-25 13:20 ` Kai Großjohann
2003-05-01 6:52 ` Kenichi Handa
2003-05-02 6:41 ` Kai Großjohann
2003-05-02 8:16 ` Jan D.
2003-05-02 8:56 ` Kenichi Handa
2003-05-02 9:59 ` Jan D.
2003-05-02 11:22 ` Kenichi Handa
2003-05-02 12:44 ` Jan D. [this message]
2003-05-03 15:03 ` Richard Stallman
2003-05-03 18:04 ` Jan D.
2003-05-05 14:32 ` Richard Stallman
2003-05-07 15:51 ` Jan D.
2003-05-07 16:09 ` Stefan Monnier
2003-05-09 11:19 ` Richard Stallman
2003-05-03 15:59 ` Stephen J. Turnbull
2003-05-03 17:59 ` Jan D.
2003-05-05 9:20 ` Kenichi Handa
2003-05-06 18:05 ` Jan D.
2003-05-07 1:08 ` Kenichi Handa
2003-05-07 15:43 ` Jan D.
2003-05-03 15:03 ` Richard Stallman
2003-05-03 18:11 ` Jan D.
2003-05-06 5:39 ` Kenichi Handa
2003-05-06 14:41 ` Richard Stallman
2003-05-07 15:49 ` Jan D.
2003-05-07 16:31 ` Stefan Monnier
2003-05-07 17:40 ` Jan D.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200305021336.h42DaHbN022640@stubby.bodenonline.com \
--to=jan.h.d@swipnet.se \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).