From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: Using GDB in NTEMACS Date: Fri, 22 Feb 2002 21:00:32 +0200 Message-ID: <6137-Fri22Feb2002210032+0200-eliz@is.elta.co.il> References: <3C6CDC0F.ECB82017@is.elta.co.il> <3C6F2F5F.DCBC0805@is.elta.co.il> <5l4rketmyq.fsf@rum.cs.yale.edu> <3C71EC79.7EE4D14C@is.elta.co.il> <5leljhsfuf.fsf@rum.cs.yale.edu> <5lg03xqm84.fsf@rum.cs.yale.edu> <5lbselqjav.fsf@rum.cs.yale.edu> <3C73260B.C9111ECB@is.elta.co.il> <5l3czwqj3m.fsf@rum.cs.yale.edu> <3C73D10E.A08C2504@is.elta.co.il> <5lofijq13j.fsf@rum.cs.yale.edu> <87pu2zlppc.fsf@charter.net> <3C748F5B.6F50B5EF@is.elta.co.il> <874rkbxpar.fsf@charter.net> <3C74E05D.781AD1E0@is.elta.co.il> <5ly9hlo1ue.fsf@rum.cs.yale.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: quimby2.netfonds.no X-Trace: quimby2.netfonds.no 1014404750 11949 195.204.10.66 (22 Feb 2002 19:05:50 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 22 Feb 2002 19:05:50 GMT Cc: emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16eL0v-00036d-00 for ; Fri, 22 Feb 2002 20:05:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16eKyP-0004wp-00; Fri, 22 Feb 2002 14:03:13 -0500 Original-Received: from freya.inter.net.il ([192.114.186.14]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16eKxs-0004uX-00 for ; Fri, 22 Feb 2002 14:02:40 -0500 Original-Received: from zaretsky (diup-221-102.inter.net.il [213.8.221.102]) by freya.inter.net.il (Mirapoint) with ESMTP id BFP60734; Fri, 22 Feb 2002 21:02:28 +0200 (IST) Original-To: monnier+gnu.emacs.help/news/@RUM.cs.yale.edu X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: <5ly9hlo1ue.fsf@rum.cs.yale.edu> (monnier+gnu.emacs.help/news/@RUM.cs.yale.edu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1435 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1435 > From: "Stefan Monnier " > 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