[vim/vim] End-of-line (EOL) character being displayed despite file does not end with newline (#6119)

[dirdi]

Bug Description
The end-of-line character (lcs-eol, $ by default) is displayed at the end of file (EOF), no matter if the file actually ends with a newline.

To Reproduce

1. Create a file without a newline at EOF echo -n foo > bar
2. Run vim --clean bar
3. Enable list mode :set list

Neither disabling the fixeol setting (:set nofixeol), nor starting Vim in binary mode (vim --clean -b bar) affects this behavior.

Expected behavior
There should be no EOL character (i.e. $) being displayed.

Screenshots

Environment (please complete the following information):

• Vim version:

$ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May 12 2020 02:37:13)
Included patches: 1-716
Modified by team...@tracker.debian.org
Compiled by team...@tracker.debian.org
Huge version with GTK3 GUI.  Features included (+) or not (-):
+acl               -farsi             +mouse_sgr         +tag_binary
+arabic            +file_in_path      -mouse_sysmouse    -tag_old_static
+autocmd           +find_in_path      +mouse_urxvt       -tag_any_white
+autochdir         +float             +mouse_xterm       +tcl
-autoservername    +folding           +multi_byte        +termguicolors
+balloon_eval      -footer            +multi_lang        +terminal
+balloon_eval_term +fork()            -mzscheme          +terminfo
+browse            +gettext           +netbeans_intg     +termresponse
++builtin_terms    -hangul_input      +num64             +textobjects
+byte_offset       +iconv             +packages          +textprop
+channel           +insert_expand     +path_extra        +timers
+cindent           +ipv6              +perl              +title
+clientserver      +job               +persistent_undo   +toolbar
+clipboard         +jumplist          +popupwin          +user_commands
+cmdline_compl     +keymap            +postscript        +vartabs
+cmdline_hist      +lambda            +printer           +vertsplit
+cmdline_info      +langmap           +profile           +virtualedit
+comments          +libcall           -python            +visual
+conceal           +linebreak         +python3           +visualextra
+cryptv            +lispindent        +quickfix          +viminfo
+cscope            +listcmds          +reltime           +vreplace
+cursorbind        +localmap          +rightleft         +wildignore
+cursorshape       +lua               +ruby              +wildmenu
+dialog_con_gui    +menu              +scrollbind        +windows
+diff              +mksession         +signs             +writebackup
+digraphs          +modify_fname      +smartindent       +X11
+dnd               +mouse             +sound             -xfontset
-ebcdic            +mouseshape        +spell             +xim
+emacs_tags        +mouse_dec         +startuptime       +xpm
+eval              +mouse_gpm         +statusline        +xsmp_interact
+ex_extra          -mouse_jsbterm     -sun_workshop      +xterm_clipboard
+extra_search      +mouse_netterm     +syntax            -xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wdate-time  -g -O2 -fdebug-prefix-map=/build/vim-RuXSEA/vim-8.2.0716=. -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linking: gcc   -L. -Wl,-z,relro -Wl,-z,now -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-E  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim   -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo  -lselinux  -lcanberra -lacl -lattr -lgpm -ldl  -L/usr/lib -llua5.2 -Wl,-E  -fstack-protector-strong -L/usr/local/lib  -L/usr/lib/x86_64-linux-gnu/perl/5.30/CORE -lperl -ldl -lm -lpthread -lcrypt  -L/usr/lib/python3.8/config-3.8-x86_64-linux-gnu -lpython3.8 -lcrypt -lpthread -ldl -lutil -lm -lm -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lm -lruby-2.7 -lm

• OS:

$ uname -a
Linux laptop 5.6.0-1-amd64 #1 SMP Debian 5.6.7-1 (2020-04-29) x86_64 GNU/Linux

• Terminal:

$ urxvt -h
rxvt-unicode (urxvt) v9.22 - released: 2016-01-23
...

Additional context
The presence of a trailing newline character can be of importance especially in binary mode.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Gary Johnson]

