The problem you mention with Emacs/Nano etc. is fixed in the current version of Konsole without needing that option to be unchecked.

When emacs/nano etc. changes the terminal flow control settings Konsole now notices and avoids showing the warning accordingly.

As far as i can tell, it's still broken for remote tty emacs (nano, etc) sessions.  This is a big problem for me, and probably for others.

Out of curiosity, why is the option disabled?  Is it broken?

i take it back - sometimes changes in the flow characteristics of the remote sessions are conveyed back to be noticed by konsole.  sometimes, however, they are not - i noticed this problem in one of those situations.  i'll see if i can reproduce it, and report it here.

Not being able to turn off flow control also breaks searching in the history of bash/zsh. ctrl-r starts a back-search, but I frequently use ctrl-s to come back to a found item I accidentally skipped.
ex: ctrl-r ls  [to search for the last line using ls]
    ctrl-r ctrl-r  [search the next matches]
    [I find that I skipped the entry I actually wanted to find]
    ctrl-s ctrl-s  [to come back to the skipped match]

(In reply to comment #1)
> The problem you mention with Emacs/Nano etc. is fixed in the current version of
> Konsole without needing that option to be unchecked.
> 
> When emacs/nano etc. changes the terminal flow control settings Konsole now
> notices and avoids showing the warning accordingly.

this has continued to be a problem, previously sporadic and now, after my upgrade to kde 4.10, constant.  every new konsole windows starts catching flow control characters, preventing use of ctrl-s in bash and tty emacs, and even worse, ctrl-x ctrl-s (save file) in tty emacs.  the option to disable flow control handling is still inhibited, leaving it permanently on.

my workaround is to issue 'stty -ixon' to my shell, when i start a new window.  i am reluctant to make that a part of my permanent shell initialization, since i use it on other platforms where this is not broken (and i don't know the collateral consequences of disabling flow control everywhere).

i continue to wonder why the option is not just re-enabled, so the configuration can be brought directly to bear where it is a problem?

I too use ctrl-r *and* ctrl-s a lot in my everyday Bash tasks. Would love to be able to turn off that flow control catching in konsole. I also wonder why it is grayed out.
(Fedora Rawhide, kdelibs-4.1.2-5.fc10.i386)

I found a workaround, just go to the configure shortcuts, and assign the Cntrl+S shortkey to some other commands :).  ( I used to clear Scrollback, or one may use as alternate copy shortcut). 

put : 
stty -ixon

on $HOME/.bashrc workaround this problem. 

I didn't see an answer to this question: "Out of curiosity, why is the option disabled? Is it broken?".

What is the point of not fixing it?  Judging by the number of votes this annoys _a lot_ of people.  Why not just simply enable that preference setting and be done with it?

I've same question as Paul -- why is that checkbox disabled at all?

Robert, I see a comment in the code saying that there is a bug in kde 4.1 which prevents flow control from working.  I couldn't find anything mentioning what the bug was.

Well - apparently flow control works too well for many people.

I do like the possibility to have flow control, but it would be better to make the shortcut key customizable, given that Ctrl-S is defined by bash.

SVN commit 955413 by hindenburg:

Allow flow control to be disabled.  The current session will not be affected.

BUG: 165457


 M  +0 -5      EditProfileDialog.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=955413

I seeing this patch still is not applied on kde-4.2.3 ! 

cat kdebase-4.2.3/apps/konsole/src/EditProfileDialog.cpp

Nor 4.2.4 for that matter.

(FWIW, I think it's too late for 4.2.4 now and this means backporting this is probably moot now. Still, why wasn't the fix backported back when it was made?)

As mentioned, the option was disabled due to a bug in KDE. Maybe noone stepped forward to test if that bug still is there in 4.2.
Now it is too late. 4.2.4 is tagged, there will likely be no 4.2.5 and 4.3 is close.
Please let this issue go for 4.2.x and test if it works like it should in 4.3 beta x instead. For me it does. :)

We've shipped 4.2.2 builds with that patch in Fedora and it worked just fine. (The patch accidentally got dropped in our 4.2.3 builds because we thought it's fixed upstream, which is part of why I'm complaining about the fix not having been backported.)

I am not a Konsole developer, so this is just my personal opinion.

I understand your resentment. That's nothing that can be undone now though.
It would have been nice to see that fix backported, no question, but it is your fault dropping the patch.

Robert, who did most of the KDE 4 work in Konsole seems a bit busy with other stuff these days. That's unfortunate but cannot be avoided either. There are some projects inside KDE that are barely maintained.

If it was a few weeks earlier, I would backport and test it but it is not and I was not aware of this not-backported-yet situation until today. Again, unfortunate but also just happened.

Regards

SVN commit 977678 by kkofler:

Allow flow control to be disabled.  The current session will not be affected.

CCBUG: 165457

(backport revision 955413 by hindenburg as this works just fine since at least 4.2.2, probably since 4.2.0)

 M  +0 -5      EditProfileDialog.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=977678

(The backport may never end up in a release, but at least people building the 4.2 branch will pick it up.)