Description of problem: Trying to start emacs in a terminal windown by using '-nw' brings up an emacs display and that is it. There is no input which is recognized. One is stuck with options except of loging from somwhere else and killing a wayward process. Once this is accomplishe the following shows up at a terminal prompt: 1;1400;0c Attempts to simplify startup, in order to eliminate possible troubles there, like 'emacs -nw --no-site-file', has no effect save slightly different "decorations" on a resulting display. Starting the same emacs in a graphics mode does show any issues. Version-Release number of selected component (if applicable): emacs-23.3-11.fc17.x86_64 How reproducible: always Additional info: All of the above from a remote login/remote display as a local desktop is currenly completely broken and nothing can be started there.
I have tested the emacs-23.3-11 build prepared locally for Fedora 16 and `emacs -nw` works well here. Some X server issue and glibc issue occurred recently in Rawhide, so that might be the cause of the emacs input problem. Please try the following actions: 1. Update to the latest Rawhide packages. A rebuilt Emacs packages should be installed: emacs-23.3-12.fc17 http://koji.fedoraproject.org/koji/packageinfo?packageID=560 Does the rebuilt package solved the issue? 2. Switch into textual multi user mode and try using Emacs from here. Command to switch into multi user mode: systemctl isolate multi-user.target Does emacs respond to input? Thanks.
(In reply to comment #1) > I have tested the emacs-23.3-11 build prepared locally for Fedora 16 and `emacs > -nw` works well here. > Please try the following actions: > > 1. Update to the latest Rawhide packages. Not available from mirrors yet but I pulled out from koji and installed emacs-23.3-12.fc17.x86_64 emacs-common-23.3-12.fc17.x86_64 emacs-filesystem-23.3-12.fc17.x86_64 > Does the rebuilt package solved the issue? Not at all. A behaviour is exactly the same. 'emacs' does work, locally or with a remote display, 'emacs -nw' gets stuck. > 2. Switch into textual multi user mode and try using Emacs from here. Yes, I tried that. It does not make a difference. After 'emacs -nw' a splash screen shows up. A keyboard is not locked in that sense that I can switch to another console (and kill emacs from there) but no input is accepted by emacs. I also tried 'TERM=vt100 emacs -nw'. Resulting "decorations" are different, as expected, but otherwise the same thing. > Does emacs respond to input? I backed off assorted xorg-* packages so I can have at least some display. Running 'emacs -nw' locally in a terminal window has only this effect that after killing it the following shows up '1;3001;0c' instead of '1;1400;0c' but not much else. BTW - my current glibc is 2.14.90-15.2. I tried to strace 'emacs --no-init-file --no-site-file -nw'. I attach resulting to the moment when emacs gets stuck. Another trace includes lines which are added after emacs process is killed.
Created attachment 533605 [details] results of strace for ' emacs --no-init-file --no-site-file -nw'
Created attachment 533606 [details] trace lines added when the process above got killed
I should add to clarify. While booted into a local text console if I will type 'emacs some_file' then a content of 'some_file' shows up in an emacs window and no further input is accepted (emacs keystrokes, "normal" typing, arrow keys, whatever ...). Neither /usr/bin/vim nor /bin/vi are afflicted by such disease.
An update to emacs-23.3-13.fc17.x86_64 does not bring any joy, I am afraid.
An update to emacs-23.3-14.fc17 should definitely help, then.
*** Bug 754837 has been marked as a duplicate of this bug. ***
-14 doesn't fix it for me.
(In reply to comment #9) > -14 doesn't fix it for me. Does not work for me either. It is not 100% CPU but "only" 90%+ but that is not of a great help. One can attach strace to a running process but this does not show anything; just sits there.
This is a duplicate of the bug describing the same problem with `emacs --daemon`, which also fails because it doesn't have an X window. *** This bug has been marked as a duplicate of bug 751154 ***