Cut and paste in Cygwin XEmacs
Mike Spertus
home, C-k, C-w, M-w and Sh-Ins cut to, copy to and paste from the
Windows clipboard (which is what I want). At the office, none of my
commands interact with the Windows clipboard, (although they work
properly within XEmacs) making it difficult for me to cut and paste
between XEmacs and Windows applications. How can I fix this?
Thanks,
Mike
RMM
news:4bb78b23.03111...@posting.google.com:
Does anyone know anything about this? I have the same problem.
On a Windows 2000 machine I have both native XEmacs and cygwin
XEmacs 21.4.13 installed. The native version handles the Windows
clipboard as expected, but the cygwin version doesn't.
I suppose one solution would be to just ditch the cygwin version.
However, I prefer it because I can then share files (like
.emacs and .emacs.bmk) that contain unix-style paths across
windows and unix without fuss. However, I tend to find the
cygwin version a little more problematic in general.
Comments?
Thanks
Maarten Bergvelt
> Mike.S...@veritas.com (Mike Spertus) wrote in
> news:4bb78b23.03111...@posting.google.com:
>
>> I have Cygwin XEmacs installed both at home and at the office. At
>> home, C-k, C-w, M-w and Sh-Ins cut to, copy to and paste from the
>> Windows clipboard (which is what I want). At the office, none of my
>> commands interact with the Windows clipboard, (although they work
>> properly within XEmacs) making it difficult for me to cut and paste
>> between XEmacs and Windows applications. How can I fix this?
> Does anyone know anything about this? I have the same problem.
This is what our system administrator told me:
------
Copy and paste is actually fairly easy to set up.... Simply right
mouse click on the Cygwin in the Taskbar, and choose "Properties".
From here you get an old style DOS property box. On the right side
middle of the first tab there is a check box for "QuickEdit Mode".
Simply check this box and tell it to "Apply to all windows opened by
this shortcut" (not the exact quote I think, but close). This allows
normal copy from Windows to the clipboard, and a right mouse click in
the UNIX side pastes it in...
------
another way is to start in cygwin xwinclip.
Hope this helps,
--
Maarten Bergvelt
Rick Rankin
"RMM" <morelli@n+o+s+p+a+m.cs.utah.edu> wrote in message
news:Xns943A6C0101DA3...@216.196.97.136...
What version of Cygwin are you running? Early 1.5.x versions had a problem
where cut-n-paste would stop working with the Windows clipboard after you
executed any sort of shell command. With the current Cygwin release
(1.5.5-1), I have no problems using cut-n-paste with either the current 21.4
release or 21.5 beta.
--Rick
P.S. I build my own XEmacs (Cygwin/native, no X11); I don't use the
netinstaller.
Mike Spertus
office. As I said above, I have this problem at work but not at home.
Mike Spertus
uses the clipboard on XP but not on 2000. This is what I experienced
also. I'll post a bug now.
Mike
Mike.S...@veritas.com (Mike Spertus) wrote in message news:<4bb78b23.03112...@posting.google.com>...
Pete Forman
> I suppose one solution would be to just ditch the cygwin version.
> However, I prefer it because I can then share files (like
> .emacs and .emacs.bmk) that contain unix-style paths across
> windows and unix without fuss. However, I tend to find the
> cygwin version a little more problematic in general.
Windows will accept / as a path separator. I find that using relative
paths works for most files across Windows and Unix.
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pete....@westerngeco.com -./\.- opinion of Schlumberger, Baker
http://petef.port5.com -./\.- Hughes or their divisions.
RMM
> As Thomas Link has confirmed, Cygwin XEmacs cut-and-paste correctly
> uses the clipboard on XP but not on 2000. This is what I experienced
> also. I'll post a bug now.
>
> Mike
>
Can anyone suggest a release of cygwin XEmacs that's still easy to
install but relatively free of serious problems? I installed 21.4.13
in an attempt to escape some fairly serious problems in an earlier release
of 21.4, the worst of which was a tendency to go into an infinite loop
while filling paragraphs. I don't want to go back to that (assuming it
was fixed in release 13), but the lack of cut and paste makes release
13 fairly untenable.
Suggestions? Alternatives?
Thanks
RMM
news:smkdsp...@westerngeco.com:
> RMM <morelli@n+o+s+p+a+m.cs.utah.edu> writes:
> > I suppose one solution would be to just ditch the cygwin version.
> > However, I prefer it because I can then share files (like
> > .emacs and .emacs.bmk) that contain unix-style paths across
> > windows and unix without fuss. However, I tend to find the
> > cygwin version a little more problematic in general.
>
> Windows will accept / as a path separator. I find that using relative
> paths works for most files across Windows and Unix.
I'm not sure what you mean by "using relative paths." Do you mean
that you set some locations like home directory and /usr as absolute
paths in .emacs according to platform (using the value of "running-x" for
instance) and make everything relative to those? That would work
for some things. What about situations where XEmacs specifies the
path (like when you save a bookmark or in recent-files etc.). Do
you have a global way of dealing with all of that?
I curious why you go through the trouble? What advantage does
native XEmacs have over cygwin XEmacs for a unix user? Do you find
that it is more reliable, or is there some other advantage?
Pete Forman
> Pete Forman <pete....@westerngeco.com> wrote in
> news:smkdsp...@westerngeco.com:
>
> > RMM <morelli@n+o+s+p+a+m.cs.utah.edu> writes:
> > > I suppose one solution would be to just ditch the cygwin version.
> > > However, I prefer it because I can then share files (like
> > > .emacs and .emacs.bmk) that contain unix-style paths across
> > > windows and unix without fuss. However, I tend to find the
> > > cygwin version a little more problematic in general.
> >
> > Windows will accept / as a path separator. I find that using relative
> > paths works for most files across Windows and Unix.
>
> I'm not sure what you mean by "using relative paths." Do you mean
> that you set some locations like home directory and /usr as absolute
> paths in .emacs according to platform (using the value of "running-x" for
> instance) and make everything relative to those? That would work
> for some things. What about situations where XEmacs specifies the
> path (like when you save a bookmark or in recent-files etc.). Do
> you have a global way of dealing with all of that?
Not really. There are a few things like:
(custom-set-variables
'(gnus-kill-files-directory "~/News/.score")
...
> I curious why you go through the trouble? What advantage does
> native XEmacs have over cygwin XEmacs for a unix user? Do you find
> that it is more reliable, or is there some other advantage?
My grounding is in Unix but for the last few years I've used a Windows
box on my desktop. I work on several remote Unix hosts using a mix of
PuTTY and VNC. Samba is used to edit files; occasionally Tramp too.
When I started using XEmacs on Windows there were one or two things
that worked in native but not in the Cygwin version. I'm afraid that
I don't recall what they were and indeed they may be fixed by now.
Perhaps one reason was printing to Windows printers.
I do have Cygwin installed and so things like ediff and grep work fine
in native XEmacs.
What it probably boils down to is whether you are happy switching
between \ and /. Personally I'm happier using native naming and put
up with flicking an internal switch. I don't feel the need to treat
Windows as if it was Unix but YMMV.
Coming back to your question, what pros and cons are there between
native and Cygwin nowadays? I'd look at Cygwin again if something
didn't work in native. The only major drawback for me at the moment
is lack of support for UTF-8.
Stephen J. Turnbull
RMM> Can anyone suggest a release of cygwin XEmacs that's still
RMM> easy to install but relatively free of serious problems?
All of them. But you have to revert your Cygwin installation.
Not a happy suggestion, either, I know. But the guy who does most of
this work for us got badly burned by Cygwin churn about a year or so
ago, and has been unwilling to update until he gets time to deal with
Cygwin changes on top of any XEmacs issues. Unfortunately, his
employer has lots of work for him, too....
We really need more people hacking on XEmacs for Windows.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
Rick Rankin
"Stephen J. Turnbull" <ste...@xemacs.org> wrote in message
news:87k75mf...@tleepslib.sk.tsukuba.ac.jp...
> >>>>> "RMM" == RMM <morelli@n+o+s+p+a+m.cs.utah.edu> writes:
>
> RMM> Can anyone suggest a release of cygwin XEmacs that's still
> RMM> easy to install but relatively free of serious problems?
>
> All of them. But you have to revert your Cygwin installation.
>
> Not a happy suggestion, either, I know. But the guy who does most of
> this work for us got badly burned by Cygwin churn about a year or so
> ago, and has been unwilling to update until he gets time to deal with
> Cygwin changes on top of any XEmacs issues.
Hmm... I've been using XEmacs on Cygwin for a long time with no significant
problems, and I always keep my Cygwin installation very current. Now
admittedly, there are a large number of XEmacs features that I don't use
(gnus, mail, et. al.). Still, as a developer, I spend a large part of almost
every day in Cygwin/XEmacs. I wouldn't even think of using it if it weren't
pretty stable.
Now until recently, I couldn't use any of the 21.5 betas because cut-n-paste
was broken in them. I kept getting a message about "variable's value is
void: region", or something like that. I reported the problem to the
xemacs-beta list several months ago. I always believed that this was an
XEmacs problem because cut-n-paste worked fine in 21.4. However, this
problem seems to have "gone away", and I'm happily using 21.5b16 on Cygwin
with no problems.
I guess part of what I'm trying to say is that instead of encouraging people
to revert their Cygwin installation, that they *first* make sure that their
Cygwin installation is completely up to date. Perhaps even install a
snapshot cygwin1.dll because problems are being fixed all the time. I say
this because they won't get *any* help at all from the Cygwin list for
reverting to a previous version, and the Cygwin people don't keep old
distributions around, so they're pretty hard to come by.
> Unfortunately, his
> employer has lots of work for him, too....
>
> We really need more people hacking on XEmacs for Windows.
>
Well, I've been wanting to take a more active role, at least in terms of
finding and fixing problems. I don't know if I'd have time to work on new
features, though. Hmm... guess I'll have to think about learning lisp ;-)
--Rick
Stephen J. Turnbull
Rick> they *first* make sure that their Cygwin installation is
Rick> completely up to date.
That makes sense.
My problem is that as a non-Windows user/developer I can only really
recommend what I have been told definitely works. I find Windows very
unfriendly to support, because every time I get close to the answer to
the question I'm really asking, Windows Help says "Please contact your
System Administrator"! I think Microsoft is trying to sell me an MCSE
correspondence course. :-( And the XEmacs Windows-specific docs are
not all that much better.
Rick> Perhaps even install a snapshot cygwin1.dll because problems
Rick> are being fixed all the time.
Problem is, if they go beyond current release, APIs might change,
right? My understanding is that a lot of the problem with XEmacs on
Cygwin (and Windows XP, for that matter) have to do with use of older
APIs that didn't really work right, so they've been replaced.
Rick> the Cygwin people don't keep old distributions around, so
Rick> they're pretty hard to come by.
Shoulda figured that. OK, scratch that recommendation.
Rick> Well, I've been wanting to take a more active role, at least
Rick> in terms of finding and fixing problems. I don't know if I'd
Rick> have time to work on new features, though. Hmm... guess I'll
Rick> have to think about learning lisp ;-)
Believe me, just having a reasonably experienced user/developer,
somebody who's actually been working with XEmacs on the platform over
the last couple of years, speaking up in c.e.x and other XEmacs
channels is a _major_ contribution.
Andy and Ben are very good at what they do, but neither has a
support-type personality, and Andy's stuff (most of the GUI,
especially on Windows) is basically undocumented outside of the
sources. As is the netinstaller -- after the platform changes (new
Cygwin, Windows XP), I'd say one of our biggest problems on Windows is
that people's packages installations get wedged because the
netinstaller and XEmacs's native package management disagree slightly
on how things are done.
While I can't give you a shopping list at the moment, if you want to
invest some of your spare time in XEmacs, hang out a bit on c.e.x and
xemacs-beta (I haven't checked recently, but I think most of the
traffic from xemacs-winnt moved to -beta), and help us build up
Google-able archives of Windows wisdom.
Of course if you can help us with the XEmacs vs. Cygwin 1.5/Windows XP
issues, that would be really great.
Thanks for posting!
Rick Rankin
> >>>>> "Rick" == Rick Rankin <rickr...@nospam.net> writes:
>
> Rick> they *first* make sure that their Cygwin installation is
> Rick> completely up to date.
>
> That makes sense.
>
> My problem is that as a non-Windows user/developer I can only really
> recommend what I have been told definitely works. I find Windows very
> unfriendly to support, because every time I get close to the answer to
> the question I'm really asking, Windows Help says "Please contact your
> System Administrator"! I think Microsoft is trying to sell me an MCSE
> correspondence course. :-( And the XEmacs Windows-specific docs are
> not all that much better.
>
> Rick> Perhaps even install a snapshot cygwin1.dll because problems
> Rick> are being fixed all the time.
>
> Problem is, if they go beyond current release, APIs might change,
> right?
Not really, at least not in my experience. Certainly the POSIX-compliant
APIs shouldn't change. There are some Cygwin-specific API calls, but I
wasn't aware that there was ever that much churn in them. But then again, I
don't use them that much. Without looking at the XEmacs code in more detail,
I'm not sure why it would need to make use of the internal calls. There's
only a handful of them, and the majority of them deal with path handling, so
unless XEmacs is doing conversions from POSIX-style paths to Windows-style
paths, then calling the native Windows API functions with the Windows-style
path, they're not really much use.
Chris Faylor, the Cygwin lead developer, has always maintained that the DLLs
are *supposed* to be binary compatible, i.e., if it works on 1.3.x, it
should work on 1.5.x. I used XEmacs 21.4.x compiled against Cygwin 1.3 on
Cygwin 1.5 for quite a while with no significant problems before I rebuilt
against Cygwin 1.5. However, it's certainly true that an application built
against Cygwin 1.5 will not work on Cygwin 1.3.
> My understanding is that a lot of the problem with XEmacs on
> Cygwin (and Windows XP, for that matter) have to do with use of older
> APIs that didn't really work right, so they've been replaced.
Possible, I suppose. Without more detail, I can't speak to that issue.
>
> Rick> the Cygwin people don't keep old distributions around, so
> Rick> they're pretty hard to come by.
>
> Shoulda figured that. OK, scratch that recommendation.
>
> Rick> Well, I've been wanting to take a more active role, at least
> Rick> in terms of finding and fixing problems. I don't know if I'd
> Rick> have time to work on new features, though. Hmm... guess I'll
> Rick> have to think about learning lisp ;-)
>
> Believe me, just having a reasonably experienced user/developer,
> somebody who's actually been working with XEmacs on the platform over
> the last couple of years, speaking up in c.e.x and other XEmacs
> channels is a _major_ contribution.
>
> Andy and Ben are very good at what they do, but neither has a
> support-type personality, and Andy's stuff (most of the GUI,
> especially on Windows) is basically undocumented outside of the
> sources. As is the netinstaller -- after the platform changes (new
> Cygwin, Windows XP), I'd say one of our biggest problems on Windows is
> that people's packages installations get wedged because the
> netinstaller and XEmacs's native package management disagree slightly
> on how things are done.
>
> While I can't give you a shopping list at the moment, if you want to
> invest some of your spare time in XEmacs, hang out a bit on c.e.x and
> xemacs-beta (I haven't checked recently, but I think most of the
> traffic from xemacs-winnt moved to -beta), and help us build up
> Google-able archives of Windows wisdom.
>
Well, I'm not exactly a support-type personality, either. I always figured
that 5 minutes in any support organization would be enough to get me fired
;-) I've been subscribed to both xemacs-winnt and -beta for a while, but I
don't read the newsgroups too often, once or twice a week, mabye. Time
permitting, I'll try to answer Cygwin-related questions. I don't use the
native version at all, so I won't be much help there, but it seem's like
Adrian answers many of those.
> Of course if you can help us with the XEmacs vs. Cygwin 1.5/Windows XP
> issues, that would be really great.
Is there a list of issues somewhere? I see them come up on the mailing
lists, but if I'm not experiencing (or haven't experienced) the issue, or if
they occur in areas of the program I don't use (gnus, mail, etc.), I often
don't pay too much attention to them.
--Rick
Stephen J. Turnbull
Rick> There's only a handful of them, and the majority of them
Rick> deal with path handling, so unless XEmacs is doing
Rick> conversions from POSIX-style paths to Windows-style paths,
Rick> then calling the native Windows API functions with the
Rick> Windows-style path,
I wouldn't be surprised; path-handling is one of the bugbears.
>> Of course if you can help us with the XEmacs vs. Cygwin
>> 1.5/Windows XP issues, that would be really great.
Rick> Is there a list of issues somewhere? I see them come up on
Rick> the mailing lists, but if I'm not experiencing (or haven't
Rick> experienced) the issue, or if they occur in areas of the
Rick> program I don't use (gnus, mail, etc.), I often don't pay
Rick> too much attention to them.
Not really. I've tried to maintain such things in the past, but it's
a big job just to read all the relevant channels.
I'm trying to get an issue tracker put together, but one of the
important criteria is that we can dump the existing list archives into
it and get something searchable, and all of the usual suspects are
heavily web-oriented.
If nothing else attracts your attention, just correct me when I say
something boneheaded. :-)
RMM
>>>>>> "RMM" == RMM <morelli@n+o+s+p+a+m.cs.utah.edu> writes:
>
> RMM> Can anyone suggest a release of cygwin XEmacs that's still
> RMM> easy to install but relatively free of serious problems?
>
> All of them. But you have to revert your Cygwin installation.
>
> Not a happy suggestion, either, I know. But the guy who does most of
> this work for us got badly burned by Cygwin churn about a year or so
> ago, and has been unwilling to update until he gets time to deal with
> Cygwin changes on top of any XEmacs issues. Unfortunately, his
> employer has lots of work for him, too....
>
> We really need more people hacking on XEmacs for Windows.
Given that, it's a shame that 2 versions have to be maintained (not
to mention the MinGW version, and of course the emacs versions).
In theory, the cygwin version makes a lot of sense for people who
are primarily unix users (like myself), and in practice the whole
cygwin system works surprisingly well for some things. However,
getting that last 1% to work ...
For me, the main distinction between the cygwin and the native
versions is path handling. I'd probably be pretty happy with
native XEmacs if there were a global switch that made it deal
with file names exactly like the cygwin version does. I don't
suppose that's in the works though.
Stephen J. Turnbull
RMM> For me, the main distinction between the cygwin and the
RMM> native versions is path handling. I'd probably be pretty
RMM> happy with native XEmacs if there were a global switch that
RMM> made it deal with file names exactly like the cygwin version
RMM> does. I don't suppose that's in the works though.
Nice try. According to Robert Collins, that's about 18 man-months'
worth of work, IIRC.
Steven E. Harris
> I've been using XEmacs on Cygwin for a long time with no significant
> problems, and I always keep my Cygwin installation very current. Now
> admittedly, there are a large number of XEmacs features that I don't
> use (gnus, mail, et. al.). Still, as a developer, I spend a large
> part of almost every day in Cygwin/XEmacs. I wouldn't even think of
> using it if it weren't pretty stable.
Are you using Windows XP? That's where the problem is. XEmacs atop
Cygwin 1.5x on XP suffers from problems interacting with spawned
processes, such as sub-shells, any ftp operations, and igrep. Adding
"tty" to the CYGWIN environment variable helps somewhat; getting a
fresh Cygwin snapshot also makes some of these problems go away.
Most of the noise I've witnessed relates to XEmacs and Cygwin, but I
notice other significant problems in Cygwin 1.5x, mostly related to
closing network connections. (OpenSSL and rsync are the ones I use and
suffer with most frequently.) On the cygwin mailing list there's been
discussion of a certain "select() bug" that may be the root cause for
these problems. I haven't had the time to install a recent snapshot to
see if the problems go away.
Fixes are definitely in progress, but the current Cygwin 1.5x release
will frustrate XEmacs users on Windows XP.
--
Steven E. Harris :: seha...@raytheon.com
Raytheon :: http://www.raytheon.com
Mike Spertus
> As Thomas Link has confirmed, Cygwin XEmacs cut-and-paste correctly
> uses the clipboard on XP but not on 2000. This is what I experienced
> also. I'll post a bug now.
>
> Mike
>
a cygwin 1.5.5-1 bug. Inserting a new cygwin1.dll from the latest
snapshot fixed the problem.
Rick Rankin
"Steven E. Harris" <seha...@raytheon.com> wrote in message
news:q67ad6c...@raytheon.com...
> "Rick Rankin" <rickr...@nospam.net> writes:
>
> > I've been using XEmacs on Cygwin for a long time with no significant
> > problems, and I always keep my Cygwin installation very current. Now
> > admittedly, there are a large number of XEmacs features that I don't
> > use (gnus, mail, et. al.). Still, as a developer, I spend a large
> > part of almost every day in Cygwin/XEmacs. I wouldn't even think of
> > using it if it weren't pretty stable.
>
> Are you using Windows XP? That's where the problem is. XEmacs atop
> Cygwin 1.5x on XP suffers from problems interacting with spawned
> processes, such as sub-shells, any ftp operations, and igrep.
No, I'm not using XP, but XEmacs also had these problems on W2K until I
installed a later snapshot. I'm currently using the 11/27 snapshot and
everything is working quite well, including rsync et.al.
--Rick
Steven E. Harris
> No, I'm not using XP, but XEmacs also had these problems on W2K
> until I installed a later snapshot.
Weird. I run Cygwin on Windows 2000 at work and I never noticed any of
the problems that I do at home on Windows XP. In both cases, Cygwin is
up to date with the latest versions available through the net
installer. Hence, the Cygwin versions are kept in parallel, as is the
XEmacs configuration, with vastly different observed behavior. The
only remaining explanation was the underlying operating system.