Re: Emacs problem after rebaseall: some progresses?
Angelo Graziosi [EMAIL PROTECTED] writes: As you can see in the mailing lists, I have posted this question a few times. Now I have discovered somethings at which you can give a more adeguate answer. The problem is that after rebaseall Emacs does not works, it takes all the CPU and its window does not appear so that one can only kill its process. After the new release of rebase-2.4-1, the problem remains BUT this time reinstalling, with setup, ONLY the package libncurses7 (whose current release is 5.3-4), EMACS works again! Rebasing all and then reinstalling a package that has just rebased : is it a valid procedure? Or should one expect that some other application does not work any more? Actually, I don't have an idea if this is a valid procedure. And to be honest, at this moment I don't even care. But today I ran into the same problem - and your trick just works for me, too. Many many thanks for posting this workaround. I guess it took you some hours to detect libncurses7 as a key component, but you certainly saved me the pain to try to re-install all cygwin. -- Cheers, haj -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
Angelo Graziosi wrote: After the new release of rebase-2.4-1, the problem remains BUT this time reinstalling, with setup, ONLY the package libncurses7 (whose current release is 5.3-4), EMACS works again! Rebasing all and then reinstalling a package that has just rebased : is it a valid procedure? Sure, this is fine. But what you're really saying is that one of the dlls in libncurses7 used by xemacs /usr/bin/cygform7.dll /usr/bin/cygmenu7.dll /usr/bin/cygncurses7.dll /usr/bin/cygpanel7.dll is not rebase-able. I'm not clear on the history; there was a time when a number of DLLs were considered not rebase-able but I don't remember why, or whether the issue was ever fixed (in rebase.exe, or in the DLLs themselves). *I* wonder, if xemacs were rebuilt against the CURRENT ncurses libraries (libncurses8), would it still have similar problems -- e.g. would you need to rebaseall and then reinstall libncursesEIGHT? If so, it's a problem I need to track down, as the ncurses maintainer. If not, then the XEmacs maintainer should simply release a new version, recompiled against the new ncurses. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
On Fri, 16 Sep 2005, Harald Joerg wrote: Angelo Graziosi [EMAIL PROTECTED] writes: The problem is that after rebaseall Emacs does not works, it takes all the CPU and its window does not appear so that one can only kill its process. After the new release of rebase-2.4-1, the problem remains BUT this time reinstalling, with setup, ONLY the package libncurses7 (whose current release is 5.3-4), EMACS works again! Actually, I don't have an idea if this is a valid procedure. And to be honest, at this moment I don't even care. But today I ran into the same problem - and your trick just works for me, too. Many many thanks for posting this workaround. I guess it took you some hours to detect libncurses7 as a key component, but you certainly saved me the pain to try to re-install all cygwin. Even using the snapshots, the problem remains and every time one needs to rebase all one must reinstall libncurses7-5.3-4 if one wants Emacs to work. In any case I am on the alert to see what cause that. Best regards, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
On Fri, Sep 16, 2005 at 07:26:26PM +0200, Angelo Graziosi wrote: Even using the snapshots, the problem remains and every time one needs to rebase all one must reinstall libncurses7-5.3-4 if one wants Emacs to work. Since this has nothing to do with Cygwin, AFAICT, there is no reason to think that a snapshot would fix the problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Page Up and Page Down
Hi. I have what appears to be a plain US 104-key keyboard manufactured by/for Compaq. Using xterm, when I press the Pg Up key on the number keypad, I get the character sequence ^[[5~ and I get ^[[6~ for Pg Dn (^[ is actually a single character, escape). However, the Page Up and Page Down keys in that middle section between the number pad and main keyboard area produce different sequences, ^[Or and ^[Ou respectively. On my Linux box at home, I believe xterm always produces ^[[5~ and ^[[6~ I also use PuTTYcyg [http://gecko.gc.maricopa.edu/~medgar/puttycyg/] to use the Cygwin command line (since the Windows Command Prompt window royally sucks). It produces ^[[5~ and ^[[6~ for everything. (By the way, if you're at a command prompt, you can see what the shell is seeing by typing ^V prior to pressig the key.) Anyway, I've looked through the app-defaults for xterm, and haven't found anything obvious, so this must be hidden somewhere else. I'm not aware of anything I might have changed to cause this to happen. It is problematic, since vim expects the sequence produced by the keypad buttons, rather than the ones produced by the middle keys. TERM is set to 'xterm' in both xterm and PuTTYcyg. -- [ Michael Hicks | [EMAIL PROTECTED] ] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
My attempt to use Cygwin seems doomed to failure in spite of...
... all the willing help I've received - esp from Reid. I do appreciate you all taking the time to give me info and clues etc. My conclusion is there is something on my system that prevents Xwin.exe and / or xterm.exe from completely initialising. I've removed most of the original text of this apend, as while I was closing down my stuff, I spotted something! From FAQ 7.6. Why does Cygwin/X freeze right after startup? Zone Alarm 5 is known to break Cygwin/X. As a result you'll see this line (or a similar) as last output in /tmp/XWin.log Rules = xorg Model = pc101 Layout = us Variant = (null) Options = (null) Disabling Zone Alarm will not solve this problem. You can only uninstall Zone Alarm 5 and switch to an earlier version (4.5 is known to work) or use a different personal firewall. I found this, but it is NOT in the xwin.log. By chance this time, I had started xwin.exe in a cmd prompt and I could see the stdout messages. These are pretty much what's in the log, except for the last line! == Rules = xorg Model = pc105 Layout = gb Variant = (null) Options = (null) So, I guess that's it - it's ZA, bless it. I can't not use it, so I guess I can't use Cygwin. Shame, I was getting quite fond of it. As a long shot, I'll see if I can find the ZA forum and ask / search. BTW, I discovered what is making cygwin run slowly - it is vsmon.exe that runs when ZoneAlarm anti-virus checking is on (it usually is) - as soon as any X-component starts the cpu consumption for vsmon rockets. Thanks again everyone --- John Ormerod erebor limited -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Page Up and Page Down
On Fri, 16 Sep 2005, Mike Hicks wrote: Hi. I have what appears to be a plain US 104-key keyboard manufactured by/for Compaq. Using xterm, when I press the Pg Up key on the number keypad, I get the character sequence ^[[5~ and I get ^[[6~ for Pg Dn (^[ is actually a single character, escape). However, the Page Up and Page Down keys in that middle section between the number pad and main keyboard area produce different sequences, ^[Or and ^[Ou respectively. On my Linux box at home, I believe xterm always produces ^[[5~ and ^[[6~ It sounds like your Linux system is running Redhat. I get lots of complaints about that (for instance earlier today ;-). For quite a while (I'm told it was corrected in Fedora) their package for xterm alters most of the key translations, lobotomizing it to look like someone's improvement to old xterm. A quick check on my system shows it producing \EOH and \EOF (though the correct answer depends on the resource settings of course). I also use PuTTYcyg [http://gecko.gc.maricopa.edu/~medgar/puttycyg/] to use the Cygwin command line (since the Windows Command Prompt window royally sucks). It produces ^[[5~ and ^[[6~ for everything. ;-) (By the way, if you're at a command prompt, you can see what the shell is seeing by typing ^V prior to pressig the key.) Anyway, I've looked through the app-defaults for xterm, and haven't found anything obvious, so this must be hidden somewhere else. I'm not aware of anything I might have changed to cause this to happen. It is problematic, since vim expects the sequence produced by the keypad buttons, rather than the ones produced by the middle keys. TERM is set to 'xterm' in both xterm and PuTTYcyg. Actually vim can use the termcap/terminfo settings (though I understand it has a built-in copy of one of the flavors for xterm). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: Page Up and Page Down
On Fri, 16 Sep 2005, Reid Thompson wrote: if nothing else, remap the sequences in your .[g]vimrc file(s). that's a backwards solution (but as a last resort ;-) Also, use setup to download rxvt and see if that provides you a better 'terminal' no - just to refresh my memory I ran it just now and see it does something comparable (different strings for the editing keypad, still not what he's expecting). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
Charles Wilson wrote: *I* wonder, if xemacs were rebuilt against the CURRENT ncurses libraries (libncurses8), would it still have similar problems -- e.g. would you need to rebaseall and then reinstall libncursesEIGHT? If so, it's a problem I need to track down, as the ncurses maintainer. If not, then the XEmacs maintainer should simply release a new version, recompiled against the new ncurses. Charles, as the title of this mail says, it is Emacs (21.2-13, 21.3.50-2, started from X), NOT XEmacs (21.4.17-1, 21.5.16-1), that has problems after rebasing all the system. The problem. There are applications that need rebasing (... unable to remap...). But after rebasing all, Emacs does not show its window and take almost 100% of CPU (one can only kill it). If one reinstall libncurses7-5.3-4, Emacs works again as it should. For what I know, Emacs is the only X application that has this problem. Cheers, angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
Angelo Graziosi wrote: as the title of this mail says, it is Emacs (21.2-13, 21.3.50-2, started from X), NOT XEmacs (21.4.17-1, 21.5.16-1), that has problems after rebasing all the system. Fine, Emacs, XEmacs, whatever. That's not the point The problem. There are applications that need rebasing (... unable to remap...). But after rebasing all, Emacs does not show its window and take almost 100% of CPU (one can only kill it). If one reinstall libncurses7-5.3-4, Emacs works again as it should. For what I know, Emacs is the only X application that has this problem. And, is it the only X application that links against an obsolete version of the ncurses library? e.g. is it simply that cygncurses-7.dll cannot be rebased without causing troubles for client apps -- and cygncurses-8.dll, used by all other X apps, is fine? The *E*macs maintainer should relink/rebuild *E*macs against cygncurses-8.dll, rebase, and see if the problem (e.g. the necessity of undoing the rebase of cygncurses-8.dll by reinstalling that package) remains. If the new *E*macs works with a rebased cygncurses-8.dll, then the problem is solved: cygncurses-7.dll is broken, and if it weren't obsolete it should be fixed. But, since it IS obsolete... Now, if the *E*macs maintainer does all this and the problem remains -- after rebasing, *E*macs is broken unless cygncurses-8.dll is reinstalled -- THEN we'll have something to talk about. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
Christopher Faylor wrote: Angelo Graziosi wrote: Even using the snapshots, the problem remains and every time one needs to rebase all one must reinstall libncurses7-5.3-4 if one wants Emacs to work. Since this has nothing to do with Cygwin, AFAICT, there is no reason to think that a snapshot would fix the problem. I do not doubt that it is so. The first time I observed these problems with Emacs was when Cygwin-1.5-17-1 was released: reinstalling 1.5.16-1 all worked fine and I thinked that some snaps solved the problem. Successively I found that reinstalling libncurses7, effectively, solve the problem. But the habit to test snapshots remains! Charles Wilson wrote: And, is it the only X application that links against an obsolete version of the ncurses library? e.g. is it simply that cygncurses-7.dll cannot be rebased without causing troubles for client apps -- and cygncurses-8.dll, used by all other X apps, is fine? I cannot answer to these questions. I can only confirm that for what I know only Emacs has these problems. Best regards, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
