[vim/vim] Does not append new line (Issue #14181)
San
Steps to reproduce
-
Open any file in vim.
-
Write inside it till the text reaches the end of the window
image.png (view on web) -
After that for the next letter, the cursor will go to the next line without indicating that it is the continuation of the same line.
In the above image, now if we enter any one letter the cursor will move and the behaviour is shown below
image.png (view on web)
Expected behaviour
A empty line indicating that it is the same should be displayed by default as follows( the following behaviour is not by default):
<it should show that it the continuation without writing anything, here i had to type * to indicate it.>
image.png (view on web)
Version of Vim
8.2
Environment
WSL2, Ubuntu 22.04.4
zsh 5.8.1 (along with ohmyzsh! framework_
(i have also tried this on bash 5.1.16)
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
You are just talking about the moment when the cursor reaches the next line but the lines does not really wrap yet? I am not sure, I think this is a very minor thing, because as soon as you type another key, you will see that the line is wrapped. Displaying line wrapping line, even so the line does not yet need to be wrapped, seems controversial.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
San
I think this is a very minor thing,
Yes I agree
It is a minor bug
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
San
@chrisbra
Also i found another bug( or maybe its on purpose)
When you only have /t( tab or indentation) without any text on a new line. And you navigate back to previous line and press delete button, the next line does not get deleted but the /t( tab or indentation) does.
Which in some cases is kind of annoying so most IDE's delete the next line when delete is pressed if the next line contains only /t's.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Sorry, I don't get it. Can you please give reproducible steps?
I tried with vim --clean -c 'call setline(1,["", "\t"])' -c 'call cursor(1,1)'
Pressing <Del> on the first line does not delete anything on the second line.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gary Johnson
> @chrisbra
> Also i found another bug( or maybe its on purpose)
> When you only have /t( tab or indentation) without any text on a new line. And
> you navigate back to previous line and press delete button, the next line does
> not get deleted but the /t( tab or indentation) does.
indentation, and you don't add any text on that line, and you then
move to a different line, Vim removes the indentation. This is by
design, to avoid adding superfluous white space to a buffer.
The delete button should delete one character. Why would you expect
it to delete a line, and a different line at that?
> Which in some cases is kind of annoying so most IDE's delete the next line when
> delete is pressed if the next line contains only /t's.
A text file is simply a sequence of characters. Different editors
have different ways of representing that to the user. In Unix, by
convention, a text file is a sequence of lines, where each line is
a sequence of characters terminated by a newline. Vim represents
each line as a line-object (my term) without a newline. The
end-of-line sequence terminating each line is implicit and does not
appear in the Vim buffer, which is simply a sequence of
line-objects.
I'm not sure that was very clear. My point is that Vim's
representation of a text file in a buffer may differ from what
you're used to. It isn't a bug; it's by design. You may have to
think differently about what it means to edit a Vim buffer for some
of Vim's behavior to make sense to you.
Regards,
Gary
vim-dev ML
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
San
It isn't a bug; it's by design
Oh,
ok
I thought maybe it's a bug. Thanks for clarification.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.