Olaf Dabrunz wrote:
> I think this is one way to do this.
>
> 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
No, this looks like there is an extra empty line. Note that EOL means
End Of Line, not line separator. On many systems a missing EOL
indicates an incomplete file, it was truncated. Unfortunately some
programs, especially on MS-Windows, have the habit of forgetting the EOL
and try to change the rules by saying it's supposed to be this way.
> 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.
>
> 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.
>
>
> If you want to prevent that for a certain filetype the file contains an
> EOL at the end, you can either highlight this as an error to the user:
>
> :call matchadd('ErrorMsg', '^\%$')
>
> or automatically remove that line with a BufWritePre autocommand:
>
> :augroup CProj
> :au!
> :autocmd BufWritePre *.cproj if &addeol == 0 | /^\%$/d | endif
> :augroup END
>
> (assuming the option controlling this mode is called 'addeol')
>
> or both.
>
> Of course, the option could also be set depending on filetype:
>
> :augroup MyFiletype
> :autocmd FileType cproj set noaddeol
> :augroup END
>
> When the 'addeol' option is turned off ('noaddeol'), if the 'eol' option
> is set, an empty line is appended to the buffer. When 'addeol' is
> turned on, and the buffer ends in an empty line, that empty line is
> removed and the 'eol' option is set, or otherwise 'eol' is cleared
> ('noeol').
>
> Of course, if 'addeol' is off ('noaddeol') when a file is read, then
> 'eol' is always cleared.
>
> Writing a file when 'binary' is set must ignore 'eol' when 'addeol' is
> off -- the EOL is already in the buffer, no need to add another one
> ('eol' should be off for 'noaddeol', it is bogus anyway).
>
>
> It think it should be fairly easy to implement an option like 'addeol'
> in vim.
>
> What do you think?
The 'addeol' option indicates adding an EOL, also when there already was
one, that's confusing. We could call it 'fixeol', which would normally
be on. For some file formats for some systems it could be switched off,
so that the missing EOL is not added.
--
Some of the well known MS-Windows errors:
EMULTI Multitasking attempted, system confused
EKEYBOARD Keyboard locked, try getting out of this one!
EXPLAIN Unexplained error, please tell us what happened
EFUTURE Reserved for our future mistakes
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
