From: Drew Adams <drew.adams@oracle.com>
To: Achim Gratz <Stromeko@nexgo.de>, 14541@debbugs.gnu.org
Subject: bug#14541: 24.3.50; `ediff-buffers' does not play well with recent Cygwin version
Date: Wed, 5 Jun 2013 16:55:01 -0700 (PDT) [thread overview]
Message-ID: <9db8fa66-43bf-4d68-841d-8ddb3c1a65cf@default> (raw)
In-Reply-To: <87a9n41fe0.fsf@Rainer.invalid>
> You are putting this file on EmacsWiki for others to use, aren't you?
Yes, I am. To use if they want to. I put a lot of stuff on Emacs
Wiki for others to use. Some of it good, some of it no doubt not
as good. And I will continue to do so, until I stop hacking Emacs.
I put code (and doc and...) on the wiki for anyone who finds it
helpful and wants to use it. Anyone who does not want to use it
need not use it. Anyone who wants to use setup-cygwin.el as
inspiration for their own, better setup file is welcome to copy &
adapt it. They are also welcome to ignore it altogether. It is
offered as is - no guarantees.
You clearly have your idea of what can be helpful; I have mine.
I know that this file has helped people. And I don't know of
anyone who has been harmed by its existence. But no doubt we
can do better - please do!
> Secondly, that warning is there for a reason, so simply switching
> it off certainly isn't going to do the right thing for everyone.
No one says that switching it off pretends to do the right thing
for everyone. (Like Cygwin, for that matter, or even Emacs...)
Are you always this black & white?
Surely, turning it off (or on) for everyone would *NOT* DTRT for
everyone. Otherwise there would be no need for the switch.
Where you go wrong (apparently) is assuming that setup-cygwin.el
is for everyone. And (seemingly) that if it is not good for
everyone then it cannot be good for anyone.
> >> Don't. You might override other settings that the user wants to take
> >> effect or at best produce a confusing no-op. You'd be much better off
> >> if you would use cygpath to convert to POSIX instead.
> >
> > I'll leave it in setup-cygwin.el, at least for now. But I'll add a
> > comment per what Eli said: that if come other Cygwin process started
> > earlier and turned this off then turning it on here has no effect.
>
> Again: it simply doesn't work the way you think it works.
I like how you are so certain of what I think. ;-) Should we judge
your certainty about Cygwin and Emacs similarly? I hope not.
> The comment isn't helping that issue in any way.
I disagree. I believe there are others who, like me, use Cygwin
mainly to provide `grep' etc. to Emacs. There are also people who
do not even know how to set an env var in Windows, or might be
hesitant to do so. For such a user, this file likely - typically
- will get Emacs working with Cygwin.
The real shame is that Cygwin no longer works with Emacs out of the
box. From my perspective, which is admittedly limited wrt Cygwin,
that's more or less a regression. (Perhaps I should have hung onto
my old version of Cygwin...)
And the thing about the env var being cached and looked up only by
the first Cygwin process seems downright perverted. I repeat:
from my limited and ignorant perspective. I have used Emacs on
Windows with Cygwin for many moon (decades). Always in a limited
way, but always with no particular problem.
> It is wrong to do this in setup-cygwin.el even when you want this
> environment variable to have exactly that value.
Wrong? Feel free to provide an Emacs setup file that "DTRT for
everyone" all the time. Feel free to point out, on the wiki or
anywhere else, that setup-cygwin.el is wrong, bad, evil, or
whatever.
But especially, please do provide something better. I will be
the first to use it and to point others to it, believe me!
I posted setup-cygwin.el because it took me a while to piece
together the stuff it contains, and I found that I needed it, in
addition to cygwin-mount.el. I don't know or imagine that
everyone needs it.
I make no claim about its contents being 100% correct or complete.
Far from it. It is a hack job born out of ignorance. It is just
something I have used and still use. And I know it has helped
others too, regardless of its probably being "wrong" in more than
one way.
And I'll be glad to use something better, when I come across it.
> It must already be set before Emacs gets started.
Not as far as I can see. Not for the case I use it for: using
Cygwin almost exclusively with Emacs. In that use case, the
first Cygwin process is launched by Emacs.
I do understand that setting the env var is better (and is sure).
I understand that it is needed if you expect to use Cygwin outside
Emacs, to be sure that the first Cygwin process sees the same
value.
But setup-cygwin.el works for the simple Emacs-only use case -
just in case you have not set the env var .
> > Sounds like the only good approach for an Emacs user on Windows, with
> > Cygwin installed, is to set the env var at the system level. If that
> > is the case (please confirm) then I'll mention that too in a
> > setup-cygwin.el comment. (And we might want to mention that in the
> > Emacs manual?)
>
> The only way to have it working reliably is to set it from the
> system panel, then log off and on again.
Sounds right to me. And Eli too confirmed that.
But wasn't it you, BTW, who said that an alternative (presumably
working reliably) is to "use cygpath to convert to POSIX instead"?
Eli was more definitive, seemingly rejecting that alternative you
mentioned, when he confirmed "That's the _only_ way, yes."
Of course, "working reliably" is a strange term for a workaround
for such a hack (apparently) as this exceptional env var presents.
It may work reliably, but it seems to be a weird way of doing
things (the caching/one-time-lookup, I mean).
(Thinking that it seems weird does not mean that I have a better
idea for Cygwin, obviously. Presumably this hack was the best
approach available.)
> I'm not sure what you want Emacs to document: the problem is that you
> are using non-Windows tools together with a Windows Emacs and you aren't
> correctly converting the different path conventions by these tools and
> Emacs. That is not a Cygwin problem and not an Emacs problem.
Fair enough (though Cygwin is a Windows tool, AFAIK). Nevertheless,
at least for the uses I make of Cygwin with Emacs, it seems to work
fine (once the env var is set), and it has for decades (without the
env var).
Now, if I used Cygwin as a *developer* on Windows (outside Emacs),
that might be different, as Eli has pointed out in the past.
I don't doubt that there is an impedance mismatch between Windows
Emacs and Cygwin, if you look hard enough. For what I do, however,
I haven't run into it, so far. I make no claim for anyone else.
> > OK, I suppose that's not the only good approach. I guess you're
> > suggesting another, for someone who is willing to change to POSIX:
> > use the cygpath utility. Feel free to document that one (for Emacs
> > users)...
>
> Actually, emacs-w32 from Cygwin is much better in almost all regards and
> doesn't have the problem to begin with because it never uses any Windows
> path names.
Aha - that's where you're coming from. Thanks, but no thanks.
I will stick with vanilla GNU Emacs. (Call me wrong.)
But I am sure both you and Eli are right that the combination of
Windows Emacs with Cygwin is not ideal for either. It happens that
it works well enough for me, and it's the package I prefer - so far.
Sorry about that.
IMO, it would be good if Cygwin played better with Windows Emacs.
But I have no idea how feasible or difficult that would be to realize.
next prev parent reply other threads:[~2013-06-05 23:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<7d461150-fe55-4278-bb7a-22fc24811364@default>
[not found] ` <<83hahfxkw9.fsf@gnu.org>
2013-06-03 16:21 ` bug#14541: 24.3.50; `ediff-buffers' does not play well with recent Cygwin version Drew Adams
2013-06-03 16:37 ` Eli Zaretskii
2013-06-03 16:50 ` Achim Gratz
2013-06-03 20:15 ` Drew Adams
2013-06-03 20:23 ` Eli Zaretskii
2013-06-05 20:17 ` Achim Gratz
2013-06-05 23:55 ` Drew Adams [this message]
2013-06-06 19:07 ` Achim Gratz
2013-06-06 20:21 ` Eli Zaretskii
2022-02-13 9:26 ` Lars Ingebrigtsen
2013-06-06 20:42 ` Drew Adams
2013-06-03 4:12 Drew Adams
2013-06-03 15:40 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9db8fa66-43bf-4d68-841d-8ddb3c1a65cf@default \
--to=drew.adams@oracle.com \
--cc=14541@debbugs.gnu.org \
--cc=Stromeko@nexgo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.