dos and no end of file eol?
Marc Weber
Still I get this result:
61 62 63 0A 61 6F 6E 74 65 68 75
^^ no end of file eol. That's ok
^^ this is \n where is the \r ?
Is this a bug?
I want Vim to store file the way it got them - so that VCS control
systems don't show that something changed all lines within a file.
set binary should be enough. But apparently its not ?
Marc Weber
Marc Weber
diff --git a/src/misc2.c b/src/misc2.c
index 724aa43..61023b6 100644
--- a/src/misc2.c
+++ b/src/misc2.c
@@ -3016,7 +3016,7 @@ get_fileformat_force(buf, eap)
else
{
if ((eap != NULL && eap->force_bin != 0)
- ? (eap->force_bin == FORCE_BIN) : buf->b_p_bin)
+ ? (eap->force_bin == FORCE_BIN) : 0)
return EOL_UNIX;
c = *buf->b_p_ff;
}
Then the result should look like it should.
Is anyone interested in this patch - should I try feeding it upstream?
I personally think its important that my beloved editor can write files
the way they are - because very often its best to keep things the way
they are. Changing eol behaviour is causing trouble in distributed dev
environments because diffs show that all lines have changed.
Marc Weber
Bram Moolenaar
Marc Weber wrote:
> I know about binary, endoffile and ff=dos setting.
>
> Still I get this result:
>
> 61 62 63 0A 61 6F 6E 74 65 68 75
> ^^ no end of file eol. That's ok
> ^^ this is \n where is the \r ?
>
> Is this a bug?
What are you doing exactly?
> I want Vim to store file the way it got them - so that VCS control
> systems don't show that something changed all lines within a file.
> set binary should be enough. But apparently its not ?
Actually, you should normally not set binary to write back what was read.
'endoffile' is the exception, and that's because a decent text file must
end with a LF. Vim fixes that for you (it always has). If other tools
omit that LF you need to fix those tools, not Vim.
--
Birthdays are healthy. The more you have them, the longer you live.
/// Bram Moolenaar -- Br...@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 ///
Ben Schmidt
> I know about binary, endoffile and ff=dos setting.
>
> Still I get this result:
>
> 61 62 63 0A 61 6F 6E 74 65 68 75
> ^^ no end of file eol. That's ok
> ^^ this is \n where is the \r ?
>
> Is this a bug?
No. Read the documentation for 'binary'.
In fact, it's important the 'binary' forces 'unix' to ensure files
aren't changed if read and written with binary mode. If reading and
writing files binary with ff=dos, it would be lossy, as Vim discards the
EOL on reading and it wouldn't then know whether to write \r\n or \n for
each EOL in the file.
Ben.
Ben Schmidt
> This patch allows using ff=dos and noendofline and binary:
>
I think the attached old patch of mine is a better solution, allowing
noendofline to be used without binary. It doesn't break the losslessness
of 'binary' like your patch I think does.
I've attached the old version, that applies to Vim 7.2.something, and an
updated one that applies to the current Vim sources (it started clashing
due to the ff fix for empty buffers that just came through a day or so
ago).
It hasn't been very thoroughly tested, particularly with later Vim
versions. But I know it used to work fine for me.
> I personally think its important that my beloved editor can write files
> the way they are - because very often its best to keep things the way
> they are. Changing eol behaviour is causing trouble in distributed dev
> environments because diffs show that all lines have changed.
I agree.
But I'm pretty sure Bram doesn't.
And since this change does to some degree break backward compatibility,
I doubt he'll accept it.
I would be keen to find some kind of solution to this problem, though.
It is crazy that Vim can't write files unchanged with a simple option or
two. Not all of us want the last lines of our files 'fixed'.
Ben.
Ben Schmidt
>> systems don't show that something changed all lines within a file.
>> set binary should be enough. But apparently its not ?
Only if you also read the file using 'binary' (++bin). And then you'll
see ^M at the end of all your lines (and have to add it to any new lines
you add). Far from ideal.
> Actually, you should normally not set binary to write back what was read.
> 'endoffile' is the exception, and that's because a decent text file must
> end with a LF. Vim fixes that for you (it always has). If other tools
> omit that LF you need to fix those tools, not Vim.
This 'decent text file' is the Unix way of viewing things. A lot of
people on DOS/Windows view \r\n not so much as end-of-line, but as
line-break. In this view (and I agree with Bram that it is inferior :-))
it is correct for files not to end with \r\n.
In my opinion, this war is not going to be resolved, certainly not by
trying to push the point with Vim. And it is a difference in opinion we
are dealing with here, not files that are truly and uncontentiously
broken. And even if it were the case that you could 'prove' other tools
were broken, not all tools are open source and readily fixable; some
vendors will simply not fix them.
IMHO, It would be better to change Vim to allow it to easily deal with
files missing a final end-of-line without 'fixing' them, even if this is
not the default option setting. It should at least be easily possible,
which currently it isn't.
Ben.
Marc Weber
Initially everything was caused by forgetting about an autocommand.
Now I fully I agree that the patch I sent only addresses a small part of
the issue and that adding a "forceeol" setting you can unset would be
the real fix.
I'm fine with Bram saying each "proper" file should have eol at each
line - but in many cases (eg when editing PHP files) you don't have to
care about it. PHP will run anything..
However its causing some annoyance to me having to not select "fix last
line" when preparing patches or create an additional patch fixing eol's
only.
Bram: How do you feel about allowing opt-out from the desired default
behavior?
Ben: I'll review and maybe reply our patches for now.
Marc Weber
Christian Brabandt
This is probably just a workaround, but wouldn't something like this
work for you?
fun! WriteFilewithoutEOF()
let a=getline(1,line('$')-1)
call map(a, 'v:val . nr2char(13)')
call extend(a, getline('$', '$'))
call writefile(a,fnamemodify(@%, ':p'), 'b')
unlet a
endfun
au BufWriteCmd filename :call WriteFilewithoutEOF()
regards,
Christian