[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs 21 on AIX 4.3
Re: Emacs 21 on AIX 4.3
Wed, 27 Jun 2001 18:01:04 +0300 (IDT)
On Tue, 26 Jun 2001, Tak Ota wrote:
> Whenever I need to try such features as toolbar
> and imaging in a buffer, my only choice has been to start VMware and
> run the mainstream GNU Emacs (built under Linux) in slow motion.
That's because no one had time to implement toolbars and images in the
Windows port. The right way to have these features is IMHO to add
such support, not to switch to ported X.
> My question is why can't I consider the system view presented by
> Cygwin as a variant of Unix which contains some minor but inevitable
> Windows specific idiosyncrasies?
Because those minor idiosyncrasies are significant enough, in my
opinion, to make Cygwin unsuitable for many Windows users who don't
have the Unix philosophy imprinted in their brains. For example,
Cygwin programs don't support the Windows d:/foo/bar or d:foo file
names in all circumstances. This isn't a great lossage from the point
of view of a Unix user, but you can't offer such a program to people
who are used to use these file names on Windows.
> > One particularly nasty problem with dumping Windows code is that you
> > lose interoperability with anything but Cygwin applications. That is
> > IMHO a very bad idea; the XEmacs experience shows that many people
> > avoid the Cygwin build because they need to run non-Cygwin
> > applications. I think Emacs should not repeat that mistake.
> I am sorry but I don't fully understand this. Could you give me an
> example of the interoperability?
Quite simply, invoking non-Cygwin programs from inside Cygwin programs
most often doesn't work. Cygwin changes the semantic of file names in
a way that non-Cygwin programs don't recognize them. For example,
instead of d:/foo/bar a program invoked from a Cygwin program will see
/cygdrive/d/foo/bar. Windows programs not compiled with Cygwin will
not know what to do with such file names.
This is only an example. Pipes, fork/exec, signals, etc.--all these
work okay between Cygwin programs, but not always work between a
Cygwin and a non-Cygwin program.
That's why the standard advice to anyone who uses Cygwin programs is
to use only Cygwin programs.
> Also I am not familiar with what the Cygwin build XEmacs is.
It's a more-or-less straightforward compilation of XEmacs using Cygwin
ports of GCC and all the other libraries, including X and the X
toolkits. I understood that this is what you are trying to do with
> After I wrote up to this point I started wondering if we might have
> been talking about two different things. One is porting of GNU Emacs
> to Cygwin runtime, and another is building of NTEmacs with Cygwin GNU
I don't see how you can do one without the other. If you mean
building Emacs with the Cygwin port of GCC but without assuming the
Cygwin DLL nor X server at run time, then this is already done: you
can compile Emacs with Cygwin targeted at MinGW runtime environment
(i.e., Microsoft's runtime DLLs).