[vim/vim] tests: no enough testing for complete_info() "auto" (PR #21152)

[zeertzjq]

Problem: tests: no enough testing for complete_info() "auto".
Solution: Check triggering manual completion before 'autocompletedelay'
expires.

---

You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/21152

Commit Summary

• 506501e tests: no enough testing for complete_info() "auto"

File Changes

(1 file)

• M src/testdir/test_ins_complete.vim (9)

Patch Links:

• https://github.com/vim/vim/pull/21152.patch
• https://github.com/vim/vim/pull/21152.diff

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21152@github.com>

[zeertzjq]

zeertzjq left a comment (vim/vim#21152)

I noticed a problem here. When triggering manual completion before 'autocompletedelay' expires, some effects specific to autocompletion (e.g. implicit "noselect") is applied to the manual completion. This happens because compl_autocomplete is true when the manual completion is triggered. It doesn't look right to me.

This makes me wonder whether it's really necessary to have two separate compl_autocomplete and compl_autostarted flags. Changing get_complete_info() to use compl_autocomplete instead of compl_autostarted still passes the tests added in #21143 and only fails the test case added in this PR. And if compl_autocomplete has a wrong value it likely indicates a bug.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21152/c5421430166@github.com>

[h_east]

h-east left a comment (vim/vim#21152)

Reproduced: with 'autocompletedelay' set, CTRL-X CTRL-O typed while the delay
runs gives complete_info() {'auto': 0, 'selected': -1}. The report says a key
asked for it, the menu behaves as an automatic one.

This is not new with the "auto" flag: nothing clears compl_autocomplete when
a key takes the completion over. Arming the delay sets it, the key that
follows clears only the two pending flags, and it is still set at the
implicit "noselect" in insexpand.c:1789.

So I would clear compl_autocomplete where a typed key takes the completion
over, rather than report it as "auto". Reporting it would answer 1 for a
completion a key asked for, which is what "auto" exists to tell apart, so the
test here is right.

The two answer different questions: compl_autocomplete how the completion
behaves from here on, "auto" how it began.

This is what I have:

diff --git a/src/edit.c b/src/edit.c
--- a/src/edit.c
+++ b/src/edit.c
@@ -684,6 +684,9 @@ edit(
 	    // Don't want delayed autocompletion from the previous key either.
 	    ins_compl_clear_autocomplete_delay();
 	    ins_compl_disarm_autostart();
+	    // This key asks for the completion, so it is not an automatic one.
+	    if (!ins_compl_active())
+		ins_compl_disable_autocomplete();
 	}

 #ifdef FEAT_RIGHTLEFT
diff --git a/src/insexpand.c b/src/insexpand.c
--- a/src/insexpand.c
+++ b/src/insexpand.c
@@ -7520,6 +7520,15 @@ ins_compl_enable_autocomplete(void)
 #endif
 }

+/*
+ * Disable autocompletion
+ */
+    void
+ins_compl_disable_autocomplete(void)
+{
+    compl_autocomplete = FALSE;
+}
+
 /*
  * Remember that Vim is about to start a completion by itself, rather than
  * because a key was typed to ask for one.

The "ins_compl_active()" guard is for a menu that is already up: typing into
an automatic completion comes through the same place, and that one goes on
being automatic.

With it, the case in this PR reads {'auto': 0, 'selected': 0}, and the
automatic completion is unchanged at {'auto': 1, 'selected': -1}.

If this looks right to you, I will add a test and open a PR.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21152/c5426413427@github.com>

[zeertzjq]

zeertzjq left a comment (vim/vim#21152)

"This key asks for the completion" in the comment doesn't look right. Any key can be typed before 'autocompletedelay' expires, not necessarily a key that asks for completion.

The two answer different questions: compl_autocomplete how the completion
behaves from here on, "auto" how it began.

Yes, but the difference between these two questions don't seem large enough to me. They are quite dependent are each other.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21152/c5426827533@github.com>

[h_east]

h-east left a comment (vim/vim#21152)

Right about the comment, any key comes through there. Reworded:

	    // A completion already on screen goes on being what it was.
	    if (!ins_compl_active())
		ins_compl_disable_autocomplete();

compl_autocomplete is derived from the option and is set again while a
completion is up, ins_compl_new_leader() among the places.
compl_autostarted is written once, where the completion starts. Report a
value that moves and the answer to "how did this begin" can change under a
menu that never went away.

Where they agree is where the patch puts them. That is the aim, not a reason
to read one for the other.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21152/c5427198969@github.com>

[Christian Brabandt]

chrisbra left a comment (vim/vim#21152)

thanks

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21152/c5429804495@github.com>