[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cygwin build (was: Using GDB in NTEMACS)

From: Eli Zaretskii
Subject: Re: Cygwin build (was: Using GDB in NTEMACS)
Date: Wed, 27 Feb 2002 18:02:17 +0200

> From: Jon Cast <address@hidden>
> Date: Tue, 26 Feb 2002 21:48:10 -0600
> > * Do the ported toolkits support Windows fonts and/or
> > Windows-specific encodings (a.k.a. codepages)?  If not, we will need
> > to think how to let users work with Windows locales.
> Dunno.

I'd suggest to find out.  Which toolkit to support is a major design
constraint, so you'll probably want to make that decision up front.
If the odds suggest to use Lesstiff, then the absence of support for
Windows character sets would be a major PITA for the users.

This is one area where XEmacs cannot help us, I think: its Windows
port is not yet m17n-capable.

> > * The shell issue: should the Cygwin port support only Bash, or the
> > stock Windows shells as well?
> What are the issues with supporting Windows shells?  PTY problems?

What I had in mind was the support for running subprocesses.  Stock
Windows shells have peculiarities and misfeatures, such as different
quoting rules, the nasty habit of returning zero exit status even if
the command they ran failed, etc., and some of the shells are 16-bit
programs which cannot be safely ran as async subprocesses.  The
Windows-specific code in Emacs (the w32*.c files) deals with these
problems by redefining some library functions, and the issue I had in
mind was whether to keep all that code or toss it.  If you keep it,
there might be complications due to redefinition of library functions.

> > * There's also this talk among users of the Cygwin port of XEmacs
> > about it being very slow, especially in Dired.  I don't understand
> > why would the Cygwin build be slow to the point that it annoys
> > users, but perhaps we should try to do something about it.  For
> > example, if the reason is that the pipe implementation is slow,
> > maybe we should use the ls-lisp.el package in the Cygwin port
> > instead of the external `ls' program.
> <http://mail.gnu.org/pipermail/emacs-devel/2002-February/006128.html>
> and
> <http://mail.gnu.org/pipermail/emacs-devel/2002-February/006131.html>
> seem to explain most of the speed difference.

I don't think they really explain that.  I replied to the first one
with another data point that seems to contradict the assumption that
`stat' is the explanation.  As to the second one, Jason just
reaffirmed what I heard many times elsewhere: that Cygwin applications
are slower, but didn't give any explanations.

Perhaps we should ask on the Cygwin list, where the Cygwin developers
could give us authoritative answers.

> Given these two factors, I doubt ls-lisp.el would be much faster for
> a Cygwin port of Emacs than ls would be.

If the problem is `stat', I agree.

> I don't think it's a concern for now, though.

Right; for now, it's just something to keep in mind.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]