savannah: mcedit forgets POSIX newline at end of file

[div0]

Original: ​http://savannah.gnu.org/bugs/?16452

Submitted by:	Rudolf Polzer <div0>	Submitted on:	Thu 27 Apr 2006 07:27:54 AM UTC
Category:	None	Severity:	3 - Normal
Status:	None	Privacy:	Public
Assigned to:	None	Open/Closed:	Open
Release:	4.6.1	Operating System:	GNU/Hurd

Original submission:

When editing a file, mcedit does not put a newline character at the 
end of the file as required by POSIX and other standards.

I quote IEEE 1003.2-2001:

A file that contains characters organized into one or more lines. 
The lines do not contain NUL characters and none can exceed 
{LINE_MAX} bytes in length, including the <newline>.

I think a text editor should default to the OS's text file format 
which does require a newline at the end of the last line (many 
utilities including sudo actually require that and gcc warns if the 
last line does not end with a newline). Of course, if one is 
editing a DOS file (CRLF line separators), no newline is to be 
enforced.

Comment 1 by Oswald Buddenhagen <ossi> at Thu 27 Apr 2006 04:05:23 PM UTC:

nothing in the quoted paragraph suggests that a newline has to be 
present. there are two philosophies regarding newlines: newlines as 
line terminators (requires newline) and newlines as line breaks 
(separators - no newline required). personally, i also lean towards 
line termination. however, so far mcedit follows a "don't do 
anything not explicitly requested" philosophy (autoindent being the 
exception) - not necessarily by design, but because it is simpler 
to implement. but i'd argue that the "explicit" mode is a good 
default choice anyway.

as far as dos newlines are concerned, i repeatedly found it 
annoying that mcedit can't deal with them (displaying ^M does not 
count ;). i think it should handle them transparently - and 
possibly offer a conversion option.

Comment 2 by Rudolf Polzer <div0> at Thu 27 Apr 2006 09:47:52 PM UTC:

Sorry, I forgot to quote the definition of "line" too...

3.205 Line
A sequence of zero or more non-<newline>s plus a terminating <newline>.

http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap03.html

However, another solution would be using syntax highlighting to 
highlight a missing newline at the end of the file if it is known 
that a file format requires it (just like Makefiles are handled 
when a line starts with eight spaces).

And since many tools get quite irritated if the newline is missing 
(another prominent example is "cat" - people often wonder why the 
shell prompt gets in the same line as the file data - and then of 
course some old versions of vi and less that I've seen on some 
older UNIX systems), it would be good to at least highlight the 
missing newline even by default. 

Comment 3 by Rudolf Polzer <div0> at Thu 27 Apr 2006 09:50:09 PM UTC:

Damn, why does it say GNU/Hurd there? I'm quite sure that I didn't 
select that on purpose (I'm using GNU/Linux and FreeBSD), maybe I 
just clicked next to the right choice... please change that or 
ignore it, thanks.

Comment 4 by Roland Illig <rillig> at Sat 29 Apr 2006 08:12:29 AM UTC:

mcedit is currently suitable for editing binary files, too. I 
wouldn't like to give up this feature. So we had to do something 
like:

if (the current file looks like a text file) {
    if (edit->size > 0 && get_byte(edit->size) != '\n') {
        if (inputbox("This file does not end with a newline. "
                     "Shall we add it?", YES | NO | CANCEL) == YES) {
            edit_insert_byte(edit->size, '\n');
        }
    }
}

Comment 5 by Oswald Buddenhagen <ossi> at Sat 29 Apr 2006 08:25:21 AM UTC:

... except that this patch does not actually handle the Cancel case 
...
but other than that i'm fine with it.

Comment 6 by Rudolf Polzer <div0> at Sat 29 Apr 2006 09:18:23 AM UTC:

I think such a dialog box should rather read:

The file you are editing does not end with a newline as required by 
many programs. Do you want to add one?
[Yes] [No]

and - since mcedit is suitable for editing binaries - it would not 
hurt if "No" was the by default selected button.

But a method to warn the user via some red highlighting would also 
suffice I think... the main reason is that I often read about 
complaints from users who edited their files with mcedit - and then 
the program (again, sudo and gcc are the most prominent examples) 
fails to work with the file (sudo, and there is no indication in 
the error messages about what is wrong) or outputs a warning the
clueless user does not understand (in case of gcc - although I 
think gcc's warning is clear enough).

Comment 7 by Leonard den Ottolander <leonardjo> at Wed 21 Jun 2006 05:36:17 PM UTC:

Any patches forthcoming?

[angel_il]

I think it can be optional

[angel_il]

branch: 46_POSIX_new_line (parent: master)
changeset: 251854c7a760a926757ce6ea2ea3afd88a69e044

[angel_il]

e55f4bec98735a3465e5e193f88781a3bd07f170 (forced update)

[angel_il]

f67134867618940f19a0bbd2fd44510fcbfde401 (forced update)

[angel_il]

02a25e0167845d6a9f75c5103c618f07d5824a19 (forced update)

[angel_il]

Fixed: 467d833ac34e629acefb5ee49c06acb2a7eacc37