Pre-note: we are mostly not actually talking about digraphs here, but
the way Vim displays control characters/'special keys'. Digraphs are a
way of entering these and other characters.
This is a bit confusing. It actually does make sense, but it seems
you've come across a bug or two as well, which isn't helping.
> I've just discovered that the digraph for linefeed is always ^@, which
> is the same as the null digraph. This is confusing. Why not use ^J for
> linefeed, which would be more logical?
You are mistaken. ^@ represents null in both cases. Due to Vim's
architecture, though, if you try to insert a linefeed into a buffer, you
actually insert a null. When you see ^@, it will be saved as a null in
the file.
> Secondly, I've also discovered that the digraph for carriage-return is
> ^M when the fileformat is either dos or unix, but it changes to ^J
> when the fileformat is mac. Why is it like this?
This is because of how the character will be saved in a file. With Unix
(or DOS) line endings, the line endings are line feeds, and any carriage
returns are written as such, so they are displayed as ^M. With Mac line
endings, the line endings are carriage returns and what are internally
represented in Vim as carriage returns are written as line feeds, so
they are displayed as ^J. However, both these are entered by entering a
carriage return in Vim.
With Unix (or DOS) line endings, it is impossible to have ^J as part of
a line. With Mac line endings, it is impossible to have ^M as part of a
line.
So...the summary of this is: the way to enter a null in Vim is to enter
a line feed, and it is displayed as ^@; the way to enter a ^M or ^J is
either to break a line, or enter a carriage return, depending on which
one you want and what your fileformat setting is.
In double checking this, I came across a bug: When ff is mac and you then
do :set ff=unix the screen is redrawn and all the ^J change to ^M as
expected. However, when ff is unix and you issue :set ff=mac the screen
is not redrawn immediately; only if you scroll or do CTRL-L or such will
they change.
> Thirdly, I can't seem to get a linefeed displayed as a digraph
> character in vim at all. I've tried writing out a file in the unix
> fileformat, so that all newlines are LFs and there are no CRs, then I
> set the fileformat to mac (so that LFs should not be displayed as line
> breaks), I set fileformats to nothing, and I edit the file. I expect
> the LFs to be displayed as ^@ (meaning LFs), and I expect the :ascii
> command to return LF, but instead the LFs are displayed as ^J
> and :ascii returns CRs. Did vim convert the LFs to CRs when I edited
> the file?
Yes.
It looks to me like you've found a bug in the :ascii command, though.
What is displayed as ^J is actually a linefeed in the file, and will be
written as such. However :ascii is incorrectly reporting it as a
carriage return (which is how it is internally represented).
(All this confusion arises because of this: In Vim, due to conventions
in the C programming language, end-of-line is represented internally by
null, and null may not appear elsewhere in a line. To get around this,
Vim uses linefeed to represent null. This is all fine for Unix line
endings, and DOS endings, by extension. But for Mac line endings it is
more complicated, and in addition, since the line ending is a carriage
return, internally a carriage return represents a linefeed to allow the
whole range of characters to be represented. Although it may seem
strange to introduce this additional translation rather than just use
carriage return instead of line feed internally to represent null, it
has its benefits, for plugins can more consistently insert nulls, and
there is greater symmetry between file formats, allowing for easier
recovery if you accidentally save with the wrong format.)
Bram: I attach a patch that fixes the two bugs I mentioned, but I am not
sure either is solved the best way: (1) I'm not sure whether it would be
more appropriate to modify transchar rather than buffering its output
and then changing c to cover the ff=mac case. I suspect not, but you
know the codebase infinitely better than I! It's pretty simple anyway.
As usual, please send me a mail to confirm you've noticed so I know it's
on the to do list or whatever. (2) I can't easily see why any redrawing
happens at all, so perhaps there is a place which causes the redraw for
some cases where catching the other cases would be better than making
setting the option redraw in all cases.
Cheers,
Ben.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
diff -r 11ae7ca1e672 src/ex_cmds.c
--- a/src/ex_cmds.c Sat Dec 06 10:45:15 2008 +1100
+++ b/src/ex_cmds.c Sun Dec 28 19:13:21 2008 +1100
@@ -49,6 +49,7 @@
exarg_T *eap;
{
int c;
+ char_u *transc;
char buf1[20];
char buf2[20];
char_u buf3[7];
@@ -92,9 +93,12 @@
else
#endif
buf2[0] = NUL;
+ transc = transchar(c);
+ if (c == CAR && get_fileformat(curbuf) == EOL_MAC)
+ c = NL; /* we use CR in place of NL in this case */
vim_snprintf((char *)IObuff, IOSIZE,
_("<%s>%s%s %d, Hex %02x, Octal %03o"),
- transchar(c), buf1, buf2, c, c, c);
+ transc, buf1, buf2, c, c, c);
#ifdef FEAT_MBYTE
if (enc_utf8)
c = cc[ci++];
diff -r 11ae7ca1e672 src/option.c
--- a/src/option.c Sat Dec 06 10:45:15 2008 +1100
+++ b/src/option.c Sun Dec 28 19:13:21 2008 +1100
@@ -1056,7 +1056,7 @@
{(char_u *)0L, (char_u *)0L}
#endif
},
- {"fileformat", "ff", P_STRING|P_ALLOCED|P_VI_DEF|P_RSTAT|P_NO_MKRC,
+ {"fileformat", "ff", P_STRING|P_ALLOCED|P_VI_DEF|P_RSTAT|P_RBUF|P_NO_MKRC,
(char_u *)&p_ff, PV_FF,
{(char_u *)DFLT_FF, (char_u *)0L}},
{"fileformats", "ffs", P_STRING|P_VIM|P_COMMA|P_NODUP,
