This was a deliberate change to fix bug 559728.

Okay, understood. Thanks for your prompt response.

However, I think the behaviour described in bug 559728 is correct and expected. For example, if I switch to the console and do CTRL-SHIFT-C, the shell sends the same signal to the running application as CTRL-C. Should the behaviour not be the same in a graphical environment? A further example is what if I were to bind the copy action to the return key, as it is with the Windows Command Prompt... I'd still want to be able to use the return key as normal when no text was highlighted.

On the contrary, even if it was decided to continue with bound key case being specialised and not send it through to the shell at all, I think my bug could be fixed in a way that retains the bug 559728 fix. CTRL-C has a well established behaviour, so surely an exception could be made such that if the bound key *is* CTRL-C, then it is sent through when no text is highlighted? You could ensure that this exception doesn't apply to CTRL-SHIFT-C in order to retain compatibility with your existing fix, even though I could argue that an exception for this is correct behaviour anyway.

The original behavior was perfectly fine here, and I'm not sure why that was "fixed"; was there actually some user demand for that change?  It's now impossible to configure this app the way people are used to it working, and I'd wager the growing list of complaints on the downstream Ubuntu bug (and its dupe collection) is already larger than the sum of complaints about the old behavior.

I'm displeased with the suggestion above to make a special case just for CTRL-C.  I've always avoided the potential confusion with the interrupt key by remapping my terminal Copy to CTRL-X (usually "Cut").  That's the workaround I'd have suggested for those displeased with the old behavior.  I'm still impacted by this change though, because now I can't easily send CTRL-X to apps anymore just by hitting that without having text selected.  That makes alpine unusable as one example.

On the other hand, special casing only the default CTRL-SHIFT-C to not send anything to the terminal if no text is selected would be a perfect fix to bug 559728, without any other impact.  That's not a valid control character sequence for an ASCII terminal anyway, so no one could possibly make a case for it to be transmitted to the terminal.

Another reasonable response here is to revert the UI behavior to what your users expect for now, then turn "Pass-through COPY keystroke if no text selected" into an option that can be turned off in the next release if that's really a problem for some people.  Can't add that option now because of the various translation freezes, and the current behavior is clearly a regression bug that users are complaining about from the UI perspective--even if it was intentional.

I agree completely with Jonathan and Greg.  The behavior in bug 559728 was correct and expected.  For those familiar both with the console use of Ctrl-C and the common GUI use of Ctrl-C, the situation-dependent behavior of previous versions was perfectly expected.  If I have something selected in the terminal, I expect Ctrl-C to copy.  If I don't have anything selected, I expect it to kill the running process.  I think those are reasonable expected behaviors, and the current behavior is definitely a regression.

chpe, can you please respond to our further comments regarding this? I understand that it was you who both reported bug 559728 and "fixed" it. However, I and others believe that the behaviour as a result of fixing that bug is incorrect.

I think bug 559728 was fixed correctly. This is a similar case to bug 138609.

chpe,

Can I ask you to review this again? Although it is similar to bug #138609, it is not the same and I don't think the same fix/policy for that bug can be applied to this case. For that bug, use of the accelerator itself causes gnome terminal to be put into a state where repeated use of the same accelerator results in unexpected behaviour. However, in the case of the bug I submitted, the original behaviour prior to the fix of bug #559728 was to change the copy accelerator's behaviour after a separate action (selection vs. deselection of text).

Since you haven't responded to the arguments presented by myself and others in this bug report, I'm not convinced that you fully understand why we believe the new behaviour following your fix of bug #559728 is incorrect.

Thanks,

Jon

*** Bug 600667 has been marked as a duplicate of this bug. ***

Please reconsider restoring the old behaviour as an option in gnome-terminal.
IMO, this was the only feature that distinguished gnome-terminal from all the other x11 terminals.

I'm surprised by a couple of things here.  One is that there's nobody involved more deeply with GNOME that wasn't relying on this behavior themselves.  As careta just mentioned, I always thought it was major reason to choose gnome-terminal over the alternatives, and that everybody used it.  I'm also surprised and disappointed that the community feedback here is being ignored, given how persistent it is.  People keep flowing in, reporting this as a problem, and yet this bug is still "UNCONFIRMED"?

However, since Christian is so convinced the right thing was done here I decided to take a look at why that was.  The behavior regression was introduced by http://git.gnome.org/cgit/gnome-terminal/commit/?id=f0b104180a4f0b488ef502cad88a5ae2c1acd151  Note that there are four bug IDs referenced in the comments there, including bug 138609 which he mentioned above.  It doesn't seem to be the case that the behavior we all used to like was explicitly and individually squashed.  It looks more like this whole code path was causing problems in a bunch of contexts, and the copy one just got lumped into that larger cleanup.

I'm guessing that just reverting that commit will turn around and break some or all of those again.  It may be possible to special-case the copy one and wrap it into an option, but I think it's going to be an ugly bit of code--as well as violating the general GNOME principals of reducing the number of exposed options you have to tweak.  While I think it's worth it, now I better appreciate that the developers of this project might not consider that a step forward.

I'm capable of producing a forked version with the preferred behavior myself as I find the time, am fighting through the learning curve required to build any GNOME app right now.  If that's successful I'll dump the result into a public repo and produce an Ubuntu PPA.  I don't see any other way to move forward here.

Marking NEW if that makes you happier.  We don't care whether the bug is in UNCONFIRMED status or NEW.

Given the number of reports we got of the old behavior (one), and many reports on this bug, I think it might make sense to revert this.  What do you think ChPe?

