Re: Using GDB in NTEMACS

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

> From: "Stefan Monnier <foo@acm.com>" <monnier+gnu.emacs.help/news/@RUM.cs.yale.edu>
> Newsgroups: gnu.emacs.help
> Date: 22 Feb 2002 12:36:41 -0500
> 
> > 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

Windows isn't Unix.  The current code will cause /cygdrive/d/foo to be
interpreted as x:/cygdrive/d/foo (where x: is the drive letter of the
default-directory's value), instead of d:/foo, the place where
/cygdrive/d/foo actually points.  That's because on Windows, a file
name without a drive letter is assumed to refer to the current drive.

> > 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.

If Emacs could be compiled with Cygwin, that would indeed solve many
problems, at least for people who mostly use Cygwin programs.
Unfortunately, a Cygwin build of Emacs is not around the corner;
volunteers are welcome to work on that.

> end users get bitten by something that can be acceptably and easily fixed
> within Emacs and without any direct adverse effect.

IMHO, this optimistic vision of the solution is inaccurate.  That's
what all that longish thread on gnu.emacs.help was about.

> > 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.

Thanks a lot for this comparison!

My evidence is not secret: it's there in several dozens of GNU
packages I ported.  You can download those ported packages (URL
available upon request) and grep their sources for relevant ifdef's
and macro names, and then draw your own conclusions.  My conclusion is
clear: a program that isn't ported, just compiled, is broken in the
absolute majority of cases.  That breakage could be blatant, or it
could be more subtle, but either way, such programs cannot be trusted.

But I cannot afford teaching you all those bits and pieces, pointing
out all the subtle problems and explaining them, etc.  I don't have
enough free time for that.  I gave a few examples on the news group,
which should have been demonstrated some of the subtleties; if that
wasn't enough, then I give up.

> Based on my understanding of cygwin's intent, there's no such hope
> in the near future

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?

> >  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.

We also have gotten nowhere in solving the problems of the famine in
Africa or the war in Afghanistan.  Those are not our problems to
solve.

Look, I've repeated those arguments many times now.  I'm tired.  You
don't want to agree with my opinions, fine.  There are other people
who worked on related issues--Andrew and Jason, to begin with; ask
them, they might give you a different view, or perhaps they will even
agree with you.  Or don't ask anyone, if you think you know better.  I
think it's a mistake to make this cygwin-mount kludge part of Emacs,
but that shouldn't stop other developers from checking in changes if
they disagree, especially so strongly as you seem to.

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