Version: (using KDE 3.5.8) Installed from: SuSE RPMs Please fix the shortcuts configuring. Why? Find such editing function as "delete line". Then find such editing function as "indent". My suggestion -- integrate all existing places to configure keyboard shortcuts in one dialog (or even better, as one of the settings tab).
What ends up under "Configure Editor" is not KDevelops business, if you want that removed file a bugreport against katepart. And there's no other place besides "Configure shortcuts" in KDevelop that allows to configure shortcuts.
Andreas, could you please redirect it then to katepart -- there is no point opening exactly the same report just for katepart. Thank you.
It might be worth mentioning that every app (afaik) that embeds katepart behaves like this - including Kate and KWrite - and it has been like this for many years. I don't know why it's done like this, and I do agree it is confusing / unexpected.
@Maciej: Yes, sorry, wasn't thinking :) Its the same thing in kde4 btw. I'll ask kwrite-devel what the use-case for this is. And to explain this a bit more for the kate devs: Kate shortcuts show up in the usual "Configure Shortcuts" Dialog in any application that embeds katepart and still there's a separate shortcut page in the "configure editor/kate" dialog itself. Though the latter only has some of the shortcuts in it, thats highly confusing to users.
I've talked to the kate devs: http://lists.kde.org/?t=120673166200011&r=1&w=2 So we both missed that there's no duplication of shortcuts and apparently the kate devs want these actions to be separate from the other ones. So I'm closing this as wontfix.
I'm personally very open for finding a way to configure them in a common dialog, which would both avoid confusing on user side and avoid conflicts. It's just not easy :)
I guess I should stop doing things when I'm in a hurry.... Well, the solution is pretty easy - IMHO: Provide those actions via the parts actionCollection. That doesn't mean they are visible in the GUI - unless you ship a .ui file that puts them into a the menu/toolbar. I don't think there's a way to completely force these actions to be private to the part. If an application developer wants to put them into its menu he most probably can find a way to do that, wether the actions are accesible via the collection or not - in the worst case he'll just copy some code from katepart.
Apart from the above, making these actions private inside katepart disallows to easily use shortcut schemes (that will come into KDE 4.2). So if I want kate with emacs-like shortcuts I can load a scheme, but I'll still have to go to the other shortcuts editor and configure those manually or load the scheme there again. I still don't understand the reasoning behind keeping these shortcuts out of the action collection. You can't force app-devs to do the "right thing" here, you'll have to trust them that they don't do stupid things with those actions in the collection.
This looks like a dupe of Bug 52191, which describes the situation quite well. It's been around since 2002. *** This bug has been marked as a duplicate of 52191 ***