Emacs for Cygwin (was: cygwin-mount.el, Using GDB in NTEMACS)

Emacs for Cygwin (was: cygwin-mount.el, Using GDB in NTEMACS)

[Ehud Karni]

Below is Eli Zaretskii mail from 23 Feb 2002.

I think that we need a CygEmacs - an emacs that will be compiled with
the real Cygwin ported gcc (i.e. without the -mno-cygwin). CygEmacs
will have UNIX APIs for I/O (files and sockets), and M$Windows APIs
for the display and the keyboard. This is already done (partly) by the
Cygwin port of rxvt.

If this is too difficult, may be a version of Emacs for Cygwin, that
use only the UNIX APIs can be ported. This Emacs version will be used
only within Cygwin's windows - Console or rxvt (Emacs in TTY mode) or
real display (using Cygwin-Xfree).

Any of these version will solve the 2 major issues of using Emacs with
Cygwin - 1. The files (names and attributes). 2. Running of sub-shells
in Emacs (file is not tty problem). It may solve another problem that
bothers me - running a client on the PC to a server on UNIX.

Ehud.


    --------------- Original Eli's mail ---------------

> From: letters@hotpop.com (Jari Aalto+mail.emacs)
> Date: Sat, 23 Feb 2002 11:29:27 +0200
> 
> all Windows users continue complaining why Emacs does not help them
> to use Cygwin environment more easily.

They should complain to Cygwin developers.

I asked before, and I'll ask again: did someone try to talk to the
Cygwin developers about this issue?  Did someone ask them what do
they think about supporting Windows file names better, and if so,
what did they reply?

It strikes me that an important party to this discussion is strangely
absent.


-- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.simonwiesel.co.il          Better  Safe  Than  Sorry

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs for Cygwin (was: cygwin-mount.el, Using GDB in NTEMACS)

[Jon Cast]

You wrote:

> I think that we need a CygEmacs - an emacs that will be compiled
> with the real Cygwin ported gcc (i.e. without the
> -mno-cygwin).

I should probably point out that I am (slowly) working on such a port
of Emacs.

> CygEmacs will have UNIX APIs for I/O (files and
> sockets), and M$Windows APIs for the display and the keyboard. This
> is already done (partly) by the Cygwin port of rxvt.

I used to agree with you, but the more I think about it, the more I
think the ideal solution (bearing in mind that we are talking about a
*Cygwin* port of Emacs) is use the normal LessTif toolkit support, and
make LessTif work ``right'' from our perspective under Windows.  (This
would also allow us to support remote X connections, which is IMNSHO
one of the major features X has over Windows.)  Only if/while this is
not workable/not worth the effort should we use the native APIs
directly.

> If this is too difficult, 

It's certainly non-trivial, but it's not difficult, either.  All it
takes is a grep for WINDOWSNT, and then a check of each of those ~ 206
occurrences to see if each one should read WINDOWSNT or (WINDOWSNT ||
CYGWIN).

> may be a version of Emacs for Cygwin, that use only the UNIX APIs
> can be ported. This Emacs version will be used only within Cygwin's
> windows - Console or rxvt (Emacs in TTY mode) or real display (using
> Cygwin-Xfree).

This second approach surrenders practically nothing for the kind of
user Cygwin targets once Cygwin-Xfree supports a rootless X server.
So, I think if that approach is workable it should be pursued instead.

> Any of these version will solve the 2 major issues of using Emacs
> with Cygwin - 1. The files (names and attributes). 2. Running of
> sub-shells in Emacs (file is not tty problem). It may solve another
> problem that bothers me - running a client on the PC to a server on
> UNIX.

Right, because the alternatives you name don't affect the use of Posix
APIs for these operations.  (Although I agree that the primary purpose
of a Cygwin port of Emacs is to get the Posix APIs for the
operations.)

> Ehud.

Jon Cast

 LocalWords:  LessTif WINDOWSNT

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs for Cygwin (was: cygwin-mount.el, Using GDB in NTEMACS)

[Eli Zaretskii]

> From: Jon Cast <jcast@ou.edu>
> Date: Tue, 26 Feb 2002 21:33:11 -0600
> 
> > CygEmacs will have UNIX APIs for I/O (files and
> > sockets), and M$Windows APIs for the display and the keyboard. This
> > is already done (partly) by the Cygwin port of rxvt.
> 
> I used to agree with you, but the more I think about it, the more I
> think the ideal solution (bearing in mind that we are talking about a
> *Cygwin* port of Emacs) is use the normal LessTif toolkit support, and
> make LessTif work ``right'' from our perspective under Windows.  (This
> would also allow us to support remote X connections, which is IMNSHO
> one of the major features X has over Windows.)  Only if/while this is
> not workable/not worth the effort should we use the native APIs
> directly.

I don't use Lesstiff too much, so please take what's below with a
grain of salt.

I think we should be aware of Windows users expectations, not only of
technical merits.  In a somehwat limited experience with a Windows
port of Gimp (which I believe uses ported toolkits for its GUI), I
find that even experienced and computer-savvy users feel annoyed by a
very different set of conventions presented by the X toolkits.

I don't have enough experience and data to judge whether that's a real
concern or just an NIH syndrom, but I thought I'd mention it anyway.

> It's certainly non-trivial, but it's not difficult, either.  All it
> takes is a grep for WINDOWSNT, and then a check of each of those ~ 206
> occurrences to see if each one should read WINDOWSNT or (WINDOWSNT ||
> CYGWIN).

Unfortunately, it's more than that.

First, there are those w32*.c files which hide an enormous complexity
of the Windows port from the mainline code (that's why you see only
200-odd ifdefs).  Some of that code can be safely tossed in the Cygwin
port--the part merely tries to wrap library functions with
Posix-compliant wrappers--but some cannot.  So you might find yourself
_adding_ ifdefs ;-)

And then there's the issue of the Lisp code.  What would be the value
of system-type in the Cygwin port?  It could use the same symbol
windows-nt used by the current Windows port, or it could invent a new
symbol.  Either way, there will be a need to go through all the
bundled packages and make sure code which does a different thing for
windows-nt will DTRT in the Cygwin port.  The difficulty here is that
in some cases the Cygwin port should take the Unix/GNU branch (like
with file names and the shell), while in others (like browse-url, for
example) it should take the Windows branch.  This probably calls for a
new symbol rather than reusing windows-nt, but the work has to be done
anyway.  I counted more than 120 places where windows-nt is mentioned
in bundled Lisp code.

> > may be a version of Emacs for Cygwin, that use only the UNIX APIs
> > can be ported. This Emacs version will be used only within Cygwin's
> > windows - Console or rxvt (Emacs in TTY mode) or real display (using
> > Cygwin-Xfree).
> 
> This second approach surrenders practically nothing for the kind of
> user Cygwin targets once Cygwin-Xfree supports a rootless X server.
> So, I think if that approach is workable it should be pursued instead.

How is this different from the alternative to use Lesstiff?  That one
is also based on the ported XFree, right?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel