Re: about and

2016-04-05 5:44 GMT+03:00 samxyzabc <wushuangrong@gmail.com>:
> following is from :help NL-used-for-Nul
>
> Technical detail:
> <Nul> characters in the file are stored as <NL> in memory. In the display they are shown as "^@". The translation is done when reading and writing files. To match a <Nul> with a search pattern you can just enter CTRL-@ or "CTRL-V 000". This is probably just what you expect. Internally the character is replaced with a <NL> in the search pattern. What is unusual is that typing CTRL-V CTRL-J also inserts a <NL>, thus also searches for a <Nul> in the file. {Vi cannot handle <Nul> characters in the file at all}
>
> my problem is:
> as mentioned above, <NUL> is stored as <NL> in memory, but isn't <NL> the character to split line? unix platform is assumed. Wouldn't this cause a newline displayed on the screen if there is <null> character in the file? another problem is that what is the difference between file and buffer? Why vim is doing this?

<NL> is the new line character in a file, but internal representation
may be any. And internally one line is a one C string, *no* newline
characters here *at all*. But C strings end with NUL, so line cannot
contain it and thus NUL is replaced with NL which cannot be present in
the line because it was already taken into account when splitting read
file into lines. It is more interesting that with e ++ff=mac <NL>
characters are turned into <CR>: when splitting <NL> characters does
not cause line to end so may be present inside the line, but in
internal representation <NL> was already taken by <NUL>. So there is
no other way around then use <CR> (cannot be present in the line
because it ends it) for <NL>.

Note: when reading file Vim *first* splits it into lines and *then*
transforms line into internal representation. So there is no problems
with line splitting. After file was read into buffer it is transformed
into on-screen view: which also replaces control characters with
things like ^@. So there is no problems when displaying lines. You
will not see that ^@ in the `getline()` output, it is on-screen
representation (though you may use `strtrans()` to get it, you will
not be able to distinguish literal `^@` and NUL after `strtrans()`).

// Note that most modern languages do not have this kind of problem
VimL has: they simply store string as {length, string} where string
does not need any terminators because its length is determined by
length. But, of course, you will have to rewrite all libc functions
that work with strings because all of them expect
nul_terminated_string. Zsh has chosen another approach: C strings, but
metafied (some characters including NUL are xor'ed with META, META
itself has dedicated byte). But unlike Vim zsh does not expose this
internal detail to user: every time string leaves zsh (is echo'ed,
written into a file, saved in the environment, etc) it is unmetafied.
// Apart from library functions and the fact that string literal in C
code is a C-style string C-style strings have only problems and little
advantages: they are slightly more memory-efficient, but it is O(N)
indexing (O(1) for {size, string}), O(N) length (O(1) obviously),
O(N+M) strcat (O(M)) (M stands for second string), increased
multiplier when writing them somewhere (due to things like
NL-used-for-NUL or metafying you need to spend time converting this
thing back and determining where it ends, with {size, string} this is
simple write(fd, string, size)).

>
> Thanks everyone!
>
> --
> --
> You received this message from the "vim_use" 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_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.