SUMMARY Autocomplete should not be used if not explicitly validated, especially when there is a risk of a delay. It occasionally makes the wrong program run. STEPS TO REPRODUCE 1. Alt+F2 2. type 2+2 3. type enter OBSERVED RESULT See that a document called 2-something.pdf is open after a noticeable delay. EXPECTED RESULT 4 is chosen. (And by the way, the result of the computation takes a considerable time to show up the first time, but this is probably another bug). And: STEPS TO REPRODUCE 1. Alt+F2, then type firefox -P customprofile, then type enter 2. Alt+F2, then type firefox. Notice that " -P customprofile" is added and selected (which is good) 3. type enter. OBSERVED RESULT "firefox -P customprofile" is run instead of firefox. EXPECTED RESULT firefox is run. firefox -P customprofile is run only if right arrow is typed, to validate the autocompletion. I'm actually alternating between firefox and firefox -P customprofile, so actually, the current behavior of KRunner means that when I want to just run firefox, firefox -P customprofile is suggested, and then when I want to run firefox -P customprofile, it is not suggested until I type a space after firefox. I feel KRunner should be consistent with the behavior of zsh-autosuggestions or fish autosuggestions. Including having ctrl+→ validate one word from autocompletion would be nice. The autocompletion would be shown in grey until validated. See also http://jeremymikkola.com/posts/2019_03_19_rules_for_autocomplete.html (and HN discussion if interested: https://news.ycombinator.com/item?id=19438826). SOFTWARE/OS VERSIONS Linux/KDE Plasma: OpenSUSE KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.58.0 Qt Version: 5.0.7-1-default
The request in this bug would be a huge regression to my workflow. Needing to explicitly validate the autocompleted result would make using KRunner slower and require more brainpower. To me one of the biggest advantages is how you can use it practically at the speed of thought. I think one of the real bugs here is that "2+2" didn't give you the calculator as the top entry. > (And by the way, the result of the computation takes a > considerable time to show up the first time, but this is probably another > bug). Yep, it's Bug 406384, which has an easy workaround (see bug report for more details).
From your answer, I guess there is no "one size fits all" solution here. I guess the workaround for me is to use ctrl+shift+→ a number of times then backspace + backspace. A solution could be to add an option to make KRunner behave like fish/zsh auto suggestion, but I would understand that it would be a pain to maintain for something that is not that significant. Thanks for referencing bug 406384 :-)
Thanks. I'm going to close this for now, but we would definitely consider a reasonable patch. If you're interested in producing one, see https://community.kde.org/Get_Involved/development https://community.kde.org/Infrastructure/Phabricator Thanks!
All right, I don't have much time right now, but I'll definitely consider it later. It will probably be fun to do. Thank you, and thanks for your work on KDE :-) Your blog won a subscriber by the way.
I think that's the nicest comment I've ever gotten from someone after closing their bug as RESOLVED INTENTIONAL! :)