On 09-Jul-15, Olaf Dabrunz wrote:
> On 22-Jun-15, Pavel Samarkin wrote:
> > Hi,
> >
> > Issue: Vim adds EOL to the end of each text file
> >
> > Although my change might seem controversial, it looks like a lot of people
> > (including myself) really want it, especially when using Vim on non-Unix
> > systems (e.g. Windows).
> > You can notice it here:
> >
> > http://vim.wikia.com/wiki/Preserve_missing_end-of-line_at_end_of_text_files
> > http://www.vim.org/scripts/script.php?script_id=4550
> > and in several questions on stackoverflow:
> > http://stackoverflow.com/questions/1050640
> > http://stackoverflow.com/questions/4133501
> > http://stackoverflow.com/questions/14171254
> > http://askubuntu.com/questions/13317
> >
> > The solution suggested in Vim FAQ (5.4)
> > http://vimdoc.sourceforge.net/htmldoc/vimfaq.html
> > includes some side-effects like inability to use 'expandtab', 'textwidth'
> > and
> > some other options (incl. Unicode BOM).
> >
> > My proposed change introduces the new option called 'respecteol' (that's the
> > best name I could come up with) which affects the EOL at the end of file the
> > same way as the 'binary' option does, while not changing any other aspects.
>
> 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
>
>
> 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.
... and 'eol' is turned off.
> 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').
So the final EOL is either stored in 'eol' (when 'addeol' is in effect),
or it is stored in the buffer, as a final empty line, and 'eol' is
cleared ('noeol'), when 'noaddeol' is in effect.
> Of course, if 'addeol' is off ('noaddeol') when a file is read, then
> 'eol' is always cleared.
... as the final EOL (if any) is stored in the buffer, not in 'eol',
when 'noaddeol' is in effect.
> 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?
--
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.