On 2020-05-22, dirdi wrote:
> Bug Description
> The end-of-line character (lcs-eol, $ by default) is displayed at the end of
> file (EOF), no matter if the file actually ends with a newline.
>
> To Reproduce
>

> 1. Create a file without a newline at EOF echo -n foo > bar
> 2. Run vim --clean bar
> 3. Enable list mode :set list

>
> Neither disabling the fixeol setting (:set nofixeol), nor starting Vim in
> binary mode (vim --clean -b bar) affects this behavior.
>
> Expected behavior
> There should be no EOL character (i.e. $) being displayed.

While I appreciate your point of view, ":help lcs-eol" says:

eol:c Character to show at the end of each line. When
omitted, there is no extra character at the end of
the line.

It says that the eol character appears at the end of the line;
it does not say that the eol character represents the EOL sequence.

In the case of the last line of a file that does not end with an EOL
sequence, the eol character shows where the text of that line,
including white space, ends. By not having the eol character at the
end of the last line, the user would lose that information.

So I think it's a feature and the intended behavior, not a bug.

As for being able to visualize that distinction, as you would like,
I'm afraid I can't think a solution at the moment that uses the
existing capabilities of Vim.

Regards,
Gary

[vim-dev ML]

On 2020-05-22, dirdi wrote:
> Bug Description
> The end-of-line character (lcs-eol, $ by default) is displayed at the end of
> file (EOF), no matter if the file actually ends with a newline.
>
> To Reproduce
>

> 1. Create a file without a newline at EOF echo -n foo > bar

> 2. Run vim --clean bar

> 3. Enable list mode :set list

>
> Neither disabling the fixeol setting (:set nofixeol), nor starting Vim in
> binary mode (vim --clean -b bar) affects this behavior.
>
> Expected behavior
> There should be no EOL character (i.e. $) being displayed.

While I appreciate your point of view, ":help lcs-eol" says:

eol:c Character to show at the end of each line. When
omitted, there is no extra character at the end of
the line.

It says that the eol character appears at the end of the line;
it does not say that the eol character represents the EOL sequence.

In the case of the last line of a file that does not end with an EOL
sequence, the eol character shows where the text of that line,
including white space, ends. By not having the eol character at the
end of the last line, the user would lose that information.

So I think it's a feature and the intended behavior, not a bug.

As for being able to visualize that distinction, as you would like,
I'm afraid I can't think a solution at the moment that uses the
existing capabilities of Vim.

Regards,
Gary

[Tony Mechelynck]

In addition to what Gary said, I'd mention that binary files (files read with e.g. :e ++bin filename.ext) and files where ":setlocal nofixeol" has been set (which is not the default) will be written with an incomplete last line if 'noeol' was set either at read-time (because no EOL was found on the last line) or later (e.g. manually). No matter whether or not 'tist' is set or whether or not 'listchars' includes a visible EOL (the default is eol:$, I use eol:¶) or a blank EOL (set e.g. by eol:\  with a backslash-escaped space, or by omitting the eol: suboption altogether): 'list' and 'listchars' are only for display purposes, and, as Gary said, they are one possible way to notice that there is whitespace at the end of a line.

Best regards,

Tony.

[vim-dev ML]

[Tony Mechelynck]

P.S. One possible way to have Vim display if a given editfiles ends with an EOL or not is by means of a custom 'statusline' (q.v.) — e.g. by having somewhere in the value of the 'statusline' option something like

%{&eol?"":"[noeol]"}

FWIW, my own 'statusline' is

%<%f %h%m%r%=%k[%{(&fenc==''?&enc:&fenc)}%{(&bomb?',BOM':'')}][U+%04B] %-14.(%l,%c%V%) %P

You may want to use only part of it, and remember that in a :set command, any space (or vertical bar or backslash) in the option value must be backslash-escaped.

Best regards,
Tony.

—
You are receiving this because you commented.

[dirdi]

Thank you both for your fast response!

Gary wrote:
It says that the eol character appears at the end of the line;
it does not say that the eol character represents the EOL sequence.

My point is that the line does not end, but the file. Therefore, the behavior does - to my understanding - not comply to :help lcs-eol.

