Description of problem: Typing keys and editing files is rife with strange and wondrous behavior. Press down arrow, and the last character on the current line gets copied to the next line. Backspace and two characters get erased from the screen (but only one was really erased which is revealed by doing a refresh). It is also very slow to respond to keystrokes and random characters wind up on the screen if you scroll up or down. It is a complete mess. The slowness disappears if I switch to emacs-lucid, but all other badness remains. I suspect sabotage by vim fanatics :-). Version-Release number of selected component (if applicable): emacs-filesystem-29.1-2.fc39.noarch emacs-common-29.1-2.fc39.x86_64 emacs-29.1-2.fc39.x86_64 emacs-lucid-29.1-2.fc39.x86_64 How reproducible: 100% Steps to Reproduce: 1.Just try to use it for a while, mysterious behavior won't be far behind. Actual results: Wacky behavior Expected results: Obeys keystrokes and displays correct text. Additional info: I'm running X11, not wayland. I have no idea if that matters.
As an experiment, I tried this stuff (I have my old fedora 38 partition mounted at /fedora38) ln -s /fedora38/usr/libexec/emacs/28.3/ /usr/libexec/emacs/28.3 ln -s /fedora38/usr/share/emacs/28.3/ /usr/share/emacs/28.3 then run emacs from this script #!/bin/bash # # See if we can run emacs 28 from the f38 boot partition... # LD_LIBRARY_PATH=/lib64/:/fedora38/lib64/ export LD_LIBRARY_PATH exec /fedora38/bin/emacs-28.3-lucid Unfortunately, it is just as screwed up that way, so the problems may live in one of the many libraries it uses rather than emacs itself. I tried to use just the /fedora38/lib64 library path, but I get stack smashing errors when I do that :-(.
I have emacs emacs-common and emacs-filesystem as well as libotf installed. I also remove my .emacs and .emacs.d directories just to ensure that the problem is not my local configuration. For me, I can not load a file into emacs with `emacs filename` I have to use `emacs -Q` and that does not load somethings, at least the font. Downgrading to Fedora 38 for emacs gets rid of the problem for me. Not quite sure what information to provide, have also reported to the emacs mailing list.
I tried this in fedora 39: dnf --releasever=38 downgrade emacs It did indeed downgrade emacs successfully, but the useless behavior persists with editing not doing what I say or at least not displaying it correctly. This pretty much kills fedora 39 for me since I spend not quite 24/7 in emacs :-).
One last experiment: I switched from x11 to wayland just in case that had something to do with it, but the wacky editing is the same.
Just to be clear: Are you running the X11 version of emacs, or are you using terminal-mode emacs in a graphical session? Have you tried to reproduce those problems in a new user profile without any customization?
(In reply to Gordon Messmer from comment #6) > Just to be clear: Are you running the X11 version of emacs, or are you using > terminal-mode emacs in a graphical session? > > Have you tried to reproduce those problems in a new user profile without any > customization? I removed my .emacs and my .emacs.d and the problem is still the same. Importantly, for me, downgrading to 28.3 works as it has in the past. However, my use cases are perhaps a bit less sophisticated than Tom's even though I have been at emacs for over 31 years.
I'm using the x11 emacs (tried both the gtk and lucid versions). If I run emacs -Q I don't seem any obvious problems, but I have emacs so heavily customized that it is hard for me to use without all my features, so I'm not sure I did enough testing to tell for sure it is better. I don't actually see any reason anything should be different with my custom lisp since I downgraded emacs to the exact same version I'm using on fedora 38, so you'd think all the lisp would be compatible. I wonder if the font I normally use is corrupt somehow and that is confusing things (I use Inconsolata if it is installed with terminus as a backup). I guess I could try a different font next time I'm booted in fedora 39 and see if the weirdness goes away.
Tried different fonts, same weird behavior.
I did more testing with emacs -Q, and it really doesn't seem to exhibit the problem there. I tried hacking my .emacs file to suppress loading all the customization it drags in from other lisp files, and it still acts wacky with just my .emacs, so I guess I'll spend the next week binary searching through my .emacs to find out what is triggering the nonsense :-). The main code in my .emacs is setting the default fonts and window sizes the way I like them, it is difficult to image what that could be doing to cause the strangeness.
I'm getting closer! It has something to do with setting custom colors for background/foreground/cursor in the initial and default frame-alist. If I comment out my custom color code in .emacs, it behaves perfectly. Now I need to work on producing the minimal .emacs file that causes the breakage.
Forget colors, that was a red herring. The real problem is wayland. I thought I was running X11 because I had sddm set to start an x11 session, but gnome somehow sneaks in a wayland session anyway unless I explicitly select gnome classic on x11. I'm currently editing some videos to show the one bug I've been able to easily reproduce. There is a line in my f39 install notes which says: I'll want to change If I move the cursor to the line just below it (which is empty) then do a cursor-left to move to the end of the line (following the e) then hit backspace to (in theory) erase the "e", on wayland the screen does not change, the cursor does not move. If I move the cursor down, then suddenly the e disappears. This is merely the one glitch I can reliably reproduce, all sorts of other weirdness happens if I try to edit stuff. When I'm on x11, the e disappears right away and the cursor backs up, all else is identical, same computer, same .emacs file, same fedora, etc. There may still be something in my .emacs that provokes this, since I don't think it happens with emacs -Q, but it definitely only happens on wayland.
Created attachment 1999371 [details] Video of edit session under wayland This video shows the cursor sitting at the end of the line for a while, but really I hit backspace. The e at the end only disappears when I hit down arrow. I can only surmise that wayland is doing some sort of "helpful" optimization of redraws :-).
Created attachment 1999372 [details] Video of edit session under x11 This video shows the same edit under x11. I move the cursor to the end of the line and hit backspace and the e disappears and the cursor moves left as expected.
Changed the component to wayland.
I don't think changing the component is helpful. I'm unable to reproduce the problem using emacs under a GNOME (Wayland) session on Fedora 39. And, as you found earlier, the problem appears to be triggered by some aspect of your configuration. Until we have the portion of the configuration that we can use to reproduce the problem, we might not be able to do anything about the issue affecting your system.
Created attachment 1999396 [details] A slightly simplified .emacs file that shows the problem This is my .emacs file with the code at the end suppressed which normally goes on to load vast additional customization, so it should work by itself as a test .emacs. On a 4K display this winds up displaying emacs with a 79 line window (assuming it could find Liberation Mono). That will be relevant for the next step editing the file I'll attach next.
Created attachment 1999397 [details] The file I edit to reproduce the bug (my fedora 39 install notes) To reproduce the bug, I edit this file. Once it is on screen I page down, that should leave the line that says "I'll want to change" near the top of the screen. Move the cursor to the empty line below that, left arrow to get to the end of the line (after "change") then backspace which should erase the "e" in "change". When I'm on wayland, the display doesn't change (but it really has erased the "e"). Anything that provokes any kind of update does finally draw the screen correctly. For instance, if you drag the emacs window it seems to go ahead and update. Possibly it will even update if you just wait long enough (maybe the clock in the mode line causes the update).
In case it is relevant, I'm using the rpmfusion nvidia drivers: nvidia-gpu-firmware-20231030-1.fc39.noarch xorg-x11-drv-nvidia-kmodsrc-535.129.03-2.fc39.x86_64 xorg-x11-drv-nvidia-cuda-libs-535.129.03-2.fc39.x86_64 xorg-x11-drv-nvidia-libs-535.129.03-2.fc39.i686 xorg-x11-drv-nvidia-libs-535.129.03-2.fc39.x86_64 nvidia-settings-535.129.03-1.fc39.x86_64 xorg-x11-drv-nvidia-power-535.129.03-2.fc39.x86_64 xorg-x11-drv-nvidia-535.129.03-2.fc39.x86_64 akmod-nvidia-535.129.03-1.fc39.x86_64 kmod-nvidia-6.5.11-300.fc39.x86_64-535.129.03-1.fc39.x86_64
(In reply to Tom Horsley from comment #15) > Changed the component to wayland. Please don't! Wayland is absolutely not the right component for this. Wayland is a set of protocol definitions in XML and a small IPC library, such bugs are not with Wayland (the component in bguzilla), this is rather a bug with the driver, the application, Xwayland or the Wayland compositor, but not Wayland. You mentioned that you tried with an older version of emacs and that the issue is the same, so that would possibly rule out a regression in the application itself. Considering that you use the proprietary NVIDIA driver, which relies on explicit synchronization [1] and the video shows that the content updates are not in sync, I would recommend trying the "nouveau" KMS driver instead of the closed source proprietary NVIDIA driver and see if you can reproduce with the Open Source driver. If that still fails, next step is to try with a different Wayland compositor. The thing that confuses me is that comment 0 states „I'm running X11, not wayland. I have no idea if that matters“ so I fail to see how that could end up being related to the Wayland compositor… [1] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967
That comment 0 about running x11 was me confused by gnome sneaking in a wayland session even though I had the sddm greeter set to run x11. I have since learned to explicitly check what kind of session is actually running :-). I've just tested various combinations nouveau wayland emacs seems to work nouveau x11 emacs seems to work nvidia wayland I see the bug described above nvidia x11 emacs seems to work That seems like some kind of mismatch between nvidia and wayland, but I assume emacs is issuing the exact same drawing calls in both cases.
(In reply to Tom Horsley from comment #21) > > That seems like some kind of mismatch between nvidia and wayland, […] Then it's most likely the synchronization issue with the NVIDIA driver I pointed out in comment 20.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26. Fedora Linux 39 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.