On 08-Jul-15, James McCoy wrote:
> On Thu, Jul 09, 2015 at 03:09:58AM +0200, Olaf Dabrunz wrote:
> > However, I believe the final EOL in a file should be made visible and
> > editable.
> >
> > Consider this:
> >
> > file A file B
> >
> > ,-------------------. ,-------------------.
> > |... | |... |
> > |Last line | |Last line |
> > |~ | | | <-- lookie here
> > |~ | |~ |
> > `-------------------´ `-------------------´
> >
> > ends on 'Last line' ends on an empty line
> >
> >
> > If vim had a mode where it *never* adds a newline on the last line when
> > writing a file, then vim would write file A without a final EOL, and
> > file B with a final EOL, and no other differences.
>
> This is just propagating the misconception that the EOL is a new line,
> instead of an indicator of the end of the current line. Why should I
> add a blank line, that isn't really a line, to get an EOL on the just
> previous non-blank line?
Yes, EOL means end of line, and not new line, in the sense of the words.
And in POSIX, a line must be terminated by a newline character.
But in its literal sense, EOL is only a concept, not a character, or
something that appears in a file. EOL is implemented with characters
like NL, CR+NL and CR (':he EOL'). So technically, a text file could
end on something else but characters that represent an EOL.
And if we like it or not, the strict sense of seeing EOL as a line
terminator is only one view. See e.g.
https://en.wikipedia.org/wiki/Newline:
In computing, a newline, also known as a line ending, end of line
(EOL), or line break, is a special character or sequence of
characters signifying the end of a line of text.
[...]
Two ways to view newlines, both of which have valid internal logic,
are that newlines terminate lines or that they separate lines. If a
newline is considered a separator, there will be no newline after
the last line of a file. Some programs have problems processing the
last line of a file if it is not newline-terminated. On the other
hand, programs that expect newline to be used as a separator will
interpret a final newline as starting a new (empty) line.
Some applications can handle either view, some can only handle one view.
Rather than discussing who is "right" or "wrong" on this, or why it has
developed in this way, I would prefer that vim supports editing text
that can readily be consumed by any application, regardless to which
view it adheres.
Unless this would mean to add support for rare use cases, or if the cost
of maintenance would be too high, or if the potential to confuse users
would be significant.
For what it's worth, in this case I am mostly concerned about adding
more code that must be maintained.
The use case does not seem to be that rare (MS Visual Studio project
files were given as an example), and the potential for confusion should
be minimal: users do not need to touch 'addeol', similarly to 'binary'.
If they are likely to touch it, displaying the state of 'addeol' in the
statusline should help.
It has also been mentioned how annoying it can be when vim always adds
an EOL to the last line, while other people on a project use other
editors where this becomes visible as an additional line.
Also, source code control and GNU diff see this as a change.
In such projects, vim can be seen as an annoying citizen.
In the gist of the robustness principle, vim should
not just [...] survive other misbehaving [software], but also [...]
cooperate to limit the amount of disruption such [software] can
cause to the shared [...] facility. [-- Adapted from RFC 1122.]
Or in other words, make it possible to create the file formats others
expect, even if that means accomodating some other view.
On the other hand, if a plugin could *reliably* take care of this, then
changes to vim are not needed.
Using 'binary' when saving a file is the only option that preserves the
last line ending. But it does not revert encoding conversions and
fileformat conversions done when reading the file.
So some other solution is needed.
> > And when vim is in that mode, when reading a file, vim would make it
> > show up like file A when the file has no newline at the end, and like
> > file B when it has a newline at the end.
> >
> > This way, it becomes clearly visible in the editor what the file
> > contains, and the user can change it too.
>
> While making it easier to accomodate the myriad applications that don't
> understand EOL is useful, misrepresenting the contents of the file
> doesn't seem like the right way to do it.
When seen as a separator, EOL (in its character form as NL, CR+NL or CR)
separates two lines. In this view, the representation is correct:
,-------------------. ,-------------------.
|... | |... |
|Last line | |Last line |
|~ | | |
|~ | |~ |
`-------------------´ `-------------------´
Last line Last line<NL> <- character sequence
> The exact behavior you're describing is one of the things that annoys me
> about Emacs, because I still haven't internalized the fact that it
> allows me to place the cursor past the last line in the buffer. This
> leads to the fun behavior of me deleting the last “line”, saving the
> buffer, and the last “line” reappearing because it properly re-adds the
> EOL.
Agreed. Ugly.
But the solution is simple: if vim has 'addeol', then do not turn it
off. Nothing will change for you.
If you end up working on a project where everyone else uses Emacs
(shudder) or even some Windows editor (horrors), and people plus the VCS
keep complaining about your editor adding newlines at the end,
:set noaddeol will make the complaints go away.
And you still cannot move the cursor beyond the end of the file (if you
see EOLs as separators that is, like the others in the project).
> I haven't followed the discussion about 'respecteol' closely, but this
> is the behavior I'd expect based on the name:
>
> 1. 'norespecteol' (default) means that an EOL is always added unless
> 'eol' + 'bin' are set, i.e. Vim's existing behavior.
... unless 'eol' is cleared and 'bin' is set, ...
> 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.
Independent of other option settings, 'eol' is set when reading a
file, unless the file does not end in an EOL, in which case 'eol'
is cleared.
> 3. If a user wishes a new, unsaved buffer to not have an EOL on the last
> line, she can set 'respecteol' and 'noeol'.
Yes.
As I said, this is one way to solve this.
My suggestion is not so different, only that the state of 'eol' can
alternatively be shown as the existence or non-existence of an
(additional) empty line at the end of the buffer.
And only when it would be shown as an extra empty line at the end of the
buffer, that is when ':set noaddeol' is in effect, but when that line is
actually missing, only then the final EOL will not be in the file.
This is similar to what other editors show, when they interpret EOL as a
line separator.
So the 'noaddeol' option essentially changes the interpretation of EOL
to that of a line separator.
In a work environment where other editors show EOLs in that way, it
makes sense to be able to edit them in the same way.
This mode could be indicated by showing a [noaddeol] item (or
similar) in the statusline.
In the 'respecteol' + '[no]eol' implementation, a statusline item
'[noeol]' could be shown when ':set respecteol noeol' is active, to
indicate that no EOL at the end of the file will be written.
But the buffer itself will not show any indication of this.
My suggestion only makes this more visible and directly and intuitively
editable in the text.
This is better for quality control: show directly what will be in the
file, in the way how others will see it.
Cheers,
--
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.
