"autistic" Konsole

Duncan 1i5t5.duncan at cox.net
Tue Jul 12 07:16:30 BST 2016


René J.V. Bertin posted on Mon, 11 Jul 2016 18:18:25 +0200 as excerpted:

> Hi,
> 
> Not to hurt anyone's feelings, but I'm running into cases where Konsole
> behaves in a way where I can only communicate with it in indirect way.
> In fact, it's as if keyboard input is ignored, but output from running
> processes still comes through. The menus work, and I can use the paste
> command to enter commands (e.g. "exit\n").
> 
> This happens with both Konsole4 and Konsole5 so I'm wondering if there
> isn't a magic key combination that deactivates the keyboard. I'm seeing
> this on a new notebook with a bit cramped chiclet-style keyboard that's
> giving me some adaptation trouble, and I have an impression it happens
> esp. when I'm in vi or editing a command line in tcsh's vi edit mode.
> It's clearly a process-wide thing, but when I launch a new konsole
> process it opens perfectly normally, and until now Konsole is the only
> application that's been showing this behaviour. Which makes me think I'm
> looking at a Konsole ideosyncrasie (or feature).
> 
> Any ideas?

This is interesting, because at least konsole5 normally has only a single 
konsole /process/ -- opening additional windows normally opens new 
threads on the same process, NOT an entirely new process.  That's why 
dragging konsole tabs from one konsole window to another works so nicely 
(just as it does in firefox, also a single process) -- it's just 
different windows of the same process.

So I must ask if you're sure you're opening a new konsole /process/, or 
just a new thread on the same process.

(FWIW, htop is what I just used to verify thread vs. process here.  Run 
it in a konsole tab/window or text-VT login, filter on konsole, and 
toggle show-threads on and off with multiple konsole tabs and windows 
open.)

Assuming it's actually different windows/threads on the same process, as 
I suspect, the problem is obviously not process-wide, but presumably tab-
wide.

Which suggests that it may actually be an issue with the terminal 
emulation for that specific tab.

Does the problem occur when you type into a text-VT login outside of X -- 
IOW when you're not using a terminal window, but an actual (virtual) 
terminal?  What about when you try some other x-based terminal emulator 
app?  (There are many.  You may have xterm or gnome-terminal installed 
already, most DEs have a terminal app, there's generic gtk- and qt-based 
terms, rxvt is often mentioned as an independent x11 terminal, etc.)

Does konsole's clear scrollback and reset (view) menu function do 
anything?  I know nothing about tcsh, but presumably it has a (terminal) 
reset command (reset) much like bash's.  You can also try that, both by 
blind-typing it, and by the paste method.

If either of those reset methods work or if other terminal window apps 
have the same issue, the problem is almost certainly that you're 
accidentally engaging some terminal-control escape sequence, and the 
emulation is then expecting a color-set sequence, for example.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.


More information about the kde mailing list