Changes between Initial Version and Version 13 of Ticket #46


Ignore:
Timestamp:
01/11/14 16:42:46 (11 years ago)
Author:
ossi
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #46

    • Property Status changed from new to closed
    • Property Votes for changeset changed from to commited-master
    • Property Severity changed from to merged
    • Property Reporter changed from slavazanko to div0
    • Property Branch state changed from to no branch
    • Property Milestone changed from to 4.7.0-pre4
    • Property Owner set to angel_il
    • Property Resolution changed from to fixed

  • Ticket #46 – Description

    initial v13  
    77||Release:||4.6.1||Operating System:||GNU/Hurd|| 
    88 
    9 Discussion: 
     9Original submission: 
    1010{{{ 
    11 Wed 21 Jun 2006 05:36:17 PM UTC, comment #7: 
     11When editing a file, mcedit does not put a newline character at the  
     12end of the file as required by POSIX and other standards. 
    1213 
    13 Any patches forthcoming? 
    14         Leonard den Ottolander <leonardjo> 
    15 Project Member 
    16 Sat 29 Apr 2006 09:18:23 AM UTC, comment #6: 
     14I quote IEEE 1003.2-2001: 
    1715 
    18 I think such a dialog box should rather read: 
     16A file that contains characters organized into one or more lines.  
     17The lines do not contain NUL characters and none can exceed  
     18{LINE_MAX} bytes in length, including the <newline>. 
    1919 
    20 The file you are editing does not end with a newline as required by  
    21 many programs. Do you want to add one? 
    22 [Yes] [No] 
     20I think a text editor should default to the OS's text file format  
     21which does require a newline at the end of the last line (many  
     22utilities including sudo actually require that and gcc warns if the  
     23last line does not end with a newline). Of course, if one is  
     24editing a DOS file (CRLF line separators), no newline is to be  
     25enforced. 
     26}}} 
    2327 
    24 and - since mcedit is suitable for editing binaries - it would not  
    25 hurt if "No" was the by default selected button. 
     28Comment 1 by Oswald Buddenhagen <ossi> at Thu 27 Apr 2006 04:05:23 PM UTC: 
     29{{{ 
     30nothing in the quoted paragraph suggests that a newline has to be  
     31present. there are two philosophies regarding newlines: newlines as  
     32line terminators (requires newline) and newlines as line breaks  
     33(separators - no newline required). personally, i also lean towards  
     34line termination. however, so far mcedit follows a "don't do  
     35anything not explicitly requested" philosophy (autoindent being the  
     36exception) - not necessarily by design, but because it is simpler  
     37to implement. but i'd argue that the "explicit" mode is a good  
     38default choice anyway. 
    2639 
    27 But a method to warn the user via some red highlighting would also  
    28 suffice I think... the main reason is that I often read about  
    29 complaints from users who edited their files with mcedit - and then  
    30 the program (again, sudo and gcc are the most prominent examples)  
    31 fails to work with the file (sudo, and there is no indication in  
    32 the error messages about what is wrong) or outputs a warning the 
    33 clueless user does not understand (in case of gcc - although I  
    34 think gcc's warning is clear enough). 
    35         Rudolf Polzer <div0> 
    36 Sat 29 Apr 2006 08:25:21 AM UTC, comment #5: 
     40as far as dos newlines are concerned, i repeatedly found it  
     41annoying that mcedit can't deal with them (displaying ^M does not  
     42count ;). i think it should handle them transparently - and  
     43possibly offer a conversion option. 
     44}}} 
    3745 
    38 ... except that this patch does not actually handle the Cancel case  
    39 ... 
    40 but other than that i'm fine with it. 
    41         Oswald Buddenhagen <ossi> 
    42 Sat 29 Apr 2006 08:12:29 AM UTC, comment #4: 
    43  
    44 mcedit is currently suitable for editing binary files, too. I  
    45 wouldn't like to give up this feature. So we had to do something  
    46 like: 
    47  
    48 if (the current file looks like a text file) { 
    49 if (edit->size > 0 && get_byte(edit->size) != '\n') { 
    50 if (inputbox("This file does not end with a newline. " 
    51 "Shall we add it?", YES|NO|CANCEL) == YES) { 
    52 edit_insert_byte(edit->size, '\n'); 
    53 } 
    54 } 
    55 } 
    56         Roland Illig <rillig> 
    57 Project Member 
    58 Thu 27 Apr 2006 09:50:09 PM UTC, comment #3: 
    59  
    60 Damn, why does it say GNU/Hurd there? I'm quite sure that I didn't  
    61 select that on purpose (I'm using GNU/Linux and FreeBSD), maybe I  
    62 just clicked next to the right choice... please change that or  
    63 ignore it, thanks. 
    64         Rudolf Polzer <div0> 
    65 Thu 27 Apr 2006 09:47:52 PM UTC, comment #2: 
    66  
     46Comment 2 by Rudolf Polzer <div0> at Thu 27 Apr 2006 09:47:52 PM UTC: 
     47{{{ 
    6748Sorry, I forgot to quote the definition of "line" too... 
    6849 
    … …  
    8364older UNIX systems), it would be good to at least highlight the  
    8465missing newline even by default.  
    85         Rudolf Polzer <div0> 
    86 Thu 27 Apr 2006 04:05:23 PM UTC, comment #1: 
     66}}} 
    8767 
    88 nothing in the quoted paragraph suggests that a newline has to be  
    89 present. there are two philosophies regarding newlines: newlines as  
    90 line terminators (requires newline) and newlines as line breaks  
    91 (separators - no newline required). personally, i also lean towards  
    92 line termination. however, so far mcedit follows a "don't do  
    93 anything not explicitly requested" philosophy (autoindent being the  
    94 exception) - not necessarily by design, but because it is simpler  
    95 to implement. but i'd argue that the "explicit" mode is a good  
    96 default choice anyway. 
     68Comment 3 by Rudolf Polzer <div0> at Thu 27 Apr 2006 09:50:09 PM UTC: 
     69{{{ 
     70Damn, why does it say GNU/Hurd there? I'm quite sure that I didn't  
     71select that on purpose (I'm using GNU/Linux and FreeBSD), maybe I  
     72just clicked next to the right choice... please change that or  
     73ignore it, thanks. 
     74}}} 
    9775 
    98 as far as dos newlines are concerned, i repeatedly found it  
    99 annoying that mcedit can't deal with them (displaying ^M does not  
    100 count ;). i think it should handle them transparently - and  
    101 possibly offer a conversion option. 
    102         Oswald Buddenhagen <ossi> 
    103 Thu 27 Apr 2006 07:27:54 AM UTC, original submission: 
     76Comment 4 by Roland Illig <rillig> at Sat 29 Apr 2006 08:12:29 AM UTC: 
     77{{{ 
     78mcedit is currently suitable for editing binary files, too. I  
     79wouldn't like to give up this feature. So we had to do something  
     80like: 
    10481 
    105 When editing a file, mcedit does not put a newline character at the  
    106 end of the file as required by POSIX and other standards. 
     82if (the current file looks like a text file) { 
     83    if (edit->size > 0 && get_byte(edit->size) != '\n') { 
     84        if (inputbox("This file does not end with a newline. " 
     85                     "Shall we add it?", YES | NO | CANCEL) == YES) { 
     86            edit_insert_byte(edit->size, '\n'); 
     87        } 
     88    } 
     89} 
    10790 
    108 I quote IEEE 1003.2-2001: 
     91}}} 
    10992 
    110 A file that contains characters organized into one or more lines.  
    111 The lines do not contain NUL characters and none can exceed  
    112 {LINE_MAX} bytes in length, including the <newline>. 
     93Comment 5 by Oswald Buddenhagen <ossi> at Sat 29 Apr 2006 08:25:21 AM UTC: 
     94{{{ 
     95... except that this patch does not actually handle the Cancel case  
     96... 
     97but other than that i'm fine with it. 
     98}}} 
    11399 
    114 I think a text editor should default to the OS's text file format  
    115 which does require a newline at the end of the last line (many  
    116 utilities including sudo actually require that and gcc warns if the  
    117 last line does not end with a newline). Of course, if one is  
    118 editing a DOS file (CRLF line separators), no newline is to be  
    119 enforced. 
     100Comment 6 by Rudolf Polzer <div0> at Sat 29 Apr 2006 09:18:23 AM UTC: 
     101{{{ 
     102I think such a dialog box should rather read: 
     103 
     104The file you are editing does not end with a newline as required by  
     105many programs. Do you want to add one? 
     106[Yes] [No] 
     107 
     108and - since mcedit is suitable for editing binaries - it would not  
     109hurt if "No" was the by default selected button. 
     110 
     111But a method to warn the user via some red highlighting would also  
     112suffice I think... the main reason is that I often read about  
     113complaints from users who edited their files with mcedit - and then  
     114the program (again, sudo and gcc are the most prominent examples)  
     115fails to work with the file (sudo, and there is no indication in  
     116the error messages about what is wrong) or outputs a warning the 
     117clueless user does not understand (in case of gcc - although I  
     118think gcc's warning is clear enough). 
    120119}}} 
     120 
     121Comment 7 by Leonard den Ottolander <leonardjo> at Wed 21 Jun 2006 05:36:17 PM UTC: 
     122{{{ 
     123Any patches forthcoming? 
     124}}}