Bug 752936
| Summary: | emacs -nw does not accept any keyboard input | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||||
| Component: | emacs | Assignee: | Karel Klíč <kklic> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | rawhide | CC: | jonathan.underwood, kklic, rjones, rvokal | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-11-25 13:54:52 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Michal Jaegermann
2011-11-10 19:41:22 UTC
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 *** |