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

[Daniel Colascione <dan.colascione@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3678 bytes --]

On 7/18/11 3:10 AM, Eli Zaretskii wrote:
>> Date: Mon, 18 Jul 2011 02:41:08 -0700
>> From: Daniel Colascione <dan.colascione@gmail.com>
>> CC: emacs-devel@gnu.org
>>
>> 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.

I don't recall that discussion.  Can we reopen it?  According to [1],
Windows 98 has a market share of 0.03%.  I suspect there are more VMS
users, and we dropped support for that OS.

Besides: shouldn't we be encouraging computationally indigent third
world users to switch to use free operating systems instead?  9X users
have no protection against security vulnerabilities.

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

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.
Moving to all-Unicode APIs would improve Emacs' internationalization
support _and_ simplify the codebase.

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

It'd be straightforward to locate all calls to CreateFile and such and
update them to use unicode APIs.  Cygwin supports UTF-8 filenames natively.

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.

>   . 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.  Any file users can
manipulate today, they'll be able to manipulate with a
partially-Unicodeized Emacs.

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.


[1]
http://marketshare.hitslink.com/operating-system-market-share.aspx?spider=1&qprid=10&qpcal=1&qpcal=1&qptimeframe=M&qpsp=148


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]