On 08-Jul-15, Pavel Samarkin wrote:
> Hi,
>
> > If you use git, then in “git help attributes” the example mentioning
> > *.vcproj
> > files might be useful for you. Possibly the end-of-line normalization
> > offered
> > by git includes the case where just the last line needs normalization.
>
> Roland - thank you, I did not know about that feature of git, it might be
> useful for my *.csproj situation, but generally I don't want my files to be
> normalized in any way, I want them to be left intact.
>
> > 1. 'norespecteol' (default) means that an EOL is always added unless
> > 'eol' + 'bin' are set, i.e. Vim's existing behavior.
> > 2. Opening an existing file when 'respecteol' is set honors the current
> > state of the EOL on the last line, and should set 'eol' accordingly.
> > 3. If a user wishes a new, unsaved buffer to not have an EOL on the last
> > line, she can set 'respecteol' and 'noeol'.
>
> James - I think in #1 you meant 'noeol' + 'bin' - if yes, then 1-3 is exactly
> what my patch adds.
>
> > I believe the final EOL in a file should be made visible and
> > editable.
>
> Olaf - James is right, according to the POSIX standard, EOL means EOL, not
> 'newline', regardless of how it's treated by some other text editors.
According to the POSIX standard you cited,
3.206 Line
A sequence of zero or more non- <newline> characters plus a
terminating <newline> character.
a line is terminated by a <newline> character.
It does not mention EOL.
In the other mail I tried to hint at the different meanings and
interpretations. They can be confusing. As a small overview:
Unicode says LF / NL and EOL are the same, at codepoint 0x000A:
http://unicode.org/charts/PDF/U0000.pdf.
This extends the meaning of 0x0A from the source character set
ISO 646 / ECMA-6 and ISO 6429 / ECMA-48, which defines this as LF.
Unicode invented a different code point for "line separator" LS at
0x2028 to "represent this semantic unambiguously":
http://unicode.org/charts/PDF/U2000.pdf
Note that there is also NEL (next line) at 0x0085, invented by
ISO 6429 / ECMA-48.
See the "Unicode Newline Guidelines" at
http://unicode.org/standard/reports/tr13/tr13-5.html for a
discussion and recommendations around newline / EOL etc. treatment.
The original definitions of characters like NL and CR are
operational (e.g. move to the next line, or to the beginning of the
line, see ISO 6429 / ECMA-48).
But EOL is the concept of a line terminator, which needs to be
represented by one or more codes.
A standard like POSIX simply adopted NL as the code for a line
terminator.
Others have adopted NL, CR+NL or CR as line terminators or as line
separators.
Have a look at https://en.wikipedia.org/wiki/Newline to find more
representations for next line, line terminator or line separator,
both historic and current.
The reason why in vim we can conveniently use the concept of EOL is that
vim does such a good job of converting the different representations
into a single internal representation (lines terminated by NUL '\0').
But the problem here is not the different representations for EOL, but
that there is software that uses the concept of a line separator rather
than a line terminator like EOL, yet represents this with a similar
selection of codes (NL, CR+NL, maybe even CR).
> Besides, I don't want to break the existing Vim functionality, I just want to
> expand the horizons of its usage beyond the Unix world it has been originally
> created for.
Fully agreed.
I do not think that a suggestion like '(no)addeol' breaks vim.
It is quite comparable to your approach, but IMHO even simpler, and more
visible and editable to the user:
When saving a file, do not append EOL (or in this case "line
separator") representation characters to the last line.
To make the file end on a line separator, an empty line must be at
the end of the buffer.
This behavior can be turned on or off with a single option.
Only when switching this option on or off, an empty last line is
converted to 'eol' or back, and if the last line is not empty,
'noeol' is set or no empty line is appended to the buffer when
converting backwards.
And when a file is read, then the setting of the option determines
if the state of the last EOL will show up in 'eol' or in the buffer.
That's it.
The main advantage of my approach, as I see it, is that when a file uses
the line separator concept instead of the EOL concept, it does not hide
the empty line at the end in an option.
Instead, it makes that line visible and malleable in a very natural way
inside the buffer.
This makes the user see what she gets, and she can manipulate it easily.
I may not have convinced you, so maybe it helps if we could compare the two
approaches side-by-side.
But I will be very busy with other things in the next days, so I am not
sure if I will get around to write an implementation for review and
comparison.
--
Olaf Dabrunz (oda <at> fctrace.org)
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
