Re: Emacs 21 on AIX 4.3

[Perry Smith]

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.