Bug 140803

Summary:	auto-completion should show only such possible endings which to access in the list would cost less keypresses than to simply type the word in
Product:	[Applications] kate	Reporter:	Wolfram R. Sieber <Wolfram.R.Sieber>
Component:	general	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	christoph
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Wolfram R. Sieber 2007-01-29 02:15:02 UTC

Version: 2.5.5 (using KDE 3.5.5, Debian Package 4:3.5.5a.dfsg.1-5 (4.0))
Compiler: Target: i486-linux-gnu
OS: Linux (i686) release 2.6.18-3-k7

Auto-completion list currently usually offers the shortest matching first. That's nice so far. (Thanks for taking #127549 into consideration. :)

Furthermore, auto-completion offers a list of alternative completions. Still, I didn't tried to figure out its order, but I suppose its by frequency. Thus, the offered alternatives differ in length. Sometimes the length differs so much that one could get the word more quick by just typing it in instead of navigating the list.

Having such a case, such a list lacks a benefit: Navigating there costs more keypresses but just typing the word completely. In the second place, such a list even inveigles to use it, despite it would be quicker to leave it alone. (Other than the user, the machine is able to "know" this much quicker than a human could count and compare the necessary keystrokes.) Thus, in such a case, the list not only inveigles to use it while being superfluously, it even (and simply) distracts: If it wouldn't shine up, it wouldn't distract -- and in fact, in the case described above, it simply isn't necessary to show it.

.
One simple case is a "list" of completions offering just one remaining character. Just the need to look at the list costs a moment of time. And an offer of just one single completion, featuring nothing but a single character the user was about to type either way, makes no benefit.

Extended to two-entries "lists", the second completion of the list is superfluous, if it offers nothing but a two characters completion (since navigating the list would cost two keystrokes as well, Down and Enter).

In three-entries lists, any entries beyond the second one featuring nothing but a two-character completion would be completely pointless: Moving there plus hitting Enter, would cost more moves but just completing the word the usual way. -- And, in German, we've got lots of words varying in just two or three ending characters.

.
Again, I suppose to offer an auto-completion shortcut such as hitting the next non-common character of the alternatively offered completions (cf. #127549). Also, the bash-like completion approach suggested by #102461 looks fine, despite I didn't notice it in practice yet.

.
I looked up related bug reports, so let me mention them here for purposes of reference: #100203, #102461, #103842 (someway), and #127549.

Comment 1 Anders Lund 2007-02-04 12:08:35 UTC

SVN commit 630056 by alund:

sort the list for the popup completion
don't consider matches adding less than 2 characthers for popup completion. this could be made configurable, or smarter.

CCBUG: 140803


 M  +4 -3      docwordcompletion.cpp  
 M  +1 -1      docwordcompletion.h  


--- trunk/KDE/kdelibs/kate/plugins/wordcompletion/docwordcompletion.cpp #630055:630056
@@ -72,7 +72,8 @@
 void DocWordCompletionModel::saveMatches( KTextEditor::View* view,
                         const KTextEditor::Range& range)
 {
-  m_matches = allMatches( view, range );
+  m_matches = allMatches( view, range, 2 );
+  m_matches.sort();
 }
 
 QVariant DocWordCompletionModel::data(const QModelIndex& index, int role) const
@@ -114,7 +115,7 @@
 
 // Scan throughout the entire document for possible completions,
 // ignoring any dublets
-const QStringList DocWordCompletionModel::allMatches( KTextEditor::View *view, const KTextEditor::Range &range ) const
+const QStringList DocWordCompletionModel::allMatches( KTextEditor::View *view, const KTextEditor::Range &range, int minAdditionalLength ) const
 {
   QStringList l;
 
@@ -125,7 +126,7 @@
   int i( 0 );
   int pos( 0 );
   KTextEditor::Document *doc = view->document();
-  QRegExp re( "\\b(" + doc->text( range ) + "\\w+)" );
+  QRegExp re( "\\b(" + doc->text( range ) + "\\w{" + QString::number(minAdditionalLength) + ",})" );
   QString s, m;
   QHash<QString,int> seen;
 
--- trunk/KDE/kdelibs/kate/plugins/wordcompletion/docwordcompletion.h #630055:630056
@@ -58,7 +58,7 @@
     QVariant data(const QModelIndex& index, int role) const;
     virtual QModelIndex index(int row, int column, const QModelIndex& parent=QModelIndex()) const;
 
-    const QStringList allMatches( KTextEditor::View *view, const KTextEditor::Range &range  ) const;
+    const QStringList allMatches( KTextEditor::View *view, const KTextEditor::Range &range, int minAdditionalLength = 1 ) const;
 
   private:
     QStringList m_matches;

Comment 2 Dominik Haumann 2007-02-04 14:05:57 UTC

This should be configurable in the gui :) If I'm searching for an entry I'm not entirely sure it still should be able to show. I hope it is still available in the bidirectional search (find next/prev). Rather stupid example: was it m_search or m_searches? ;)

Comment 3 Anders Lund 2007-02-04 14:37:11 UTC

It only affects the popup, and i will add an option for it.

Comment 4 Wolfram R. Sieber 2007-02-04 22:17:15 UTC

Anders: Thanks for considering the request. Your are great. :-)


Dominik: Thanks for your support. :)

Comment 5 Maciej Pilichowski 2008-01-08 18:18:22 UTC

The exactly same report but for KDevelop (code-completion):
https://bugs.kde.org/show_bug.cgi?id=127100

Comment 6 Christoph Cullmann 2014-01-25 23:35:14 UTC

I disagree: having a word show up means, you have at least typed it once, this allows e.g. to avoid typing errors, even if it would be the same number of keypresses to type it.