Konsole - Copy to Clipboard - Switch to Other Application

Support KDE Plasma
1

I use cat to show me a quite long textfile that has more lines than there are room for on one page in Konsole.
I scroll up to somewhere at the top of the text, select a few words, use Ctrl-Shift-C to copy the text to clipboard. So far, all is well.

The next step introduces my problem. I switch to Firefox, to be able to search a web page, and as I do this, the current line, where the cursor is ready for you to type some command or something, will be pushed into view and I lose sight of the selected text at the top.

It does not matter how I switch to Firefox, using the mouse to select its icon in the panel at the lower part of the screen, or using Alt-Tab, both do the same thing: The active line with the cursor is pushed into view for no good reason.

It also does not seem to matter which program I switch to, it doesn’t have to be Firefox. I tried it with Dolphin and the same problem shows up.

If I select the text, right-click the selection and choose copy from the menu, the problem goes away, but I don’t like that method of doing things. In any case, it seems as if the keyboard is involved somehow, with Konsole sensing that the keys have been triggered and therefore focuses on the current line where the active cursor actually is located.

Is there any way to stop Konsole from doing this?

I have not seen this behavior before the last update on May 2, so I was wondering if there is some setting I am not aware of that has been introduced or changed.

I have looked in settings, restarted, but nothing I do seem to make a difference.

Thanks.

2

I am not sure you can.

I have no explanation for the behaviour - if you find it very problematic I think you should create an issue with the developers of the Konsole app.

The following is pure speculation - not an explanation - I have no insight into the sources - but I am a software architect and full stack developer - so I can only see it as I would do it

I could be that even though the shortcut technically is doing the same as mouse action - the underlying premises is not the same.

To be able to select text using the mouse - the software convert the visible buffered content to a text view port allowing the mouse to provide a box containing the text.

To move that selection to the clipboard - there is two defined actions and - I am guessing

  • The mouse action sends the text to clipboard and there is no key press involved
  • The shortcut method involves key press
    • Any key press will trigger returning to the actual prompt location

If you want to retain the position in the terminal I suggest pipe the content through less as this will preserve the cursor location

cat somefile | less
2 Likes
3

I can’t reproduce your problem, but I am running Krohnkite which changes the way windows are tiled so that may interrupt the issue and/or be a solution for you.

4

i remember having some issue of similar nature ages ago, but cannot reproduce it anymore.

what i do remember is having installed wl-clipboard or xclip (depending upon whether you are on wayland or X11 respectively) did straighten the kinks with clipboard issues on terminal and TUI programs. worth giving a shot, i think

5

I can easily reproduce the behaviour.

Because no key press is involved when using the mouse → right-click → copy there is no change in focus.

As soon as you press a key while Konsole has focus it will jump to the current input location.

That is expected Konsole behaviour.

I think the issue comes partly from not understanding that the Konsole window is not a text editor and as such when a key board press is registred - the jump to the input point in the Konsole is the correct and expected behavior.

1 Like
6

Yes, that may well be a good solution but then I would skip cat and instead do:

less pd*

(there is only one file which starts with “pd”, short for programs-diff, in this directory)

I had xclip installed earlier, but switched to wl-clipboard when I switched to Wayland. Hmm, I hope Konsole’s update didn’t re-introduce a need for xclip all of a sudden…

Maybe, but why did it not do that from day one? What was changed, I wonder, that made it “change its mind” and all of a sudden refocus on the “active” line when it had not done so in the past?

Oh, well, it may be whatever, I’ll skip cat for now and go for less.

Thanks to all.

The suggestion by @linux-aarhus seem to me be the solution for this problem, until the Konsole (or KDE) people start to be affected by this as well and change things again. 8 )

7

I cannot remember any virtual terminal application (Konsole is just one of many) that did not jump to the actual input point when pressing a key.

I don’t think it ever did… but what do I know about your system?

I know nothing - Look at Konsole profile → Keyboard → you can configure how the console reacts to keypress - perhaps you did that, but it would make no sense for the normal use of the virtual terminal

And now that I come to think of it - I actually do remember - from a long time ago - my first modem - a 2400 baud industrial telecommunitcation modem found in container.

In the terminal used to communicate with the modem (windows 3.1) one could move the cursor - place on an arbitrary line at an arbitrary position and then press Enter which then caused the preceding characters to be echoed to the modem - causing either a success or an error - depending on characters.

Let me expand this a bit.

What you see as text in the terminal application is history - if the cursor stayed on the line and you pressed enter - if the behaviour was different than it is you would send the content of the line back into the system - which could cause unwanted behavior.

Think of the modern virtual terminal as a two window communication

  • The first window is your command followed by Enter
  • The second window is the system response

It is a two-way communication where you can have only one active input location and you cannot access the response other than reading it.

1 Like
8

Ok, I didn’t understand what the problem was. I can now reproduce it.

If you’re using mouse to select the text, you could enable “Copy on select” within the “Mouse” options for the profile in use. That way you only need to select the text and not use Ctrl+Shift+C to copy it.

2 Likes
9

Thanks for this suggestion. I have set this option to see how it behaves. It may work, or using less as suggested by @linux-aarhus might prove a better solution. Future will tell.

10

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.