test popupmenu question
115 views
Skip to first unread message
Christian Brabandt
Jul 23, 2016, 3:02:28 AM7/23/16
to vim...@vim.org
Bram,
I am writing a test for the popupmenu and the different keys, that can
be used there (:h popupmenu-keys)
And I have some questions.
1)
,----
| In the first state these keys have a special meaning:
| <BS> and CTRL-H Delete one character, find the matches for the word before
| the cursor. This reduces the list of matches, often to one
| entry, and switches to the second state.
`----
I fail to understand what this does, especially in difference to the
second state:
,----
| In the second and third state these keys have a special meaning:
| <BS> and CTRL-H Delete one character, find the matches for the shorter word
| before the cursor. This may find more matches.
`----
And whatever I do, using <bs> will always end the completion menu and
remove one character. Either from the last typed char or from the
inserted char. I can't seem to figure out, how to use <bs> to adjust the
number of entries in the completion menu.
2) The behaviour of the enter key
,----
| The behavior of the <Enter> key depends on the state you are in:
| first state: Use the text as it is and insert a line break.
| second state: Insert the currently selected match.
| third state: Use the text as it is and insert a line break.
`----
For me the <Enter> Key will always insert a line break.
Any clarification would be appreciated.
Best,
Christian
--
Das Wichtigste im Leben ist die Wahl des Berufes. Der Zufall
entscheidet darüber.
-- Blaise Pascal
I am writing a test for the popupmenu and the different keys, that can
be used there (:h popupmenu-keys)
And I have some questions.
1)
,----
| In the first state these keys have a special meaning:
| <BS> and CTRL-H Delete one character, find the matches for the word before
| the cursor. This reduces the list of matches, often to one
| entry, and switches to the second state.
`----
I fail to understand what this does, especially in difference to the
second state:
,----
| In the second and third state these keys have a special meaning:
| <BS> and CTRL-H Delete one character, find the matches for the shorter word
| before the cursor. This may find more matches.
`----
And whatever I do, using <bs> will always end the completion menu and
remove one character. Either from the last typed char or from the
inserted char. I can't seem to figure out, how to use <bs> to adjust the
number of entries in the completion menu.
2) The behaviour of the enter key
,----
| The behavior of the <Enter> key depends on the state you are in:
| first state: Use the text as it is and insert a line break.
| second state: Insert the currently selected match.
| third state: Use the text as it is and insert a line break.
`----
For me the <Enter> Key will always insert a line break.
Any clarification would be appreciated.
Best,
Christian
--
Das Wichtigste im Leben ist die Wahl des Berufes. Der Zufall
entscheidet darüber.
-- Blaise Pascal
Bram Moolenaar
Jul 23, 2016, 10:35:18 AM7/23/16
to Christian Brabandt, vim...@vim.org
Christian Brabandt wrote:
> Bram,
> I am writing a test for the popupmenu and the different keys, that can
> be used there (:h popupmenu-keys)
> And I have some questions.
> 1)
>
> ,----
> | In the first state these keys have a special meaning:
> | <BS> and CTRL-H Delete one character, find the matches for the word before
> | the cursor. This reduces the list of matches, often to one
> | entry, and switches to the second state.
> `----
>
> I fail to understand what this does, especially in difference to the
> second state:
and the first one is used for the text. That could be "completion".
Still the matches for "compl" are shown.
Then typing BS changes it to "completio" and only matches for that are
shown.
> ,----
> | In the second and third state these keys have a special meaning:
> | <BS> and CTRL-H Delete one character, find the matches for the shorter word
> | before the cursor. This may find more matches.
> `----
>
> And whatever I do, using <bs> will always end the completion menu and
> remove one character. Either from the last typed char or from the
> inserted char. I can't seem to figure out, how to use <bs> to adjust the
> number of entries in the completion menu.
differs from what the current text is.
> 2) The behaviour of the enter key
>
> ,----
> | The behavior of the <Enter> key depends on the state you are in:
> | first state: Use the text as it is and insert a line break.
> | second state: Insert the currently selected match.
> | third state: Use the text as it is and insert a line break.
> `----
>
> For me the <Enter> Key will always insert a line break.
menu,preview
> Any clarification would be appreciated.
completion works. The code is very complicated and there are many
corner cases.
--
ARTHUR: Listen, old crone! Unless you tell us where we can buy a shrubbery,
my friend and I will ... we will say "Ni!"
CRONE: Do your worst!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Christian Brabandt
Jul 23, 2016, 11:36:14 AM7/23/16
to vim...@vim.org
Hi Bram!
On Sa, 23 Jul 2016, Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
> > Bram,
> > I am writing a test for the popupmenu and the different keys, that can
> > be used there (:h popupmenu-keys)
>
> Thanks, that is useful.
>
> > And I have some questions.
> > 1)
> >
> > ,----
> > | In the first state these keys have a special meaning:
> > | <BS> and CTRL-H Delete one character, find the matches for the word before
> > | the cursor. This reduces the list of matches, often to one
> > | entry, and switches to the second state.
> > `----
> >
> > I fail to understand what this does, especially in difference to the
> > second state:
>
> For example, if you type "compl<Ctrl-N>" then you get a list of matches,
> and the first one is used for the text. That could be "completion".
> Still the matches for "compl" are shown.
> Then typing BS changes it to "completio" and only matches for that are
> shown.
Hm, that works when using <Ctrl-N>, but not when using, e.g.
calling the completion menu like this:
inoremap <f5> <c-r>=ListMonths()<cr>
Then <BS> will always end the completion menu and remove the last
letter.
I did not think, that there is a difference depending on how the
completion menu is called. This might be a bug.
> > ,----
> > | In the second and third state these keys have a special meaning:
> > | <BS> and CTRL-H Delete one character, find the matches for the shorter word
> > | before the cursor. This may find more matches.
> > `----
> >
> > And whatever I do, using <bs> will always end the completion menu and
> > remove one character. Either from the last typed char or from the
> > inserted char. I can't seem to figure out, how to use <bs> to adjust the
> > number of entries in the completion menu.
>
> The main difference is that in the second state the highlighted item
> differs from what the current text is.
Oh yes. Emphasis on "Cursor Key". Basically, that happens only then. Now
I understand.
>
> > 2) The behaviour of the enter key
> >
> > ,----
> > | The behavior of the <Enter> key depends on the state you are in:
> > | first state: Use the text as it is and insert a line break.
> > | second state: Insert the currently selected match.
> > | third state: Use the text as it is and insert a line break.
> > `----
> >
> > For me the <Enter> Key will always insert a line break.
>
> Not for me. Probably depends on 'completeopt'. My value is
> menu,preview
Yeah, once i figured, that I need to use the cursor keys to select the
match, it works as expected.
> It's possible that the help is not correct for all possible ways
> completion works. The code is very complicated and there are many
> corner cases.
Well, here is an updated patch for the popupmenu.
I think I also found a bug, and this makes the test currently fail.
Take this example from the test:
(The popupmenu is the one from the help for all months)
The initial state of the buffer is this:
,----
| D
| December2015
`----
(cursor at D, press <f5><c-e><c-e><c-e><c-e><enter>)
Now if you want to complete the letter D this should only complete to
December, since all other values do not match it and therefore it should
be completed immediately to December and no menu shown. Therefore,
pressing <C-e> afterwards should select the letter from below the
cursors line, so it should complete to "December2015" if you press <c-e>
4 times, then there should be a new line because of the enter and then
the "December2015" should be shown. So in the end, the buffer should
look like this:
,----
| December2015
|
| December2015
`----
For whatever reason, doing it interactively, this results in:
,----
| Dece
|
| December2015
`----
(because after inserting the match <c-e> is still in popupmenu mode and
"ends completion and goes back to what was there before selecting a
match")
However, a total mystery is to me, when the test is run, it will
complete to
,----
| December2015
| December2015
| December2015
`----
I have left this documented in the test. I am pretty sure, this is a
bug, and therefore, the test fails currently.
On a related note, since the "noinsert/noselect" property only seem to
change, what is inserted when the completion menu is entered initially,
It is hard to correctly test for that, therefore, I basically tested,
whether enter will insert a line break or not (difference in the states
as you explained above) and by that we know, if there was something
selected.
Mit freundlichen Grüßen
Christian
--
Die ersten vierzig Jahre unseres Lebens liefern den Text, die
folgenden dreißig den Kommentar dazu.
-- Arthur Schopenhauer
On Sa, 23 Jul 2016, Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
> > Bram,
> > I am writing a test for the popupmenu and the different keys, that can
> > be used there (:h popupmenu-keys)
>
> Thanks, that is useful.
>
> > And I have some questions.
> > 1)
> >
> > ,----
> > | In the first state these keys have a special meaning:
> > | <BS> and CTRL-H Delete one character, find the matches for the word before
> > | the cursor. This reduces the list of matches, often to one
> > | entry, and switches to the second state.
> > `----
> >
> > I fail to understand what this does, especially in difference to the
> > second state:
>
> For example, if you type "compl<Ctrl-N>" then you get a list of matches,
> and the first one is used for the text. That could be "completion".
> Still the matches for "compl" are shown.
> Then typing BS changes it to "completio" and only matches for that are
> shown.
calling the completion menu like this:
inoremap <f5> <c-r>=ListMonths()<cr>
Then <BS> will always end the completion menu and remove the last
letter.
I did not think, that there is a difference depending on how the
completion menu is called. This might be a bug.
> > ,----
> > | In the second and third state these keys have a special meaning:
> > | <BS> and CTRL-H Delete one character, find the matches for the shorter word
> > | before the cursor. This may find more matches.
> > `----
> >
> > And whatever I do, using <bs> will always end the completion menu and
> > remove one character. Either from the last typed char or from the
> > inserted char. I can't seem to figure out, how to use <bs> to adjust the
> > number of entries in the completion menu.
>
> The main difference is that in the second state the highlighted item
> differs from what the current text is.
I understand.
>
> > 2) The behaviour of the enter key
> >
> > ,----
> > | The behavior of the <Enter> key depends on the state you are in:
> > | first state: Use the text as it is and insert a line break.
> > | second state: Insert the currently selected match.
> > | third state: Use the text as it is and insert a line break.
> > `----
> >
> > For me the <Enter> Key will always insert a line break.
>
> Not for me. Probably depends on 'completeopt'. My value is
> menu,preview
match, it works as expected.
> It's possible that the help is not correct for all possible ways
> completion works. The code is very complicated and there are many
> corner cases.
I think I also found a bug, and this makes the test currently fail.
Take this example from the test:
(The popupmenu is the one from the help for all months)
The initial state of the buffer is this:
,----
| D
| December2015
`----
(cursor at D, press <f5><c-e><c-e><c-e><c-e><enter>)
Now if you want to complete the letter D this should only complete to
December, since all other values do not match it and therefore it should
be completed immediately to December and no menu shown. Therefore,
pressing <C-e> afterwards should select the letter from below the
cursors line, so it should complete to "December2015" if you press <c-e>
4 times, then there should be a new line because of the enter and then
the "December2015" should be shown. So in the end, the buffer should
look like this:
,----
| December2015
|
| December2015
`----
For whatever reason, doing it interactively, this results in:
,----
| Dece
|
| December2015
`----
(because after inserting the match <c-e> is still in popupmenu mode and
"ends completion and goes back to what was there before selecting a
match")
However, a total mystery is to me, when the test is run, it will
complete to
,----
| December2015
| December2015
| December2015
`----
I have left this documented in the test. I am pretty sure, this is a
bug, and therefore, the test fails currently.
On a related note, since the "noinsert/noselect" property only seem to
change, what is inserted when the completion menu is entered initially,
It is hard to correctly test for that, therefore, I basically tested,
whether enter will insert a line break or not (difference in the states
as you explained above) and by that we know, if there was something
selected.
Mit freundlichen Grüßen
Christian
--
Die ersten vierzig Jahre unseres Lebens liefern den Text, die
folgenden dreißig den Kommentar dazu.
-- Arthur Schopenhauer
Christian Brabandt
Jul 30, 2016, 11:54:57 AM7/30/16
to vim...@vim.org
On Sa, 23 Jul 2016, Christian Brabandt wrote:
> Hm, that works when using <Ctrl-N>, but not when using, e.g.
> calling the completion menu like this:
>
> inoremap <f5> <c-r>=ListMonths()<cr>
>
> Then <BS> will always end the completion menu and remove the last
> letter.
>
> I did not think, that there is a difference depending on how the
> completion menu is called. This might be a bug.
I am still not sure how to handle this.
> Hm, that works when using <Ctrl-N>, but not when using, e.g.
> calling the completion menu like this:
>
> inoremap <f5> <c-r>=ListMonths()<cr>
>
> Then <BS> will always end the completion menu and remove the last
> letter.
>
> I did not think, that there is a difference depending on how the
> completion menu is called. This might be a bug.
test, when the current key is <c-e> that the popupmen is still visible
and if not, handle it like a normal <c-e> character. This fixes at least
the test.
Best,
Christian
--
Die Fähigkeit, seine Muße klug auszufüllen, ist die letzte Stufe der
persönlichen Kultur.
-- Bertrand A. W. Russell
Bram Moolenaar
Aug 2, 2016, 4:36:31 PM8/2/16
to Christian Brabandt, vim...@vim.org
a bit of a mess...
--
It might look like I'm doing nothing, but at the cellular level
I'm really quite busy.
h_east
Sep 11, 2016, 12:52:14 PM9/11/16
to vim_dev, vim...@vim.org
Hi ChrisBra, Bram and list,
2016-7-24(Sun) 0:36:14 UTC+9 Christian Brabandt:
I have investigated this behavior.
Related vim_dev threads:
- Patch 7.4.2146
https://groups.google.com/d/msg/vim_dev/75ZXlRlBzl4/DDnqvSn9BgAJ
- [vim/vim] VIM 7.4: Possible regression via patch 2146? (#972)
https://groups.google.com/d/msg/vim_dev/mQ2YacpOKvo/vOsgkU-2AQAJ
- Patch 7.4.2188
https://groups.google.com/d/msg/vim_dev/e2Rr8Px3qkQ/1XWiAQ0LAgAJ
I think the series of <C-E> behavior is correct.
>
> (cursor at D, press <f5><c-e><c-e><c-e><c-e><enter>)
>
> Now if you want to complete the letter D this should only complete to
> December, since all other values do not match it and therefore it should
> be completed immediately to December and no menu shown. Therefore,
> pressing <C-e> afterwards should select the letter from below the
> cursors line, so it should complete to "December2015" if you press <c-e>
> 4 times, then there should be a new line because of the enter and then
> the "December2015" should be shown. So in the end, the buffer should
> look like this:
>
> ,----
> | December2015
> |
> | December2015
> `----
"the popup menu is not visible" is not equivalent to "the completion mode is not active".
After the type <F5>, Vim still stay in the first state of the completion mode.
It is not related to the visible of popup menu.
Check on the gdb.
(gdb) p compl_started
$4 = 1
(gdb) p pum_visible()
$5 = 0
So that, the first <C-E> behavior `complete_CTRL-E` is correct.
Of course, the second and more <C-E> is `i_CTRL_E`.
>
> For whatever reason, doing it interactively, this results in:
>
> ,----
> | Dece
> |
> | December2015
> `----
> (because after inserting the match <c-e> is still in popupmenu mode and
> "ends completion and goes back to what was there before selecting a
> match")
>
> However, a total mystery is to me, when the test is run, it will
> complete to
>
> ,----
> | December2015
> | December2015
> | December2015
> `----
Hmm?, I got the following result. (make test_popup in 7.4.2358)
1 FAILED:
Found errors in Test_popup_complete2():
function RunTheTest[9]..Test_popup_complete2 line 10: Expected ['December2015', '', 'December2015'] but got ['Dece', '', 'December2015']
I think `['Dece', '', 'December2015']` is right.
>
> I have left this documented in the test. I am pretty sure, this is a
> bug, and therefore, the test fails currently.
>
> On a related note, since the "noinsert/noselect" property only seem to
> change, what is inserted when the completion menu is entered initially,
>
> It is hard to correctly test for that, therefore, I basically tested,
> whether enter will insert a line break or not (difference in the states
> as you explained above) and by that we know, if there was something
> selected.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)
Christian Brabandt
Sep 11, 2016, 1:56:04 PM9/11/16
to vim_dev
On So, 11 Sep 2016, h_east wrote:
> Hi ChrisBra, Bram and list,
> 2016-7-24(Sun) 0:36:14 UTC+9 Christian Brabandt:
> Hi ChrisBra, Bram and list,
> 2016-7-24(Sun) 0:36:14 UTC+9 Christian Brabandt:
> > On Sa, 23 Jul 2016, Bram Moolenaar wrote:
> > > Christian Brabandt wrote:
> > I think I also found a bug, and this makes the test currently fail.
> > Take this example from the test:
> >
> > (The popupmenu is the one from the help for all months)
> > The initial state of the buffer is this:
> > ,----
> > | D
> > | December2015
> > `----
>
> I have investigated this behavior.
>
> Related vim_dev threads:
> - Patch 7.4.2146
> https://groups.google.com/d/msg/vim_dev/75ZXlRlBzl4/DDnqvSn9BgAJ
> - [vim/vim] VIM 7.4: Possible regression via patch 2146? (#972)
> https://groups.google.com/d/msg/vim_dev/mQ2YacpOKvo/vOsgkU-2AQAJ
> - Patch 7.4.2188
> https://groups.google.com/d/msg/vim_dev/e2Rr8Px3qkQ/1XWiAQ0LAgAJ
>
> I think the series of <C-E> behavior is correct.
okay.
> > > Christian Brabandt wrote:
> > I think I also found a bug, and this makes the test currently fail.
> > Take this example from the test:
> >
> > (The popupmenu is the one from the help for all months)
> > The initial state of the buffer is this:
> > ,----
> > | D
> > | December2015
> > `----
>
> I have investigated this behavior.
>
> Related vim_dev threads:
> - Patch 7.4.2146
> https://groups.google.com/d/msg/vim_dev/75ZXlRlBzl4/DDnqvSn9BgAJ
> - [vim/vim] VIM 7.4: Possible regression via patch 2146? (#972)
> https://groups.google.com/d/msg/vim_dev/mQ2YacpOKvo/vOsgkU-2AQAJ
> - Patch 7.4.2188
> https://groups.google.com/d/msg/vim_dev/e2Rr8Px3qkQ/1XWiAQ0LAgAJ
>
> I think the series of <C-E> behavior is correct.
> > ,----
> > | Dece
> > |
> > | December2015
> > `----
> > (because after inserting the match <c-e> is still in popupmenu mode and
> > "ends completion and goes back to what was there before selecting a
> > match")
> >
> > However, a total mystery is to me, when the test is run, it will
> > complete to
> >
> > ,----
> > | December2015
> > | December2015
> > | December2015
> > `----
>
> Hmm?, I got the following result. (make test_popup in 7.4.2358)
>
> 1 FAILED:
> Found errors in Test_popup_complete2():
> function RunTheTest[9]..Test_popup_complete2 line 10: Expected ['December2015', '', 'December2015'] but got ['Dece', '', 'December2015']
>
> I think `['Dece', '', 'December2015']` is right.
assert.
Best,
Christian
--
Alles was man will, kostet etwas mehr als es wert ist.
(Das zweite Gesetz der Thermodynamik)
Christian Brabandt
Sep 22, 2016, 11:34:35 AM9/22/16
to vim_dev
Hi,
On Mi, 21 Sep 2016, h_east wrote:
> func! Test_popup_complete2()
> - " Insert match immediately, if there is only one match
> - " <c-e> Should select a character from the line below
> - " TODO: test disabled because the code change has been reverted.
> - throw "Skipped: Bug with <c-e> and popupmenu not fixed yet"
> + " 'the popup menu is not visible' is not equivalent to 'the completion mode
> + " is not active'.
> + " After the type <F5>, Vim still stay in the first state of the completion
> + " mode. It is not related to the visible of popup.
> + " So that, the first <C-E> behavior is `complete_CTRL-E`, and the second and
> + " more <C-E> is `i_CTRL_E`
How about this:
Although the popupmenu is not visible, this does not mean completion
mode has ended. After pressing <f5> to complete the currently typed
char, Vim still stays in the first state of the completion
(:h ins-completion-menu), although the popupmenu wasn't shown <c-e> will
remove the inserted completed text (:h complete_CTRL-E), while the
following <c-e> will behave like expected (:h i_CTRL-E)
> - call assert_equal(["December2015", "", "December2015"], getline(1,3))
> + call assert_equal(["Dece", "", "December2015"], getline(1,3))
Looks good to me.
Best,
Christian
--
Autokraten lieben meist kleine Kinder. Sie schränken ihre Macht nicht
ein, dafür sind sie ihnen dankbar.
-- Ludwig Marcuse (Argumente und Rezepte)
On Mi, 21 Sep 2016, h_east wrote:
> func! Test_popup_complete2()
> - " Insert match immediately, if there is only one match
> - " <c-e> Should select a character from the line below
> - " TODO: test disabled because the code change has been reverted.
> - throw "Skipped: Bug with <c-e> and popupmenu not fixed yet"
> + " 'the popup menu is not visible' is not equivalent to 'the completion mode
> + " is not active'.
> + " After the type <F5>, Vim still stay in the first state of the completion
> + " mode. It is not related to the visible of popup.
> + " So that, the first <C-E> behavior is `complete_CTRL-E`, and the second and
> + " more <C-E> is `i_CTRL_E`
How about this:
Although the popupmenu is not visible, this does not mean completion
mode has ended. After pressing <f5> to complete the currently typed
char, Vim still stays in the first state of the completion
(:h ins-completion-menu), although the popupmenu wasn't shown <c-e> will
remove the inserted completed text (:h complete_CTRL-E), while the
following <c-e> will behave like expected (:h i_CTRL-E)
> - call assert_equal(["December2015", "", "December2015"], getline(1,3))
> + call assert_equal(["Dece", "", "December2015"], getline(1,3))
Looks good to me.
Best,
Christian
--
Autokraten lieben meist kleine Kinder. Sie schränken ihre Macht nicht
ein, dafür sind sie ihnen dankbar.
-- Ludwig Marcuse (Argumente und Rezepte)
h_east
Sep 22, 2016, 11:57:22 AM9/22/16
to vim_dev
Hi ChrisBra, Bram and list,
2016-9-23(Fri) 0:34:35 UTC+9 Christian Brabandt:
> Hi,
>
> On Mi, 21 Sep 2016, h_east wrote:
> > func! Test_popup_complete2()
> > - " Insert match immediately, if there is only one match
> > - " <c-e> Should select a character from the line below
> > - " TODO: test disabled because the code change has been reverted.
> > - throw "Skipped: Bug with <c-e> and popupmenu not fixed yet"
> > + " 'the popup menu is not visible' is not equivalent to 'the completion mode
> > + " is not active'.
> > + " After the type <F5>, Vim still stay in the first state of the completion
> > + " mode. It is not related to the visible of popup.
> > + " So that, the first <C-E> behavior is `complete_CTRL-E`, and the second and
> > + " more <C-E> is `i_CTRL_E`
>
>
> How about this:
> Although the popupmenu is not visible, this does not mean completion
> mode has ended. After pressing <f5> to complete the currently typed
> char, Vim still stays in the first state of the completion
> (:h ins-completion-menu), although the popupmenu wasn't shown <c-e> will
> remove the inserted completed text (:h complete_CTRL-E), while the
> following <c-e> will behave like expected (:h i_CTRL-E)
Nicely. I like this. Thanks👍.
>
> On Mi, 21 Sep 2016, h_east wrote:
> > func! Test_popup_complete2()
> > - " Insert match immediately, if there is only one match
> > - " <c-e> Should select a character from the line below
> > - " TODO: test disabled because the code change has been reverted.
> > - throw "Skipped: Bug with <c-e> and popupmenu not fixed yet"
> > + " 'the popup menu is not visible' is not equivalent to 'the completion mode
> > + " is not active'.
> > + " After the type <F5>, Vim still stay in the first state of the completion
> > + " mode. It is not related to the visible of popup.
> > + " So that, the first <C-E> behavior is `complete_CTRL-E`, and the second and
> > + " more <C-E> is `i_CTRL_E`
>
>
> How about this:
> Although the popupmenu is not visible, this does not mean completion
> mode has ended. After pressing <f5> to complete the currently typed
> char, Vim still stays in the first state of the completion
> (:h ins-completion-menu), although the popupmenu wasn't shown <c-e> will
> remove the inserted completed text (:h complete_CTRL-E), while the
> following <c-e> will behave like expected (:h i_CTRL-E)
>
> > - call assert_equal(["December2015", "", "December2015"], getline(1,3))
> > + call assert_equal(["Dece", "", "December2015"], getline(1,3))
>
> Looks good to me.
I update a patch.
Bram>
Please include this patch.
Bram Moolenaar
Sep 22, 2016, 3:27:50 PM9/22/16
to h_east, vim_dev
--
You were lucky to have a LAKE! There were a hundred and sixty of
us living in a small shoebox in the middle of the road.
Reply all
Reply to author
Forward
0 new messages