all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Colascione <dan.colascione@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] system-type cygwin with window-system w32
Date: Mon, 18 Jul 2011 06:10:00 -0400	[thread overview]
Message-ID: <E1Qikm0-0001Ph-Gg@fencepost.gnu.org> (raw)
In-Reply-To: <4E23FFB4.1040809@gmail.com> (message from Daniel Colascione on Mon, 18 Jul 2011 02:41:08 -0700)

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

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



  reply	other threads:[~2011-07-18 10:10 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-18  0:01 [PATCH] system-type cygwin with window-system w32 Daniel Colascione
2011-07-18  0:06 ` Daniel Colascione
2011-07-18  6:13 ` Eli Zaretskii
2011-07-18  6:29   ` Daniel Colascione
2011-07-18  8:53     ` Eli Zaretskii
2011-07-18 10:10       ` Daniel Colascione
2011-07-18 16:04         ` Paul Eggert
2011-07-18 16:19         ` Eli Zaretskii
2011-07-18 13:55     ` Jason Rumney
2011-07-18 16:13     ` Paul Eggert
2011-07-18 17:34       ` Andreas Schwab
2011-07-18  6:53 ` Eli Zaretskii
2011-07-18  7:01   ` Daniel Colascione
2011-07-18  9:04     ` Eli Zaretskii
2011-07-18  9:41       ` Daniel Colascione
2011-07-18 10:10         ` Eli Zaretskii [this message]
2011-07-18 10:49           ` Daniel Colascione
2011-07-18 11:22             ` Juanma Barranquero
2011-07-18 16:41             ` Eli Zaretskii
2011-07-18 16:48               ` Daniel Colascione
2011-07-18 17:08                 ` Eli Zaretskii
2011-07-18 22:08             ` Richard Stallman
2011-07-18 22:24               ` Daniel Colascione
2011-07-18 22:45                 ` David Kastrup
2011-07-18 22:56                   ` Daniel Colascione
2011-07-19 16:49                     ` Richard Stallman
2011-07-21  1:44               ` Lennart Borgman
2011-07-18 22:08             ` Richard Stallman
2011-07-18 13:31       ` Jason Rumney
2011-07-18 13:46         ` Richard Riley
2011-07-18  8:42 ` Eli Zaretskii
2011-07-18 10:33   ` Daniel Colascione
2011-07-18 16:29     ` Eli Zaretskii
2011-07-18 17:04       ` Daniel Colascione
2011-07-18 15:54 ` Stefan Monnier
2011-07-18 15:55 ` Stefan Monnier
2011-07-18 17:37 ` Andreas Schwab
  -- strict thread matches above, loose matches on Subject: below --
2011-07-18 17:33 grischka
2011-07-18 17:50 ` Daniel Colascione
2011-07-18 18:08   ` Daniel Colascione
2011-07-18 18:52     ` grischka
2011-07-18 19:11       ` Daniel Colascione
2011-07-18 21:01         ` grischka
2011-07-19  2:58           ` Eli Zaretskii
2011-07-19  2:59             ` Daniel Colascione
2011-07-21 17:44           ` Lennart Borgman
2011-07-22  7:30             ` Daniel Colascione
2011-07-22  7:41               ` Lennart Borgman
2011-07-22 21:24                 ` chad
2011-07-22 21:57                   ` Lennart Borgman
2011-07-18 18:38   ` grischka

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1Qikm0-0001Ph-Gg@fencepost.gnu.org \
    --to=eliz@gnu.org \
    --cc=dan.colascione@gmail.com \
    --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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.