Re: [Parseperl-discuss] [PATCH] preserve newlines

[Chris D. <ch...@ch...>]

On Oct 5, 2006, at 12:40 AM, Adam Kennedy wrote:

>>> That leaves us only with the case of mixed newlines. Personally,   
>>> outside of binary files I am not away of ANY cases in which  
>>> mixed  newlines in a text file is allowed, even in __DATA__  
>>> segments.
>> Well, certainly my goal is to get rid of the mixed newlines!   
>> That's  why I was writing a Perl::Critic policy against that.  :-)
>
> Well, you know it's possible to detect mixed newlines from the raw  
> source right?
>
> Does critic have access to the original file/string?

In theory almost always yes, in practice no.  We accept PPI::Document  
instances, so that's one case where I can't ever get the raw source.   
We also accept STDIN, so I'd have to explicitly save the source.  In  
the most common case, we build a PPI::Document::File.  I *could* of  
course use the filename() to get back to source.

The main reason I can't use raw source is that we have pseudo-pragmas  
that turn Perl::Critic on/off over lexical scopes.  In the bizarre  
case of someone who wanted to have mixed newlines and used a "## no  
critic" to make Perl::Critic ignore it, I couldn't catch that.  But  
maybe it's a lost cause at that point?

Nonetheless, I find this discussion interesting beyond Perl::Critic's  
immediate problem.


>>> In THAT case, perhaps we either localise, or we flatten to the   
>>> first newline in the file.
>>>
>>> I'd be happy to implement that as a first step towards full  
>>> native  mixed newlines, as the functionality seems fairly  
>>> containable.
>>>
>>> It also matches what some of the better editors do... localise   
>>> internally, but remember and save out as the same input type.
>> Not Emacs.  It picks one newline to work on and treats the others   
>> like binary.  So, if you're in \n mode and there is a single \r\n  
>> in  the file, you see a "^M" character at the end of that line.
>
> Well, I mean for the non-mixed case, they deal with it internally.
>
> Emacs et al doing binary items inside a text file is one example of  
> what I mean by handling it wrong.

Hmm...  Maybe I've just been using Emacs so long that its behavior  
feels intuitive to me?  :-)

>>> But I'm honestly not aware of ANYTHING that handles mixed  
>>> newlines  properly. I've done tons of unix/win32/mac cross-over  
>>> work and I've  seen just about every screwed up case there is.
>>>
>>> Even Dreamweaver, which inspired PPI in the first place, doesn't   
>>> handle fucked up broken newlines.
>>>
>>> So we'd have to invent the solution.
>> You must be a step ahead of me or something.  Doesn't "handle"  
>> simply  mean serialization and de-serialization for PPI?  Maybe  
>> I've spent  too much time just in the Perl::Critic case?
>
> There's two levels here.
>
> One is the parser/serializer, the second is the API layer. If we  
> provide add_before, for example, and it's mixed, what do we do?
>
> Say it's mixed unix/mac running on Win32, do we insert with the  
> Win32 newlines and now have 3-platform mix?
>
> We need to define the "correct" behaviour for working with mixed  
> newlines... and I don't know that anyone else has done this yet.

I think the correct behavior on insert is to convert to document  
newline by default, and possibly offer a way to preserve the mixed  
newlines if the generator requests it.  The mechanism for that  
"request" can be a workaround (add_before() then set_newline()), or a  
flag to add_before(), or a sticky_newline flag on the node to be  
inserted.

But as you say...

> I don't think anyone ever really WANTs to make mixed newlines. As I  
> said, I don't know of any legitimate real-world cases of this.

... so probably the generator case is just to adopt the newline of  
the surrounding document.

There are plenty of real world cases of mixed newlines, just none of  
them intentional!

Chris

-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)