Gary wrote:
In the case of the last line of a file that does not end with an EOL sequence, the eol character shows where the text of that line, including white space, ends. By not having the eol character at the end of the last line, the user would lose that information. So I think it's a feature and the intended behavior, not a bug.

Is not the lcs-trail setting responsible for indicating trailing spaces?

						*lcs-trail*
trail:c	Character to show for trailing spaces.  When omitted,
	trailing spaces are blank.  Overrides the "space"
	setting for trailing spaces.

E.g. setting it to a dot :set listchars:eol:$,trail:. gives:

My (maybe wrong?) intention is that the window content should represent what will be written to disk, when one executes the write command. Hence, the lcs-eol character should be displayed, iff it would be written to disk (i.e. if it is present or if the fixeol setting is set).

Best, dirdi

—
You are receiving this because you commented.

[Gary Johnson]

On 2020-05-22, dirdi wrote:
> Thank you both for your fast response!
>
> Gary wrote:
> It says that the eol character appears at the end of the line;
> it does not say that the eol character represents the EOL sequence.
>
> My point is that the line does not end, but the file. Therefore, the behavior
> does - to my understanding - not comply to :help lcs-eol.

That's an interesting perspective. I would have said that the line
ends at the end of the file, as the programs I've seen that don't
end the last line of the file with an EOL nevertheless intend that
the line end there. That's not how "cat file1 file2" would handle
it, though, for example, if file1 didn't end with an EOL.

> Gary wrote:
> In the case of the last line of a file that does not end with an EOL
> sequence, the eol character shows where the text of that line, including
> white space, ends. By not having the eol character at the end of the last
> line, the user would lose that information. So I think it's a feature and
> the intended behavior, not a bug.
>
> Is not the lcs-trail setting responsible for indicating trailing spaces?

That would work, too.

> *lcs-trail*
> trail:c Character to show for trailing spaces. When omitted,
> trailing spaces are blank. Overrides the "space"
> setting for trailing spaces.
>
> E.g. setting it to a dot :set listchars:eol:$,trail:. gives:

> 2020-05-23-021102_90x52_scrot
>
> My (maybe wrong?) intention is that the window content should represent what
> will be written to disk, when one executes the write command. Hence, the
> lcs-eol character should be displayed, iff it would be written to disk (i.e. if
> it is present or if the fixeol setting is set).

I don't think you're wrong: you have a good point. I think there's
more than one way to present this information. Vim (vi?) chose one
way and you would have chosen another.

I suppose it could be an option [ducks]. There are some issues with
the way that some other listchars are handled (notably lcs-extends),
but no solution yet, so there might be an opportunity to make
lcs-eol work either as you would like or as it does now.

Regards,
Gary

[vim-dev ML]

[dirdi]

I want to add two more thoughts:

Gary wrote:
I think there's more than one way to present this information.

Currently there is no representation of this information at all. Always and independent of a buffer's state displaying the lcs-eol character, does not provide any information to the user. But of course you are right: Not representing it, is in some way a representation.

If one wants to have a character at each EOL, the ~ character - which is already used to represent the EOF - would be a more consistent choice. However, I would prefer to just not display the lcs-eof character.

Tony wrote:
One possible way to have Vim display if a given editfiles ends with an EOL or not is by means of a custom 'statusline'

In my eyes, the right place to indicate how a file ends, would not be the statusline, but the end of the file. Further, Tony's proposed statusline enhancement would not reflect what will be written, but what was read.

On the other hand, changing the current behavior to the behavior I suggested (and to the documented behavior, as I read it), would most probable not break anything, since - to the best of my knowledge - it is currently not possible to query the presence of the lcs-eol character at the EOF and hence no vimscript/plugin/etc. is able to rely on it.

Best, dirdi

—
You are receiving this because you commented.

[Tony Mechelynck]

One thing to keep in mind is that Vim is a product of the Unix world, where every line of a file, including the last one, should have an end-of-line marker. This is why the normal behaviour of Vim is to add an end-of-line at the end of a non-binary file if it is missing, and why it will sometimes display a ^M at the end of every line except the last one if every line except the last one end in a CR+LF pair.

