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

[Eli Zaretskii]

> Date: Mon, 18 Jul 2011 02:41:08 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
> 
> The 9X family is long dead.

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.

> We shouldn't forgo technical improvement on the account of a dead
> system.

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.)

So this is the requirement: use the new APIs, but test safely for
their availability and provide fallbacks for when they are not
available.  If the fallback does not use Unicode APIs, then it does
not even need to be specifically tested on W9X, if that specific API
is documented to exist on W9X.

> > and (2) going Unicode means that all the existing APIs
> > used by Emacs will have to be switched to Unicode. 
> 
> Why not do it piecemeal?  We can directly call Unicode APIs where
> appropriate.

I'm not sure I understand the details of your proposal.  The situation
that worries me is this:

  . 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

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