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: Cygwin build (was: Using GDB in NTEMACS)

[Eli Zaretskii]

> From: Jon Cast <jcast@ou.edu>
> Date: Fri, 22 Feb 2002 13:30:17 -0600
> 
> A quick interjection: I /am/ willing to work on a Cygwin build of
> Emacs, if that would be accepted here.

Sure, please go ahead.  I think a possibility to build Emacs as a
Cygwin application would be a terrific feature.

In case you didn't know, Emacs can be compiled with Cygwin today, but
as a MinGW application, not a Cygwin application.  See nt/INSTALL for
the gory details.

Also, from past discussions of this issue, it could be useful first to
discuss the best approach to this project.  There are trade-offs that
IMO need to be considered when you decide how much Windows-specific
code to keep in the Cygwin build, whether to use the ported Xlib or
the native Windows GUI, etc.

_______________________________________________
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]

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

[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

Cygwin-mount.el (Was: Re: Using GDB in NTEMACS)

[Jari Aalto+mail.linux]

* Fri 2002-02-22 Eli Zaretskii <eliz@is.elta.co.il> list.emacs-devel
* Message-Id: <8582-Fri22Feb2002224834+0200-eliz@is.elta.co.il>
| > From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
| > 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.  

I don't think this is the correct view to the issue. 

If I understood correct, your premises are that:

- If Emacs would include cygwin-mount.el, users expect to be able
  use FULL cygwin paths EVERYWHERE.

I donät think that is a correct view. I don't see in a foreseeable
future for anyone starting to use Cygwin style paths in their Lisp
code or applications, configurations they've made to Emacs, just
because there would be cygwin-mount.el shipped with Emacs.

The view is more like Stefan says:

- Most of the Win32 Emacs users will eventually install Cygwin
- To manage cygwin effectively under Emacs, one needs cygwin-mount.el  

The requirement of cygwin is natural, because a simple M-x grep,
doing diff, running RCS, or any other similar thing cannot be done
without cygwin.

Emacs and Cygwin go hand in hand in Win32: in fact Emacs is crippled
without it, so is XEmacs without Cygwin.

Users want to MANAGE cygwin from Emacs. They do not want to "use
cygwin paths" in their Emacs configuration. What I mean, is that users
that have installed cygwin want to be able to use addresses like:

    C-x C-f /etc/passwd

to configure their Apache, Inetd, Squid, Exim and
other nifty stuff that can now be used natively under Windows. Just
like you would in Linux.


That is the intent of cygwin-mount.el. It makes life easier. 

To require perfection before anything can be added to Emacs is
a sad paths for Emacs. It will not make it more user friendly.
By including something that (in lisp level) is not perfect,
will improve in time from the user's comments if there is
something to fix.

Adding cygwin-mount.el would be the best thing happened to
any Windows user. 


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

This is against all the design decisions and I'm sure you
understand why. Cygwin is an Unix emulation, it should not
understand DOS style paths at all.

How the heck would a pure Unix application understand configuration
file that would include dos paths? You can't expect to change 10 000
unix applications to support DOS paths.

Cygwin cannpt solve that in their libraries, because the application
use the paths, not Cygwin.

Emacs is at least now pure windows application, so it understandas
DOs paths. But it could be taught to understand cygwin paths and
that change is small in the scope where cygwin paths are mainly
used.

cygwin-mount.el adds that extra, in a simple yet effective way.
Jari

-- 
http://tiny-tools.sourceforge.net/
Swatch  @time http://www.ryanthiessen.com/swatch/resources.htm
Convert @time http://www.mir.com.my/iTime/itime.htm


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

Re: Cygwin-mount.el (Was: Re: Using GDB in NTEMACS)

[Eli Zaretskii]

> From: letters@hotpop.com (Jari Aalto+mail.linux)
> Date: Sat, 23 Feb 2002 11:19:15 +0200
> 
> If I understood correct, your premises are that:
> 
> - If Emacs would include cygwin-mount.el, users expect to be able
>   use FULL cygwin paths EVERYWHERE.
> 
> I don't think that is a correct view. I don't see in a foreseeable
> future for anyone starting to use Cygwin style paths in their Lisp
> code or applications

You assume that any Cygwin-style file name comes from something a user
types.  But that's not true: some file names are gotten from something
output by a program.  This thread started (on gnu.emacs.help) because
someone could use GDB from GUD; that's one case where Emacs gets a
file name from a program.  There are others: Dired, for example (if
the user wants to use the Cygwin port of `ls').

> Users want to MANAGE cygwin from Emacs. They do not want to "use
> cygwin paths" in their Emacs configuration. What I mean, is that users
> that have installed cygwin want to be able to use addresses like:
> 
>     C-x C-f /etc/passwd
> 
> to configure their Apache, Inetd, Squid, Exim and
> other nifty stuff that can now be used natively under Windows.

You've just contradicted yourself, I think: to support /etc/passwd
like in the above example, we do need to handle Cygwin-style file
names everywhere in Emacs, because Emacs needs to know about the
Cygwin mount points.

> To require perfection before anything can be added to Emacs is
> a sad paths for Emacs.

I didn't require perfection.  A good solution doesn't have to be
perfect, but it should be reasonably reliable, IMHO.  If it hides
subtle bugs and misfeatures, it's broken.

> Cygwin is an Unix emulation, it should not understand DOS style
> paths at all.

As I explained earlier, there's no contradiction here.  Cygwin
applications could support both styles.

> How the heck would a pure Unix application understand configuration
> file that would include dos paths?

By passing the file names unchanged into the Windows API.

> You can't expect to change 10 000 unix applications to support DOS
> paths.

Please re-read my messages in gnu.emacs.help: the changes are already
there in the sources, they just need to be used by the Cygwin build
(by simple modifications of the existing C preprocessor macros).

> Cygwin cannpt solve that in their libraries, because the application
> use the paths, not Cygwin.

That's true.

> Emacs is at least now pure windows application, so it understandas
> DOs paths. But it could be taught to understand cygwin paths and
> that change is small in the scope where cygwin paths are mainly
> used.

That's the crux of this argument: I don't think the change is small.

_______________________________________________
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

cygwin-mount.el (Was Re: Using GDB in NTEMACS)

[Jari Aalto+mail.emacs]

* 2002-02-22 Jason Rumney <jasonr@gnu.org> list.emacs-devel
* Message-Id: <m37kp5s024.fsf@nyaumo.btinternet.com>
| "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.  

I'm not sure they will. Perhaps only you want 100% correctness?

I have never wanted anything more that what cygwin-mount.el provides
and I have used Cygwin for a very long time. 

Maybe there is a misunderstanding what cygwin + Emacs users want. In
my understanding (just go to Windows Emacs mailing list), they are not
interested in full 100% compatibility in Emacs lisp function level,
they just want tighter co-operation.

And that's what is offered by cygwin-mount.el

The ambitious goal could be 100%, but who needs it?
If there is no need for it, why set a goal to 100%. I would't.

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

That's sad. Very sad. With this statement you all Windows users
continue complaining why Emacs does not help them to use Cygwin
environment more easily. They keep asking why Emacs still holds more
to it's "ideals" and does not answer to what users really need.

I think it is evident enough by now that they want tighter Cygwin 
co-operation. We should provide that, and not hold on to 100% goals
that are not needed by users.

Jari

-- 
http://tiny-tools.sourceforge.net/
Swatch  @time http://www.ryanthiessen.com/swatch/resources.htm
Convert @time http://www.mir.com.my/iTime/itime.htm


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

Re: cygwin-mount.el (Was Re: Using GDB in NTEMACS)

[Eli Zaretskii]

> From: letters@hotpop.com (Jari Aalto+mail.emacs)
> Date: Sat, 23 Feb 2002 11:29:27 +0200
> 
> all Windows users continue complaining why Emacs does not help them
> to use Cygwin environment more easily.

They should complain to Cygwin developers.

I asked before, and I'll ask again: did someone try to talk to the
Cygwin developers about this issue?  Did someone ask them what do
they think about supporting Windows file names better, and if so,
what did they reply?

It strikes me that an important party to this discussion is strangely
absent.

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

Emacs for Cygwin (was: cygwin-mount.el, Using GDB in NTEMACS)

[Ehud Karni]

Below is Eli Zaretskii mail from 23 Feb 2002.

I think that we need a CygEmacs - an emacs that will be compiled with
the real Cygwin ported gcc (i.e. without the -mno-cygwin). CygEmacs
will have UNIX APIs for I/O (files and sockets), and M$Windows APIs
for the display and the keyboard. This is already done (partly) by the
Cygwin port of rxvt.

If this is too difficult, may be a version of Emacs for Cygwin, that
use only the UNIX APIs can be ported. This Emacs version will be used
only within Cygwin's windows - Console or rxvt (Emacs in TTY mode) or
real display (using Cygwin-Xfree).

Any of these version will solve the 2 major issues of using Emacs with
Cygwin - 1. The files (names and attributes). 2. Running of sub-shells
in Emacs (file is not tty problem). It may solve another problem that
bothers me - running a client on the PC to a server on UNIX.

Ehud.


    --------------- Original Eli's mail ---------------

> From: letters@hotpop.com (Jari Aalto+mail.emacs)
> Date: Sat, 23 Feb 2002 11:29:27 +0200
> 
> all Windows users continue complaining why Emacs does not help them
> to use Cygwin environment more easily.

They should complain to Cygwin developers.

I asked before, and I'll ask again: did someone try to talk to the
Cygwin developers about this issue?  Did someone ask them what do
they think about supporting Windows file names better, and if so,
what did they reply?

It strikes me that an important party to this discussion is strangely
absent.


-- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.simonwiesel.co.il          Better  Safe  Than  Sorry

_______________________________________________
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