HOME on line 2 sends cursor to line 1 if line 1 is blank regardless of char position of cursor on line 2 #1109

Activity

1. msftrncs commented on Oct 20, 2019

   

   Carl Morris (msftrncs)

   on Oct 20, 2019

   CollaboratorAuthor

   More actions

   When I attempt to fix this, I cause a VI mode test to fail,

   A total of 1 test files matched the specified pattern.
   [xUnit.net 00:00:06.27]     Test.en_US_Windows.DeadKeyShouldBeIgnored [SKIP]
     ! Test.en_US_Windows.DeadKeyShouldBeIgnored [1ms]
     X Test.en_US_Windows.ViMoveToFirstLogicalLineThenJumpToLastLogicalLine [24ms]
     Error Message:
      System.Exception :
   ---- Assert.Equal() Failure
   Expected: 0
   Actual:   3
   

   I am not familiar with VI, Maxime Labelle (@springcomp), I might need some help understanding what the test expected and why changing the way GetBeginningOfLinePos() finds the beginning of the line would have any effect here.
2. Carl Morris (msftrncs)

   changed the title [-]HOME on line 2 sends cursor to line 1 if line 1 is blank regardless of char position of cursor on line 1[/-] [+]HOME on line 2 sends cursor to line 1 if line 1 is blank regardless of char position of cursor on line 2[/+] on Oct 20, 2019
3. springcomp commented on Oct 21, 2019

   

   Maxime Labelle (springcomp)

   on Oct 21, 2019

   Contributor

   More actions

   Carl Morris (@msftrncs) I think I can reproduce your problem, but I would like to make sure about the sequence you use to create an empty first line in VI mode.

   The way I see it, Ctrl+Enter creates an empty line but the _buffer does not contain the corresponding \n character. Thus, there is a mismatch between the _buffer and what is displayed on the screen.

   To make it clearer, typing Ctrl+Enter displays the following prompt:

   PS>
   >>>
   

   But the buffer is still an empty string at this stage (which seems wrong). The reason for this is that there is no binding for the Ctrl+Enter combination, even though the ProcessOneKey() method does not find a handler and tries to insert the key with SelfInsert(). At this stage, the key has a KeyChar property set to \0 instead of \n.

   I think that is the origin of the issue you are seeing.

   Now to answer your question, I agree with you that it has nothing to do with the way the GetBeginningOfLinePos() method has been changed. To reiterate, at this point, the internal test made by LineIsMultiline() returns false because, in effect, the buffer does not contain an expected \n but instead contain a \0.
4. msftrncs commented on Oct 21, 2019

   

   Carl Morris (msftrncs)

   on Oct 21, 2019

   CollaboratorAuthor

   More actions

   Maxime Labelle (@springcomp), when I was debugging the initial find, the buffer did contain \n, and its length was set to 1, and 'current' was set to 1 as well. I will edit the issue though, to be clear, that my keybindings are the standard for Windows environments, CTRL-ENTER is bound to InsertLineAbove, and CTRL-J works for inserting \n directly as well. I'll try to spend some more time to make sure of what I saw in the state of the buffer, and possibly post a PR so the change I was trying to make can be evaluated.
5. msftrncs commented on Oct 22, 2019

   

   Carl Morris (msftrncs)

   on Oct 22, 2019

   CollaboratorAuthor

   More actions

   I had not noticed when I copied the change between files that there was some minor differences, so I created the failure, and the test caught it. Corrected and its no longer failing the test.
6. Carl Morris (msftrncs)

   added 3 commits that reference this issue on Oct 22, 2019

   Correct skipping of checking first character in buffer for new lines.

   ...

   This issue will close once commit 94974b8 is merged into the 'master' branch.

   94974b8

   Correct skipping of checking first character in buffer for new lines.

   ...

   This issue will close once commit 61ec70b is merged into the 'master' branch.

   61ec70b

   Correct skipping of checking first character in buffer for new lines.

   ...

   This issue will close once commit d6197e6 is merged into the 'master' branch.

   d6197e6
7. Dongbo Wang (daxian-dbw)

   closed this as completedin #1108on Oct 29, 2019