[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
Tue, 26 Jun 2001 08:56:16 -0700 (PDT)
On Tue, 26 Jun 2001 16:21:00 +0300 (IDT), Eli Zaretskii <address@hidden> wrote:
> I'd advise against such a categorical approach. Dumping the
> Windows-specific code means you lose all the experience that was
> earned by hard labor over the past 5 years of NTEmacs maintenance.
> That experience should not be discarded too easily; it is what makes
> NTEmacs a much better Windows citizen than XEmacs.
Please, please don't take me wrong. I have never proposed dumping
Windows-specific code nor dumping NTEmacs. I am an everyday-user of
NTEmacs and most grateful about its existence, people and their hard
work behind its existence. I will continue to be an NTEmacs user as
long as I am forced to use Windows for making my ends meet.
What I have personally been trying to achieve is to have a mainstream
GNU Emacs on Windows. 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.
> With all due respect to Cygwin, it still doesn't solve some of the
> idiosyncrasies of Windows. Some of those problems cannot be solved at
> all on a library level (e.g., text vs binary I/O), because only the
> application knows what's right in each case.
> In other words, Windows isn't Unix even when using the Cygwin
> runtime. You can see the evidence of this in Emacs-related news
> groups and on the Cygwin mailing list: people keep describing problems
> with small incompatibilities that cannot be easily solved.
I have no objection to this observation. However, from application
program's viewpoint, the environment looks far from Windows but
resembles much like Unix.
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?
> 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? Also I am not familiar with what the
Cygwin build XEmacs is.
We can't expect everyone using Cygwin on their Windows. Therefore
NTEmacs remains a mainstream solution for Windows users. I don't see
any issue in "many people avoid the Cygwin build".
> I also don't see why the Cygwin build should force the use of the
> ported Xlib. That will almost certainly make the Cygwin port
> significantly slower than if it used the native GUI toolkit. Why
> should Cygwin users be punished like that?
> To summarize: I think someone _does_ have to walk through the Windows
> code in NTEmacs and decide in each case what should be retained in the
> Cygwin port. Building with Cygwin as if you were on Unix might be the
> easy way out, but IMHO it's the wrong way. Emacs should support
> Cygwin, but not at the expense of being useful in conjunction with
> other Windows software.
We of course know what NTEmacs is. I know what I want, that is a port
of Emacs on another (sort of) Unix system. Please explain me what you
are trying to realize. I am already using NTEmacs happily with cygwin
tools and am quite satisfied with their harmony. Cygwin lets me use
NTEmacs much more efficiently by providing standard Unix commands.
What I've been looking for is a *real* Emacs that runs on Windows.
Especially NTEmacs 21 lacks some new features that the big brother 21
is about to introduce to the world.
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
tool-chain. If so there is no reason why we cannot achieve both.