Similarly, the cat (concatenate) program will concatenate the files just as they are, and if one of the files (other than the last one) lacks an EOL on its last line, that line and the first line of the following file will become a single line in the output.

Some programs, and in particular some programs stemming from the DOS/Windows world, regard (erroneously IMHO but I'm not going to enter a flame war about it) the end-of-line sequence not as a line terminator but as a line separator, and if they get a file whose last line is properly terminated they will add an empty line just after that. This is in any case IMHO a lesser evil than failing to separate the last line of one file and the first line of the next file in case of concatenation because the last line of the first file wasn't properly ended.

In any case, it is possible to query Vim for the presence of a proper end-of-line terminator at the end of the present file:

• If the 'endofline' (or 'eol') local option is unset, no EOL character was found on the last line when reading the file. This can be tested with if !&eol ….
• Normally however (i.e. if 'binary' is off and 'fixeol' on for that file, both of which are the default) Vim will disregard the 'eol' setting when writing and add a proper EOL anyway. The opposite condition can be tested with if &bin || !&fixeol ….
• A binary file should be read-in with the ++bin modifier (see :help ++opt) to set 'binary' locally for this file, thus telling Vim that it is a binary file and that it must not add an EOL at the very end if there isn't one there yet.
• If for any reason a text file should not get an additional EOL at the end, the old way of doing it (in versions of Vim compiled before the 'fixeol' option was defined) was to declare that file as binary but that was regarded as "abusing the system". Nowadays it is possible to use :setlocal nofixeol on that file to tell Vim that a possible missing EOL should not be "fixed".
• All of the above behaviours are deterministic and it is quite possible for a plugin to test for them. OTOH, it is not possible for a plugin to test for the presence or absence, at any point, of a specific 'listchars' character: the $ (or other character) representing the end of a line cannot be checked for by if something == "$"; but the fact that Vim won't write an EOL at the end of the file can be tested by if !&eol && (&bin || !&fixeol) …; or the fact that Vim will only write an EOL at the end of the file if it was already there is the condition inside the parenthesis in this last if statement.

Best regards,
Tony.

—
You are receiving this because you commented.

[Bram Moolenaar]

The main purpose of showing $ after the line is to be able to spot any trailing white space. That's an old vi mechanism, it's not going to change.
Since many users find the $ look bad, Vim has added other ways to show trailing spaces.
Having a file not end in a line break is uncommon, Vim considers this a special case and has the 'endofline' option for that. That doesn't show in the text though. Perhaps we can add an item in 'listchars' to show a different character instead of "eol:" when 'endofline' is set.

—
You are receiving this because you commented.

[Tony Mechelynck]

The main purpose of showing $ after the line is to be able to spot any trailing white space. That's an old vi mechanism, it's not going to change.
Since many users find the $ look bad, Vim has added other ways to show trailing spaces.
Having a file not end in a line break is uncommon, Vim considers this a special case and has the 'endofline' option for that. That doesn't show in the text though. Perhaps we can add an item in 'listchars' to show a different character instead of "eol:" when 'endofline' is set.

…or perhaps rather when it is unset, since with 'eol' set the last line ends just the same way as any other line of that file.

—
You are receiving this because you commented.

[dirdi]

Bram wrote:
The main purpose of showing $ after the line is to be able to spot any trailing white space. That's an old vi mechanism, it's not going to change.
Since many users find the $ look bad, Vim has added other ways to show trailing spaces.
Having a file not end in a line break is uncommon, Vim considers this a special case and has the 'endofline' option for that. That doesn't show in the text though. Perhaps we can add an item in 'listchars' to show a different character instead of "eol:" when 'endofline' is set.

I understand that - and please correct me if I am wrong - it is not possible to change the default behavior, because this would "break userspace", so to speak. But it would be possible to add an option to customize the default behavior.

How about this:

• Adding a lcs-eof item (eof:c) to listchars
• that is not set by default and
• that will replace the eol:c character on a file's incomplete last line,
• if and only if
  • a character for eof:c was set (e.g. ~) and
  • the eol option is false and
    • the fixeol option is false, or
    • the binary option is true

This would not conflict with current behavior nor break anything, but enable one to visualize a missing EOL sequence at EOF by configuring the to be implemented lcs-eof item. Would that be acceptable? If so, I would propose to add the "feature-request" label to this thread.

—
You are receiving this because you commented.

[mmikeww]

so basically there is no way in Vim to display the actual newline characters that exist in the file

seems like an awful limitation

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.Message ID: <vim/vim/issues/6119/1307915993@github.com>

[Christian Brabandt]

this is basically the same as the previous comment #6119 (comment)

Perhaps propose a PR then?

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.Message ID: <vim/vim/issues/6119/1307945305@github.com>

[mmikeww]

not exactly the same... that comment is proposing to add an extra character to visualize a missing EOF EOL sequence

i'm proposing no visualization at all for a missing EOF EOL sequence. only visually display what actually exists in the data

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.Message ID: <vim/vim/issues/6119/1307949715@github.com>

[Bram Moolenaar]

> so basically there is no way in Vim to display the actual newline
> characters that exist in the file
>
> seems like an awful limitation

I do not understand what you mean with "actual newline characters".
Those are not printable characters, you can't display them other than
the line break itself, which is of course visible.

Perhaps you can illustrate what you expected to see?

Keep in mind that wording might matter. When you say "newline" I think
of the ASCII NL symbol (also called LF), which is decimal 10 or hex 0A.

Some people call it the "line separator", which goes into the direction
of the last line not being followed by one, but most Unix systems
consider it a "line terminator" and then the last line does have one.
This mainly matters for what happens when concatenating two files.
Also for detecting a possible truncated file (not 100% reliable of
course, but if a text file doesn't end in a newline character it's often
caused by it being unexpectedly truncated).

--
hundred-and-one symptoms of being an internet addict:
32. You don't know what sex three of your closest friends are, because they
have neutral nicknames and you never bothered to ask.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[dirdi]

@mmikeww regarding linefeeds, one is already able to "visually display what actually exists in the data" via eol:c, except for the very last line. If an eof:c item was implemented, like it was suggested by me earlier (#6119 (comment)), this would also enable one to resemble the behavior you are asking for, by just setting eof:c to a blank or any other non-printing character.

—

Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you commented.Message ID: <vim/vim/issues/6119/1310037490@github.com>

[Bram Moolenaar]

> @mmikeww regarding linefeeds, one is already able to "visually display

> what actually exists in the data" via `eol:c`, except for the very

> last line. If an `eof:c` item was implemented, like it was suggested
> by me earlier

> (https://github.com/vim/vim/issues/6119#issuecomment-633044279), this

> would also enable one to resemble the behavior you are asking for, by
> just setting `eof:c` to a blank or any other non-printing character.

That is in the 'listchars' option, which is only used when 'list' is
set. The "eol:$" entry is mainly there for backwards compatibility.
In the old days with some terminals you couldn't tell whether the whole
text was displayed, thus an extra "$" was put after the line to tell the
user it's a complete line. These days I don't expect users to need that
hint.

For 'endoffile' it's the other way around: It normally isn't set and
there is no need to tell the user that there is no CTRL-Z at the end.
If there is a CTRL-Z then very often it will just show up. When using
Unix 'fileformat' then 'endoffile' won't even be set, the CTRL-Z is just
another text character.

Only when 'fileformat' is "dos" and 'endoffile' is set, then there is no
indication of this situation. And the 'noendofline' state is actually
not visible either, the "$" is displayed after the last line anyway.
Again, this is backwards compatible with old days.

Since this is a special situation and it's only one place, I don't think
having the user set 'list' to see it makes sense. Thus adding an
"eof:c" item to 'listchars' isn't very useful.

How about this: We show the unexpected state at the end of the last line
by default, and add items to the 'fillchars' option to do something else
than the default. I would anticipate that most users would be satisfied
with the default, and those few who don't can choose something else.

For the missing EOL, with 'noendofline', perhaps an upside down
exclamation mark could indicate that? Might be hard to spot though.

For the additional CTRL-Z, when 'endoffile' is set, we could just show
the text "CTRL-Z".

Both highlighted with NonText.

'fillchars' items:
noeol:¡
eof:CTRL-Z

Comments?

--
Seen it all, done it all, can't remember most of it.

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\

/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you commented.Message ID: <vim/vim/issues/6119/1310322714@github.com>

[mmikeww]

I have no comment on the EOF character CTRL+Z (from a quick google, ascii 26?). I didn't even know that existed, and don't care how that is handled. Most text files dont have a trailing CTRL+Z from what I've seen.

As far as adding 'noeol' to 'fillchars', here is the problem: Vim does not keep track of the eol status as the file is edited. It only checks it once upon file open. Simply open up a noeol file, use :set eol? and you'll see 'noendofline', edit the file, save it, Vim auto adds the eol, then use :set eol? again and Vim will incorrectly report noeol still, even though it was changed and added. I believe Vim needs to keep track of the original eol state of the file, so that it can determine what to do for the existing 'fixeol/nofixeol' setting, and so that shouldn't be changed either I guess

If the 'eol' listchar cannot be changed for backwards compatibility with Vi, thats fine. My point is that then there is no visual way inside Vim to consistently display \n (LF) chars. And the only way to display \r (CR) is to set ff=unix and then you will see ^M displayed.

It just seems like the easiest and most non intrusive solution is to simply add CR and LF options to listchars and then people can visually see this data, independent of the chosen fileformat

—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.Message ID: <vim/vim/issues/6119/1310537464@github.com>

[Bram Moolenaar]

> I have no comment on the EOF character CTRL+Z (from a quick google,
> ascii 26?). I didn't even know that existed, and don't care how that
> is handled. Most text files dont have a trailing CTRL+Z from what I've
> seen.

It's from old systems, you might call it exotic. That's why showing it
could be useful, it will only show rarely and probably help the user
notice there is something strange going on.

> As far as adding 'noeol' to 'fillchars', here is the problem: Vim does
> not keep track of the eol status as the file is edited. It only checks
> it once upon file open. Simply open up a noeol file, use `:set eol?`
> and you'll see 'noendofline', edit the file, save it, Vim auto adds
> the eol, then use `:set eol?` again and Vim will incorrectly report
> noeol still, even though it was changed and added. I believe Vim needs
> to keep track of the original eol state of the file, so that it can
> determine what to do for the existing 'fixeol/nofixeol' setting, and
> so that shouldn't be changed either I guess

Please use a separate issue for separate things. We are discussing the
visibility of the state in this issue. If you find a repro case where
the value of 'endofline' is wrong, please create a new issue for that.
Otherwise we get things mixed up or forgotten, closing the issue when it
is only partly fixed. I will not act on this remark now, please use
another issue for that.

> If the 'eol' listchar cannot be changed for backwards compatibility
> with Vi, thats fine. My point is that then there is no visual way
> inside Vim to consistently display \n (LF) chars. And the only way to
> display \r (CR) is to set ff=unix and then you will see `^M`
> displayed.

Non printable characters like LF/NL/CR are of course not visible. Only
in some cases we do indicate they exist in some way. But LF/NL is a
line break, not something you see in pixels. I see no reason at all to
make it visible, other then the mentioned list mode character. The CR
showing up as ^M is also from old times, and I don't see a need to
change that.

> It just seems like the easiest and most non intrusive solution is to
> simply add CR and LF options to listchars and then people can visually
> see this data, independent of the chosen fileformat

I do not understand what you mean with "see this data", you don't say
what you actually imagine would show up. And really I don't see any
need for it yet. You'll have to come with more convincing arguments.

Saying "independent of the chosen fileformat" is wrong, we do want to
show the actual state, not some decoration. Users should be aware of
what's going to be written and avoid having options to create confusion.

Keep in mind that users will be concentrating on the text, and the
fileformat is a setting that only matters when reading and writing the
buffer. Not something you need constant reminding of, more distracting
than useful.

--
Despite the cost of living, have you noticed how it remains so popular?

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\