Re: [PATCH] system-type cygwin with window-system w32

[Eli Zaretskii]

> 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?