Re: Using GDB in NTEMACS

["Eli Zaretskii" <eliz@is.elta.co.il>]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Fri, 22 Feb 2002 14:37:23 -0500
> 
> I haven't seen any example where the use of
> cygwin-mount.el introduces any problem (let along subtle ones).

cygwin-mount.el isn't enough to solve this.

To support Cygwin-style file names, we need to fix all Emacs
primitives which deal with file names so that they convert them to the
native Windows form.  This includes ``classic'' file-name primitives,
such as expand-file-name and substitute-in-file-name; less obvious
ones, such as Windows-specific parts of call-process; and probably
some more.  This is hard (look at the mess in expand-file-name, and
you'll see why), but doable.

We then need to chase all the Lisp code that takes apart file names or
constructs file names from their parts, and fix whatever needs fixing
there.  This is where I expect the major part of the effort to be
spent, since the amount of code is enormous, and it's not always
obvious what to do in each case.

And then there are problems which are simply unsolvable in Emacs, such
as when the user changes the mount points outside Emacs (so that "/"
now references a different drive).

So this is a significant effort, if we want to do it right.  We could
have solved it easier if we could make changes to the Windows
run-time, but we can't.

I think before someone embarks on such a journey, we should talk to
Cygwin developers and ask them to solve this on their side, at least
for core development tools for which Emacs provides an interface.

> > I don't know on what you are basing this.  Did the Cygwin developers
> > say they don't intend to fix this, ever?  Did anyone even ask them?
> 
> It's based on my understanding of their intent.  If their intent
> is to provide a Unix API, then they pretty much have no choice.

I don't see why they should have no choice.  Cygwin could support both
forms of file names.  There's no contradiction between them, as long
as Cygwin controls the run-time library, something that Emacs doesn't.

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