Re: Using GDB in NTEMACS

Re: Using GDB in NTEMACS

[Stefan Monnier <foo@acm.com>]

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

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

Re: Using GDB in NTEMACS

[Eli Zaretskii]

> 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

Re: Using GDB in NTEMACS

[Jon Cast]

Eli Zaretskii <eliz@is.elta.co.il> wrote:

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

A quick interjection: I /am/ willing to work on a Cygwin build of
Emacs, if that would be accepted here.

Jon Cast


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

Re: Using GDB in NTEMACS

[Stefan Monnier]

> 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

I'm not sure what current code you're talking about.  If you're talking
about the current Emacs code, then wether it's interpreted as
d:/cygdrive/d/foo or as x:/cygdrive/d/foo is irrelevant since the
filename is wrong anyway.
If you're talking about the current cygwin-mount.el code, then
/cygdrive/d/foo will be interpreted as d:/foo.

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

AFAIK you've given examples of ways in which recompiling a unix
program with cygwin can lead to unexpected problems (i.e. limitations
of the cygwin DLL), but I haven't seen any example where the use of
cygwin-mount.el introduces any problem (let along subtle ones).

I don't really care to know whether cygwin's Unix emulation is still
not perfect, all I care about is "why should Emacs not provide a way
to deal with /cygdrive/ paths".

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

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.

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

It's not the same: those who suffer in our case are Emacs users.
Not just cygwin users.  So it is partly our problem.  We get questions
about it on gnu.emacs.help.
And on top of that, we can easily do something about it by including
something like cygwin-mount.el.


	Stefan


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

Re: Using GDB in NTEMACS

[Eli Zaretskii]

> 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

Re: Using GDB in NTEMACS

[Jason Rumney]

Jon Cast <jcast@ou.edu> writes:

> Eli Zaretskii <eliz@is.elta.co.il> wrote:
> 
> > 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.
> 
> A quick interjection: I /am/ willing to work on a Cygwin build of
> Emacs, if that would be accepted here.

We already have some patches based on the XEmacs build, which subject
to agreement from the author, we might be able to use as a starting point.
The reason these patches are currently sitting unused is that the
person who submitted them did not feel able to support them, since
they were basically copy and paste from XEmacs.

-- 
Jason Rumney


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

Re: Using GDB in NTEMACS

[Jason Rumney]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

> And on top of that, we can easily do something about it by including
> something like cygwin-mount.el.

The problem with doing that IMHO, is that if Emacs supports Cygwin
paths in the 99% of cases that cygwin-mount.el covers, users will
expect Cygwin paths to work in 100% of cases.  Until someone can
spend the time to make Cygwin paths work in the remaining 1% of
cases, it is better that cygwin-mount.el remains external to Emacs,
so that expectation is not there.


-- 
Jason Rumney


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

Re: Using GDB in NTEMACS

[Jason Rumney]

Jason Rumney <jasonr@gnu.org> writes:

> We already have some patches based on the XEmacs build, which subject
> to agreement from the author

Unfortunately the author says he has been asked to sign papers to
include his work in Emacs in the past, refused then, and will refuse
in this case also.  So we will have to start from scratch I am afraid.


-- 
Jason Rumney


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

Re: Using GDB in NTEMACS

[Jon Cast]

Jason Rumney <jasonr@gnu.org> wrote:

> Unfortunately the author says he has been asked to sign papers to
> include his work in Emacs in the past, refused then, and will refuse
> in this case also.

That's what I was afraid of.

> So we will have to start from scratch I am afraid.

That can be done :)

Jon Cast

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

Re: Using GDB in NTEMACS

[Jon Cast]

Jason Rumney <jasonr@gnu.org> wrote (to me; I'm assuming you forgot to Cc: the mailing list):

> FWIW, it did not seem to be a huge amount of work.

I didn't think it was, or I wouldn't have volunteered :)

> Most of the work involved modifying the configure script and
> Makefile.in files,

And providing an s/cygwin.h file :)

What sort of modifications were made to Makefile.in?

> then I guess there is a bit of work figuring out which #ifdef
> WINDOWSNT blocks are required by the Cygwin version, and which
> aren't.

Just a guess, but doesn't that depend on what GUI mechanism we settle
on?  A purely LessTif-based GUI wouldn't require any of the #ifdef
WINDOWSNT blocks, would it?

> I don't think the patch I was sent had done this last part though,
> the impression I got was that the submitter had taken bits from
> XEmacs until he got it to compile.

So it's not as great a loss as might be expected, then---I'm perfectly
capable of modifying Emacs's build scripts until it compiles :)

Jon Cast

 LocalWords:  Makefile cygwin ifdef

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