Escape Sequences For Managing Whitespace (Preview)

[John Rose]

+100

One nit:  <\ u 0 0 2 0> is not an escape sequence and so should not be displayed next to <\ 0 4 0>.  The former is processed before tokenization globally while the latter is processed inside strings only. This confusing fact is an additional motivation for <\ s> since most people don’t know what <\ u 0 0 2 0> actually does and some would attempt to use it if not presented with a clean and clear alternative like <\ s>. 

Another nit: <\ LT> (LT = LIneTerminator) is slightly more correct than three rules showing precursors of LT because those precursors have been replaced by LT before escape sequences are processed in string literals. The corresponding library method should say something like what you wrote. 

Substantive suggestion: I think <\ LT> could usefully gobble any unescaped horizontal space that immediately follows the LT. Also unescaped spaces before the <\ LT> could be gobbled. This would allow users freedom in arranging the line continuation escapes in a clear fashion (perhaps aligned visually) and still have complete control over content. The downside of this suggestion is that <\ s> would be required to mark spaces at line continuation edges which are desired as content and not just layout. 

I am thinking of the way multi line C preprocessor definitions are frequently formatted for clarity. The line continuations are visually bracketed away from the content, of the space around the continuations can be classified as non-content. This would be pleasant to offer as an option to text block authors. 

OTOH gobbling spaces around <\ LT> could be felt as a surprise.  OTOOH trailing spaces are illegal in a text block currently, so allowing them as stripped layout control before  <\ LT> is arguably intuitive–why else could it mean?

So I suggest deleting all of <LWS* \ LT LWS*> where LWS is either space or tab, unescaped of course. 

> On Aug 13, 2019, at 5:46 AM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227870
> 
> Comment back to this list, thank you.
> 
> Cheers,
> 
> -- Jim
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190813/08aceec0/attachment.html>