[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] system-type cygwin with window-system w32
From: |
Eli Zaretskii |
Subject: |
Re: [PATCH] system-type cygwin with window-system w32 |
Date: |
Mon, 18 Jul 2011 19:41:16 +0300 |
> Date: Mon, 18 Jul 2011 03:49:41 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
>
> > Not in the 3rd world, where there are still many machines running it.
> > Or so we were told last time this issue popped up. RMS personally
> > asked not to drop W9X on this behalf.
>
> I don't recall that discussion. Can we reopen it?
Let's wait for Richard to chime in.
> > I didn't say we should stop the improvement. You will find quite a
> > few Emacs features that use APIs which are unavailable on W9X. But
> > they do it in a way that lets Emacs still run on W9X and produce
> > reasonable results, be that some fallback or just plain message saying
> > that this nifty feature is not available. (Of course, disabling menus
> > or file access cannot use the latter fire escape, because they are too
> > basic and without them Emacs would become unusable.)
>
> These fallbacks involve significant complexity, and they're
> lightly-tested at best. I'd prefer to eliminate the complexity involved
> in supporting these alleged 9X users by simply dropping the support.
I'd prefer that as well, as soon as we drop W9X support.
> > . user uses the file dialog to return a file name in UTF-16 which
> > includes characters not available in the system codepage (this is
> > quite possible on NTFS)
> >
> > . the file name is passed to file-attributes or insert-file-name or
> > some other primitive that accepts file names
>
> It'd be straightforward to locate all calls to CreateFile and such and
> update them to use unicode APIs.
I'm afraid it isn't straightforward. I suspect there's a lot of
supporting code that still assumes unibyte characters. But I'll
welcome patches in that area (if we agree to drop W9X support).
> Cygwin supports UTF-8 filenames natively.
I know that, but it isn't relevant to the native w32 build, because
that needs to use UTF-16, not UTF-8.
> But even if we don't --- why does it matter? You can create files using
> the NT native API that can't be opened using Win32 calls; it doesn't
> cause a problem in practice. Likewise, users who have strange
> filesnames might not be able to use them with all Emacs features right
> away, but they'll be able to work with more reasonable filenames just as
> they did before.
But switching to Unicode doesn't make sense _unless_ you want to
support "strange file names": all the non-strange file names are
already supported under the current ``ANSI'' APIs. It's when I want
to see file names with characters not from my system locale that I
need Unicode.
> > . if the underlying file APIs used by these primitives (`stat',
> > `open', `opendir', etc.) are not Unicode, these primitives will
> > fail in weird ways, like "file does not exist" etc., that would
> > just confuse the user.
>
> I'd prefer to go all-Unicode because I don't think unencodable filenames
> are common enough to warrant much concern here.
Sorry, I disagree. I have quite a few on my system, for example. If
you want to know how I got them, then they came with zip files that
included dictionaries in all kinds of languages, I brought them in
when I worked in a Windows port of Ispell. And that's just one
example that came to my mind, I'm sure I would find more if I cared to
look. E.g., I remember seeing file names with Kanji characters at
some point.
IMO, a half-broken feature is worse than an absent feature.
Especially if the breakage reveals itself as subtly as "file does not
exist" when I just selected it from a dialog.
> Any file users can manipulate today, they'll be able to manipulate
> with a partially-Unicodeized Emacs.
See above: for those, the Unicode interfaces give no advantage.
> Still, if we can't do that, then as a temporary measure, we can still
> use Unicode APIs (the 9X discussion notwithstanding), but as a temporary
> measure, filter their results so that we reject filenames that can't be
> used with the system codepage.
But then this is just complication with no benefits, isn't it?
- Re: [PATCH] system-type cygwin with window-system w32, (continued)
Re: [PATCH] system-type cygwin with window-system w32, Eli Zaretskii, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Daniel Colascione, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Eli Zaretskii, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Daniel Colascione, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Eli Zaretskii, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Daniel Colascione, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Juanma Barranquero, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32,
Eli Zaretskii <=
- Re: [PATCH] system-type cygwin with window-system w32, Daniel Colascione, 2011/07/18
- Re: [PATCH] system-type cygwin with window-system w32, Eli Zaretskii, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, Richard Stallman, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, Richard Stallman, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, Daniel Colascione, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, David Kastrup, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, Daniel Colascione, 2011/07/18
Re: [PATCH] system-type cygwin with window-system w32, Richard Stallman, 2011/07/19
Re: [PATCH] system-type cygwin with window-system w32, Lennart Borgman, 2011/07/20
Re: [PATCH] system-type cygwin with window-system w32, Jason Rumney, 2011/07/18