Just to recap, the fix for bug 559728 did fix a real issue, but it also BROKE existing deliberate behaviour in the form of a feature that many people were relying on. It's a great shame this is being ignored.

It seems the two quick options for those affected are to use an old gnome-terminal, or use a different terminal. I'll be doing the latter.

IMO the fix is pretty correct. I was not even aware that people expected things to work as in this report, nor that it did work, but it was not intentional, as far as I can remember. In particular, it is not a feature 'everybody used'!

Special casing any key combination is a rather bad idea, and arguments along the lines of «Should the behaviour not be the same in a graphical environment?» or «it has always been like this so there is no reason to change» are impressively unconvincing... Terminals are already a great swamp of inconsistencies, quirks and behaviours that can only be explained by getting a copy of an original VTsomething manual (if at all...)---there is no need to add to that.

> this was the only feature that distinguished gnome-terminal from all the
> other x11 terminals

Oh well. The market for terminal emulators has finally been comoditized!

Whether the original behavior was intended or not, and whether the bug fix that removed it was a good idea in general or not, all these things are really irrelevant.  gnome-terminal used to do something that was valuable to a number of people.  It doesn't do that anymore.  That is therefore a feature regression.  Consider it a new feature request if that makes you feel better.  Regardless of how you classify it, there's a group of people who want something different than what the program does now, and they're telling you how to improve the current state of the program from a usability perspective for a subset of your user base.  And those users are only being told that they're wrong for wanting that.

I have not read all dups, but I don't think anyone said those users were wrong. It is clear that they have a different opinion to chpe's but that is inevitable from time to time. 

You are surely not implying that following the suggestion of a group of users the only acceptable way to deal with it?

Sorry about the noise but I also miss the multifunction feature of Ctrl-C and consider this as huge regression for my work-flow. 

Anyhow until then I compiled older gnome-terminal to keep the behavior.

For what is worth, I'm also missing the old behavior.

*** Bug 639619 has been marked as a duplicate of this bug. ***

I still think the behaviour as implemented is correct => NOTABUG.

CP, you'd make an excellent lawyer :- ) I give up arguing with a stone, as it's easier to go elsewhere.

Please stop personal comments, even if they are supposed to be funny.

No, he's right... Despite of all arguing here and in other "duplicates" this funny stoned stone appears here with a NOTABUG mumble... IS it funny? No. So, please, it IS NOT supposed to be funny, tell him about it first.

What part of my comment about personal comments did you not understand?

This is being reclassified only after another person filed it as a bug.  People who think is a regression keep showing up, while the number who feel the new behavior is right become a smaller minority every time that happens.  That a dupe would appear, and the reaction is "oh, that bug again; let's close the original ticket" is such an unexpected combination, essentially telling yet another person they are wrong, that it is hard not to have an emotional response.

Philosophically, if enough people tell you your user interface has regressed due to a change made, at some point there is no reasonable alternative but to say to yourself "I guess it must just be me who thinks this way", and try to find a way to satisfy them.  They are the users; you're the developer; if you want your software to be easier to use you're supposed to care what they say.  I have to admit I'm wrong about things all the time to keep the interfaces to my own open-source projects moving toward what the community of users wants, rather than just what makes sense to me.

This has been, and apparently is now ending, as an unfortunate example of prioritizing developer's wishes over those of the users of the software.  That's meant to be a factual observation the project should consider rather than a personal comment.

It is clear that the developers do not care about the fact that many users think this is a regression.

However, keep in mind that this being free software, the developers may not exactly be thinking about the users, but just scratching an itch for themselves - in other words, they are developing gnome-terminal because they like to use it. And apparently, they think the behaviour regression is correct.

The solution is simple. Stop using gnome terminal. I already replaced most of my GNOME desktop with XFCE and LXDE components, and it works much better than GNOME ever did. No wonder Ubuntu is dropping it.

To all:
GNOME Bugzilla is not a place for most of the recent comments.

@careta: Your opinion about the gnome-terminal developer and GNOME in general is offtopic for GNOME Bugzilla. This is not a forum. Just because you talk about GNOME does not mean it belongs on Bugzilla.

@Greg: There really aren't that many people yet (ping again when we at least have a few hundred). And again, making generalized comments regarding chpe is not appreciated.

@Satellite: Insults will only make me or another GNOME bugzilla admin ban your account. It won't do anything to change the the mind of a developer.

@Jonathan: Getting personal is not appreciated.


-- GNOME Bugzilla administrator (not a developer)

Note: if you want to discuss this, email bugmaster@gnome.org. And I do understand that this change is very disliked by almost everyone who responded here. Still, getting personal is something that I dislike. See also http://live.gnome.org/CodeOfConduct for a generalized writeup.

Just to give my 2 cents for users finding some solution to keep Ctrl-C for copy function. Anyhow it helped me at least to get used to with the new behaviour.

So, when you map COPY function to Ctrl-C, then now you can still send signals with CTRL-SHIFT-C or CTRL-Alt-C. So other words when you want finish some terminal job, just use SHIFT or ALT key and you can keep your Ctrl-C for copy only.  

Hope this small tip will help someone here :-)

I documented this accidental feature in 2008 at http://mikelward.com/news/2008/09/better-gnome-terminal-copy-and-paste.html

Until somebody submits a patch that doesn't undo the fix for bug 559728, then complaining here is not constructive.

I suggest trying Ctrl+Ins and Shift+Ins: they work pretty much everywhere.