Re: Using GDB in NTEMACS

[Stefan Monnier <address@hidden>]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.help as well.

>> Although you have stated that Emacs
>> does not know when a string is a file name, this claim seems absurd on
>> its face.  Every Emacs function that operates on files is perfectly
>> aware of this fact.
> Not every Emacs function knows that.  This was discussed on the developers'
> list; a superflous scan found several that don't.

And those should be fixed anyway.

> In addition, there's application-level Lisp code that takes file names
> apart, matches them to regular expressions, or constructs new file names
> from parts of the old ones.  Those places need to be changed as well.

Do they ?  Why ?  The /cygdrive/ paths should actually need no such
changes since they look and behave just like Unix (in contrast to
the a:\foo ones which do require special care).

> It's the wrong end of the problem.  Problems should be fixed where they
> originate.

As far as I can see, the place where they originate is in the fact that
Emacs is not cygwinized.

And whether they originate in Emacs or not is irrelevant to the fact that
end users get bitten by something that can be acceptably and easily fixed
within Emacs and without any direct adverse effect.

> cygwin-mount only solves part of the problem.  We've been through this,
> including in this thread; may I suggest to re-read past messages?

I still have no idea which part it does not solve.

> I don't want to argue about this; certainly not here.  This is way
> off-topic now.  My opinion is based on years of experience, which included
> similar mistakes, but I have no time to explain it all, show all the pieces
> of code I've ever gone through, especially when every word is subject to
> scrutiny, and I need to repeat the same arguments time and again.  I don't
> care enough about this issue to waste so much of my time on it.  Sorry.

Reminds me of the use of secret evidence in trials.

>> I don't mean to annoy, but you seem to consistently mischaracterize
>> the intent and purpose of Cygwin.

> We were talking about Emacs and Cygwin applications, and specifically about
> GDB.  I don't want to discuss the intent of Cygwin, it's not really
> relevant to the issue at hand.  The issue at hand is what is the best way
> to let Emacs users use Cygwin applications.

The intent of cygwin is relevant to this issue because it determines
whether or not there's a hope for cygwin applications to change their
behavior or not.  Based on my understanding of cygwin's intent, there's
no such hope in the near future, which means that your saying "let cygwin
fix it" amounts to telling users to get lost.

>> Cygwin was developed to make it
>> easy to build significant Unix software on Windows *without* requiring
>> extensive changes to the source code.  You have stated that nearly
>> every high quality Unix port to Windows will require changes, but this
>> is simply not true.  An astonishing amount of Unix software builds and
>> works fine in the Cygwin environment with no porting required at all.

> They will work fine as long as they only need to interact with other Cygwin
> applications.

Which is the situation we're talking about: all cygwin applications
(except for Emacs which does not exist in a cygwin version).

> I never said that the decision was arbitrary, just that it has adverse side
> effects that need to be taken care of.

What are they ?

>  Other similar projects made similar
> mistakes in the past.  The previous format of Cygwin names, //c/foo, was
> even nastier, so they changed that.  Obviously, Cygwin is on the right
> track, they just aren't there yet, IMO.  We should help them by sharing
> relevant experience and by requesting that misfeatures such as this one be
> solved better than they are now.  If we accept the current situation as
> satisfactory, we will get nowehere.

We have gotten nowhere since 1999 with the approach you're advocating.


        Stefan