What is the correct cursor position when a } (forward paragraph motion) reaches the last line of the buffer?

Question

Suppose I have two lines in a buffer:

First line
Second line

I position my cursor on the first column of the first line. In normal mode, I press } (i.e. closing curly brace, forward paragraph motion). Where is my cursor supposed to end up? Is there a standard behavior for this, or can it vary by vi implementation?

In Vim, the cursor ends up on the last column of the last line. In Nvi, the cursor ends up on the first column of the last line. Is the proper behavior specified by some kind of standard?

Answer 1

POSIX has this to say on the matter (emphasis added by me):

Return to Previous (Context or Section)

The [[, ]], (, ), {, and } commands are all affected by "section boundaries", but in some historical implementations not all of the commands recognize the same section boundaries. This is a bug, not a feature, and a unique section-boundary algorithm was not described for each command. One special case that is preserved is that the sentence command moves to the end of the last line of the edit buffer while the other commands go to the beginning, in order to preserve the traditional character cut semantics of the sentence command. Historically, vi section boundaries at the beginning and end of the edit buffer were the first non-<blank> on the first and last lines of the edit buffer if one exists; otherwise, the last character of the first and last lines of the edit buffer if one exists. To increase consistency with other section locations, this has been simplified by POSIX.1-2017 to the first character of the first and last lines of the edit buffer, or the first and the last lines of the edit buffer if they are empty.

Sentence boundaries were problematic in the historical vi. They were not only the boundaries as defined for the section and paragraph commands, but they were the first non-<blank> that occurred after those boundaries, as well. Historically, the vi section commands were documented as taking an optional window size as a count preceding the command. This was not implemented in historical versions, so POSIX.1-2017 requires that the count repeat the command, for consistency with other vi commands.

To me this reads as the following: the original vi implementation goes to the end of the last line of the buffer, but a 2017 update to POSIX modifies this. However, this is of little consequence, as both vim and traditional vi (http://ex-vi.sourceforge.net/) use the "traditional" behavior and are unlikely to change in their defaults.

vim has an attempt at a "POSIX mode" when the environment variable VIM_POSIX is set. However, this also predates the POSIX update above by about 12 years, so does not change the behavior either.