David A. Wheeler wrote: > > ... Handling EOF withing a preceding EOL is ugly in > > general, and it's not the something you see in practice in source or > > structured data. >
Alan Manuel Gloria replied: > I worry about this, because I've experienced at least one nasty text > editor (not designed for programming, admittedly, but still) that > stripped off *all* trailing EOL's before an EOF (I also can't remember > the editor's name off-hand, but I think it was made for Windows). So > I think we should treat EOF=EOL in the parser spec. A fair concern. My concern is that we need to make the spec "not too hard to implement". I just got basic indentation processing working in sweet.g; once things stabilize, let's see how hard that is to do. We could say that portable files MUST have newline before EOF (if they're non-empty), and that implementations SHOULD handle the case, if it's too hard to handle. But if it's not too hard to implement, then being flexible (and requiring EOF-without-newline) sounds best. --- David A. Wheeler ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
