SUMMARY The return key being the shortcut to use to pick an auto-complete choice potentially breaks text input in all languages where there is no line terminator and not commonly a closing bracket at the end of each line, because typing a partial match of what is also offered as an auto-complete entry and pressing enter to go to the next line is indistinguishable to intending to pick the auto-complete. Affected languages are for example Lua and Python. For these languages it should be possible both for the user to manually switch the auto-complete confirm shortcut to something compatible like the common choice of tab or shift+space or something like that, and for a language XML as specified for the katepart syntax highlighting to say that this language can't be inputted without bigger issues with return key triggering auto-complete, such that then kate defaults to something else. Otherwise, the experience would be broken out of the box. STEPS TO REPRODUCE 1. Open Settings > Configure Kate... 2. Click "Editing" tab 3. Click "Auto-completion" 4. Check for any way to change the auto complete confirm shortcut that picks a choice from the popup 5. Close settings 6. Open Settings > Configure Keyboard Shortcuts 7. Enter search term "complet" (no "e" so it still matches e.g. completion) 8. Check for any way to change the auto complete confirm shortcut that picks a choice from the popup OBSERVED RESULT 1. there appears to be no way to change the auto-complete confirm shortcut by the user 2. there appears to be also no way to change it via the kate-part syntax-highlighting XML as a default for all users of that language EXPECTED RESULT both of the things listed in "observed result" are possible SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: openSUSE Slowroll (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.114.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/660
Ooh that's so great that someone is looking at it! Maybe this is helpful: I've been thinking some more, maybe the least controversial setting would have the options for accepting auto-complete with enter of "Always On", "Language-Dependent", "Always Off"? With "Language-Dependent" depending on some syntax-highlighting.xml attribute for the "language" tag similar to the "indenter" one, it could maybe be named "autocomplete_enter_by_default" and have a value of "true"/"false"? If it's "false" then the "Language-Dependent" setting would turn it off too. Maybe it's just me but I think for Lua and Python and Go for example it would be better to default this to "off" for people who want a smart language dependent behavior, while of course for C/C++/Rust it wouldn't be an issue. I hope this is somehow helping.
We have other ways to pre configure stuff for certain languages without involving syntax highlighting, but we only do that if we are 100% sure that this is the right thing to do i.e.,no opinions there. For e.g., using tabs for Go language. You can still configure this per language/file-type though, but its something the user will have to decide for themselves.
Hm, but why wouldn't you want to have the hopefully most sane default based on file type out of the box? I guess if the XML isn't the right place for it, it could be kept in some other place. If you really wanted a unified default no matter what, then maybe the less destructive disabling of enter to pick an auto complete item might be the better choice. Especially if the popup has a short help text instructing to use tab, this doesn't seem likely to confuse anyone and won't occasionally somewhat literally break any typed code.
Git commit 93e0d56d0e13fca4e33a3dd6e460d9a1986c82a8 by Christoph Cullmann, on behalf of Waqar Ahmed. Committed on 24/01/2024 at 09:37. Pushed by cullmann into branch 'master'. Allow to configure 'enter-to-insert-completion' per file type M +1 -1 src/dialogs/completionconfigtab.ui M +24 -21 src/document/katedocument.cpp M +1 -0 src/include/ktexteditor/view.h M +1 -1 src/inputmode/katenormalinputmode.cpp M +1 -1 src/utils/kateconfig.cpp M +5 -0 src/variableeditor/variablelineedit.cpp https://invent.kde.org/frameworks/ktexteditor/-/commit/93e0d56d0e13fca4e33a3dd6e460d9a1986c82a8
Git commit 6a87ba2a39fcf5d33242468d71178b79bef9188f by Christoph Cullmann, on behalf of Waqar Ahmed. Committed on 24/01/2024 at 09:37. Pushed by cullmann into branch 'master'. Allow disabling 'enter to insert completion' By default it is enabled M +12 -2 src/dialogs/completionconfigtab.ui M +3 -0 src/dialogs/katedialogs.cpp M +7 -1 src/inputmode/katenormalinputmode.cpp M +1 -0 src/utils/kateconfig.cpp M +1 -0 src/utils/kateconfig.h https://invent.kde.org/frameworks/ktexteditor/-/commit/6a87ba2a39fcf5d33242468d71178b79bef9188f
Thanks so much for fixing it! I still would hope for a better default but I'm guessing the close means it was fully decided against now
Changing this default means breaking other people's workflow (established since 20 years). I am usually against this unless there is a good reason to break a workflow.
Wouldn't it be possible to only change the default for new installs? And only for the languages where it makes sense, that's part of why I suggested a language-dependent default. I assume most C/C++ coders for example would expect return key for auto-complete. However, for Lua for example this is an entirely different matter.
I think the default shall stay at is, we got close to zero complaints about that for over a decade, that means it can't be that bad.
That seems like a logical fallacy, but I guess I can't change your mind. My assumption would be most users who ran into this either begrudgingly put up with it, or just moved on to other editors.