Mail Archives: cygwin/2002/02/27/05:09:55
> From: Jon Cast <jcast AT ou DOT 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?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -