Change the edit mode to VI mode. Black cursor appears on the text editor. Pressing the arrow keys moves the black cursor, but using HJKL keys causes the black cursor to disappear.
Specs (EDIT with more infos):
Kate 24.08.3
Operating System: EndeavourOS
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.12.1-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i5-10300H CPU @ 2.50GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics
Manufacturer: Acer
Product Name: Predator PH315-53
System Version: V2.04
Can’t reproduce here either (Fedora 41, Nvidia card). Do you have access to any other hardware, or to a virtual machine on your current device, that you could try it out on to rule out some sort of weird graphical issue?
As a side note, this forum provides each visitor with their own personal “where you last visited” mark in the topic list, to make it easier to find topics they haven’t yet read - I don’t think “bumping threads” is necessary.
Oh you mean testing on other device. I tested this on my Steam Deck’s Kate, and I couldn’t recreated the bug either. I can move the black cursor with HJKL.
Hmm - on the device where you see that behavior, did it work as expected at any point in the past?
You could rule out possible packaging issues on the Arch end by trying out the Flatpak version of Kate, perhaps?
Also, do you have a kernel before 6.12 (either linux-lts or 6.11, I’d assume, on Arch) you can try out on that device, by chance? I’m asking as I’ve seen folks post a few odd graphical issues on devices with 6.12 so far, possibly related to the kernel’s built-in graphics drivers? Just a guess, though.
I know you tried on a steam deck, but I wonder if the issue would remain if you tried this with a live session, like booting from a flash drive on that same hardware. It seems like a conflict between color selection of Kate settings and something else like global colors settings from a theme.
Maybe the flatpack attempt is a coincidence here…not sure how that really works out in a situation like this.
I had not run across these options before, but there is a plethra of things that I could break in this section and maybe produce a similar result. But, at least if this is some sort of bug, there might be a temporary solution in finding out what controls that color. A little tedious for sure.
One other classic troubleshooting step to try would be, on the device where you’re experiencing the issue, creating a fresh user account (with all default settings) and seeing if the issue shows up on that one as well.
If it doesn’t show up on a new account, then it’s at least narrowed down that it’s something in the user configs, as opposed to a fundamental package+system problem - if it does, then you know it’s not something that was introduced by any other customization you’ve done to your user profile!
Yep. It’s something in my user configs. I created two accounts for admin and standard types. Both did not have the issue. The black cursor did not hide with HJKL motions.
Also, in my current (faulty) account has multiple activities. I set Kate to appear in all activities. I tested it in all activities, and the issue is still there.
Unfortunately, I don’t have past kernel versions, though I have the fallback kernel. So, I rebooted it in the fallback version. The issue is still there, too.
Ah - it might make sense to start small and see if backing up your current ~/.config/katerc file, then removing it / going back to all defaults helps? (It’d be nice if it was just something funky in the Kate configuration file!)
I made a backup directory of katerc and deleted katerc/. Then I opened Kate from terminal and typed in Vi-Mode. The black cursor still disappears with HJKL motions. Also other Vi keys like 0, ^, w, e, etc. made the black cursor disappear too.
Deleting ~/.config/katerc would have functionally reset you to defaults for Kate settings, so…oof, if doing that didn’t help then there’s something…somewhere else in your user profile that is having the bizarre effect of creating this cursor issue.
Depending on how determined you are, you might be able to pin it down by taking one of the newly-created users that you made that doesn’t show that behavior, and then one-by-one making each customization to turn it into a copy of your main user, to try to find out which step causes it…depending on how many themes, KWin effects, etc. you have customized, that could be a while though, so it might be a judgment call of whether figuring that out is worth it.
It was caused by Ibus Wayland. I used Ibus Wayland to type in Japanese but I was in Romaji mode when testing it, meaning typing in Latin characters instead of Hiragana, Katakana or Kanji.
My Ibus Wayland also has English - Filipino layout, which shouldn’t have an another character layout option like the Japanese keyboard layout with Hiragana, Katakana and Kanji. But when I set Ibus Wayland to English - Filipino layout, the black cursor still disappears.
So I disabled Ibus Wayland. The black cursor can now move with HJKL. Didn’t change any theming settings.
Though, is this an intended behavior with virtual keyboards? Thinking of filing a bug report to either Kate, Ibus Wayland or virtual keyboard in general?