[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs 21 on AIX 4.3
From: |
Perry Smith |
Subject: |
Re: Emacs 21 on AIX 4.3 |
Date: |
Tue, 26 Jun 2001 08:39:37 -0500 (CDT) |
I guess I had a few very simple objectives. One was that "configure"
followed by "make" should `work' from the cygwin bash shell. By
`work' I only mean to imply that it produces something. According to
the README, this is suppose to work now and it probably does if I just
spent a little more time with it.
The other objective was to understand cygwin's mounting stuff so that
I can open "/usr/dog" from inside emacs and it will be the same as
what the cygwin's bash shell said it was.
As far as the windows code, I completley agree with this post. I
didn't even know that cygwin had an xlib but that would be useless to
me. I'm stuck on windows only because it is the only ****ing platform
that has the applications I need. GRRR!!! Why would you be on
MS-Lost and use only GNU or Cygwin apps?
Perry
Eli Zaretskii writes:
> [Note that I moved this discussion to emacs-devel. I think
> emacs-pretesters is not appropriate for it anymore.]
>
> On Mon, 25 Jun 2001, Tak Ota wrote:
>
> > Regarding the GUI and w32xxx stuff, I consider this cygwin port to be
> > another Emacs port to a variant of unix system since the cygwin layer
> > pretty much can hide the underlying Windows. Therefore I am ignoring
> > w32xxx files all together. To answer your question I personally think
> > Cygwin port should not rely on the native Windows GUI. The port
> > should be a legitimate X client since cygwin provides a port of X
> > server by itself.
>
> 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.
>
> 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.
>
> 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 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.