Rebind SIGINT when copy is bound to ctrl+c

[Sparhawk]

In guake (drop down terminal), if you bind copy to ctrl+c (instead of ctrl+shift+c), SIGINT will be swapped. Hence, SIGINT will then be bound to ctrl+shift+c. I imagine that this is processed before bash itself, and guake sends a literal ctrl+c when ctrl+shift+c is pressed.

It would be fantastic if terminator could also do this. I appreciate that I could modify this from within bash itself using stty, but making the terminal emulator do it is useful for consistency when sshing, etc.

Bug 340604 is related, where copy can be bound to ctrl+c, but SIGINT can still be sent with the same keycode when no text is selected. I feel that guake's implementation is cleaner, and (for example) allows SIGINT with text selected.

==EDIT==
This bug is so old I can't exactly remember what I was complaining about! Anyway, one can now bind copy to ctrl+c, which is great. SIGINT can then be sent with crtl+shift+c. If text is selected, ctrl+c copies. However, if there is no text selected, ctrl+c still sends SIGINT. It would be better to totally rebind SIGINT so that it is *never* sent with ctrl+c, no matter what is selected.

[Leslie Viljoen (leslieviljoen)]

Please can this be made to work? Trying to bind ctrl-c to copy actually breaks the keybinding - afterwards the copy command can be set to any binding but it always becomes disabled as soon as I leave the dialog. I had to edit ~/.config/terminator/config and remove the bindings to get back to ctrl-shift-c for copy.

Since ctrl-c breaks out of programs and is a irreversible operation, I'd much prefer to use more modifier keys to trigger it, and doing so would also make the terminal consistent with every other program. It's a continual pain to ctrl-c in a browser and then have to ctrl-shift-v in terminal, and do the reverse dance to paste from the terminal into the browser.

[Sparhawk (sparhawkthesecond)]

@Leslie
Yes, there is a bug where you cannot rebind keys in certain situations, but this is fixed in trunk (bug #1099481). As you say, you can edit ~/.config/terminator/config to change it manually. You can assign <Control>c here.

I agree with the inconsistency in ctrl+c between other applications and Terminator. I used to use yakuake instead of guake, but tore my hair out constantly when accidentally sending SIGINTs. In addition to ctrl+c being less destructive and less keys, I use copy a lot more than SIGINT, so I'd prefer it to be (more) idiot proof.

[Leslie Viljoen (leslieviljoen)]

Woohooo, that is so awesome, thanks for fixing that! I've had to use an old terminal for so long and now I can go back to Terminator!

[Sparhawk (sparhawkthesecond)]

@Leslie Do you mean my workaround? This bug is not fixed AFAIK.

[Stephen Boddy (stephen-j-boddy)]

Hi Bug subscribers, this is the maintainer (Steve Boddy) of Terminator, who took over from Chris.

In case you were not aware there has been a new release 0.98 of Terminator in the last few days which has many changes, fixes and updates. We also have an ongoing GTK3 port which uses a much more up-to-date libvte.

Even with the ~50 issues closed by that release, and discounting the ~90 outstanding wishlist items, we still have an unwieldy 95 bugs. With the oldest approaching it's 6th birthday and some that haven't seen any updates in nearly 5, it is time for a purge.

My intention is to try and get this list down to a minimum, and for that I need your help.

First I'm going to work through, oldest to newest, setting bugs to Incomplete, pending confirmation that they are still an issue. If after a month there is no feedback, the issue will get closed as Invalid. Here's where you come in. I can't always reproduce, or setting up (i.e. other distros) to even test takes a long time, so I'm going to try crowdsourcing this.

1. Get the latest release. Is it still an issue? If yes, set the confirmed-0.98 tag. For bonus points follow the guide http://gnometerminator.blogspot.com/2015/09/so-you-want-to-try-terminator-gtk3.html and see if the GTK3 branch has same issue, and set the confirmed-gtk3 or notaffected-gtk3 tag.

2. Can you reproduce with an empty/default config file? You can pass "-g temp_config" to do this without affecting your existing config. If you already have Terminator running, you'll need to pass -u as well to disable the DBus.

3. If able to, can you reproduce with another user/guest account?

4. If the issue does not already have clear, precise instructions to reproduce with minimal setup/steps, add them.

5. Put as much info about what you are running.
   * Software/library versions (libvte, gtk, pango, cairo, distro, desktop environment, language)
   * Screens (single or multi)
   * Any unusual / custom packages or configs that might be interacting.

6. If possible attach the config file, unless the issue also happens with an empty one, but mention that.

7. Attach the "-d" debug output from 0.98.

Some common things that cause incidents.

* Strange sizing issues or rapidly shrinking windows - Try turning off Window geometry hints.
* Input (esp. broadcasting duplicate chars etc) problems - Try killing IBus.
* Hand editing of the config file can cause various issues - Due to misunderstanding, incorrect structure or typos.
* Some issues are actually in libvte - This is why testing GTK3 is so important.
* segfaults - Unfortunately these are dying inside the C libraries, and it is usually beyond me to fix those.

Many thanks for your assistance, and hopefully this will get us closer to a bug-free Terminator.

[Sparhawk (sparhawkthesecond)]

1. Confirmed in 0.98, terminator-bzr 1645, terminator-gtk3 r1601 (with vte3 0.40.2) in Arch Linux.
2. Confirmed with an empty config.
3. Confirmed with another user.
4. Original report edited (it's a fairly minor bug now).
5. Additional info:
* vte 0.28.2-5
* gtk2 2.24.28-1
* pango 1.36.8-1
* cairo 1.14.2 (actually cairo-infinality-ultimate)
* Arch Linux
* KDE Plasma 5.4.0-1
* en_AU
* Screens: bug is present with both single and dual monitors.
6. Reproducible with empty config file.
7. Output attached using 0.98 and running `terminator -g temp_config -d`

[Stephen Boddy (stephen-j-boddy)]

I think this outstanding schizo Ctrl-C behaviour is considered a positive feature by some people, though I can see how it could be confusing, and prone to causing frustration for those that dislike it.

So do we look at forcibly unbinding the SIGINT with an option? This is a bit unclear, to me right now, so will require some thought and research. Setting as low for now though.

Thanks for the response.

[Sparhawk (sparhawkthesecond)]

From memory, Guake totally prevents SIGINT from being activated by ctrl+c. Like I mentioned, I can't remember exactly what my initial complaint was (and I wrote the initial report poorly). I agree that this is now a fairly low priority.

In theory, I might accidentally attempt to copy something with nothing selected, and accidentally kill something. In practice, this has never happened, and there are other more pressing issues to tackle.

I guess ideally it would be implemented, perhaps with an option, or even an option to manually bind SIGINT to anything (although I guess you'd need to be able to bind it to two things… which gets even more confusing).

Cheers.

[Stephen Boddy (stephen-j-boddy)]

OK, so a little investigation:
In terminal.py line ~868:
            if (mapping == "copy" and event.state & gtk.gdk.CONTROL_MASK):
                if self.vte.get_has_selection ():
                    getattr(self, "key_" + mapping)()
                    return(True)
            else:
                getattr(self, "key_" + mapping)()
                return(True)
Will need an extra clause in the first "if", i.e. self.config('smart_copy')
Then a smart_copy setting, GUI, and documentation needs to be added. This would enable people to choose smart copy or not (i.e. copy if there's a selection, or SIGINT if not, or always copy and use additional modifier to get the SIGINT.

[Stephen Boddy (stephen-j-boddy)]

Committed in r1667