+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.las...@oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227870
> 
> Comment back to this list, thank you.
> 
> Cheers,
> 
> -- Jim
> 
> 
> 

Reply via email to