You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure what the correct solution is, but I am increasingly feeling like V should handle long lines without issue, probably via soft wrapping.
The current idiom of manually wrapping files included on the disk and relying on all opened files to have been treated so (or simply created with a compliant V) limits V substantially.
Consider that the 34 characters that can be entered as an s" in V is 6 shy of a full line of text output. While some applications can factor this away, there may be a full line of literal text (or more) that you may want to enter, perhaps as a data string.
I understand that this will introduce the seemingly-confusing behaviour of navigating vertically not always being a line at a time, but this would be keeping with vim.
I think it would make coding a bit more fluid, as you don't have to look ahead to see if a word will fit. I know I've miscalculated that limit before. A soft wrap would be welcome here.
edit: sorry for the edit spam. Misdiagnosed an interpreter error momentarily.
The text was updated successfully, but these errors were encountered:
burnsauce
changed the title
V should handle long lines
V / Interpret should handle long lines
Mar 19, 2020
burnsauce
changed the title
V / Interpret should handle long lines
V should wrap long lines
Mar 19, 2020
On Thu, 19 Mar 2020 at 23:05, Poindexter Frink ***@***.***> wrote:
I'm not sure what the correct solution is, but I am increasingly feeling
like V should handle long lines without issue, probably via soft wrapping.
The current idiom of manually wrapping files included on the disk and
relying on all opened files to have been treated so (or simply created with
a compliant V) limits V substantially.
Consider that the 34 characters that can be entered as an s" in V is 6 shy
of a full line of text output. While some applications can factor this
away, there may be a full line of literal text (or more) that you may want
to enter, perhaps as a data string.
I understand that this will introduce the seemingly-confusing behaviour of
navigating vertically not always being a line at a time, but this would be
keeping with vim.
I think it would make coding a bit more fluid, as you don't have to look
ahead to see if a word will fit. I know I've miscalculated that limit
before. A soft wrap would be welcome here.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#245>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34O44JHBIIJEDG75TJILRIKJL5ANCNFSM4LPW4UBQ>
.
I'm not sure what the correct solution is, but I am increasingly feeling like V should handle long lines without issue, probably via soft wrapping.
The current idiom of manually wrapping files included on the disk and relying on all opened files to have been treated so (or simply created with a compliant V) limits V substantially.
Consider that the 34 characters that can be entered as an s" in V is 6 shy of a full line of text output. While some applications can factor this away, there may be a full line of literal text (or more) that you may want to enter, perhaps as a data string.
I understand that this will introduce the seemingly-confusing behaviour of navigating vertically not always being a line at a time, but this would be keeping with vim.
I think it would make coding a bit more fluid, as you don't have to look ahead to see if a word will fit. I know I've miscalculated that limit before. A soft wrap would be welcome here.
edit: sorry for the edit spam. Misdiagnosed an interpreter error momentarily.
The text was updated successfully, but these errors were encountered: