Re: [Nano-devel] DOS/Mac text conversion

[David Lawrence Ramsey]

--- Chris Allegretta <address@hidden> wrote:
>On Fri, Oct 01, 2004 at 11:34:30AM -0400, Bill Soudan wrote:
>> On Fri, 2004-10-01 at 11:02, Dwayne Rightler wrote:
>> > I don't know what shell you use, but for bash you could always do 
>> > something like:
>> > 
>> > alias nano-dos='nano -D'
>> > 
>> > That would solve your problem as long as you could remember to use 
>> > the nano-dos command instead of nano when editing win32 text files.
>> 
>> heh, that's irritating, and yes I will forget.  Why not just fix the 
>> editor so that it does what I know I expect as a user: save the text 
>> file in the same format it was read in from?  As a reference, vi and 
>> emacs do this.
>
>Yes.  However, last time I used it (which is now a LONG time ago), Pico 
>did not do this.  It saves all files as Unix format by default, and I 
>don't believe there's any option to change how it is saved.  Has any 
>used Pico recently who would know if this is still the case?

The current version, Pico 4.8, still does this.

>Since we're already doing this better, it just becomes a question of
>whether we save in the file's format by default (and hence not need
>--noconvert).  I'm fine with that, what do you think DLR?  How do we 
>handle multiple file buffers?  Yuck, I cant think about this right now 
>:)

Saving in the file's format by default sounds good to me.  It appears to 
just be a matter of saving the values of the DOS_FILE and MAC_FILE flags 
when updating an open_files entry, resetting them just before reading in 
another file, and setting them based on the detected file format.  
Here's a patch that should do that, against nano 1.2.4:

http://pooka_regent.tripod.com/patches/nano/nanoformat124-patch.txt

Does it do what's expected?

As for not needing --noconvert, I think it's still needed.  nano isn't 
designed as a binary editor, of course, but there are times where it's 
handy to be able to open binary files in it without mangling line 
endings that may not actually be line endings.