Add ASCII parser

[dormerod]

I'd like to work on a parser for ASCII formatted (human readable) Go diagrams.

I propose we call this format ASCII, rather than Sensei's format, forum format or something else, because its use predates Sensei's Library (e.g. in newsgroups, email, old Go websites, command line Go programs etc). There doesn't seem to be any reference to ASCII in the existing codebase for Glift, so I don't envision any conflicts at the moment.

The 'standard' ASCII format looks like this and can be generated by various SGF editors:

     A B C D E F G H J K L M N O P Q R S T
   +---------------------------------------+
19 | . . . . . . . . . . . . . . . . . . . | 19
18 | . . . . . . . . . . . . . . . . . . . | 18
17 | . . . 2 . . . . . . . . . . 4 . . . . | 17
16 | . . . + . . . . . + . . . . . + 1 . . | 16
15 | . . . . . . . . . . . . . . . 7 . . . | 15
14 | . . . . . . . . . . . . . . . . . . . | 14
13 | . . . . . . . . . . . . . . . . . . . | 13
12 | . . . . . . . . . . . . . . . . . . . | 12
11 | . . . . . . . . . . . . . . . . . . . | 11
10 | . . . + . . . . . + . . . . . + . . . | 10
 9 | . . . . . . . . . . . . . . . . . . . | 9 
 8 | . . . . . . . . . . . . . . . . . . . | 8 
 7 | . . . . . . . . . . . . . . . . . . . | 7 
 6 | . . . . . . . . . . . . . . . . . . . | 6 
 5 | . . . . . . . . . . . . . . . . 6 . . | 5 
 4 | . . 5 + . . . . . + . . . . . + . . . | 4 
 3 | . . . . . . . . . . . . . . . 3 . . . | 3 
 2 | . . . . . . . . . . . . . . . . . . . | 2 
 1 | . . . . . . . . . . . . . . . . . . . | 1 
   +---------------------------------------+
     A B C D E F G H J K L M N O P Q R S T

The Sensei's Library/Forum extension looks like this:

$$Bm1 [caption]
$$ +---------------------------------------+
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . 2 . . . . . . . . . . 4 . . . . |
$$ | . . . , . . . . . , . . . . . , 1 . . |
$$ | . . . . . . . . . . . . . . . 7 . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . , . . . . . , . . . . . , . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . 6 . . |
$$ | . . 5 , . . . . . . . . . . . , . . . |
$$ | . . . . . . . . . . . . . . . 3 . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ +---------------------------------------+

These formats are similar enough that the parser should be able to handle both of them. The dollar signs have limited meaning in our case, so we can easily strip them out.

One of the existing issues with these diagrams on sites like Sensei's Library is that move numbers in diagrams can only go up to 10 (represented by 0) after which you need to continue with a new diagram, where the previous moves have been flattened.

My experience is that this can be very frustrating and limiting, so I suggest that our implementation should support move numbers up to three digits in length (or maybe of arbitrary length) with (optional) zero padding to maintain a nice, human readable alignment.

[artasparks]

so I suggest that our implementation should support move numbers up to three digits in length (or maybe of arbitrary length) with (optional) zero padding to maintain a nice, human readable alignment.

I don't think our goal should be to reinvent an ASCII format, just to parse what currently exists.

There is one big trickiness with ascii formats: How big is the board? it's a little tricky, especially if the user has chosen to crop the board in some non-trivial way.

[dormerod]

Ok, how about I start simple for now and see whether it's easy to add the nice to haves later?

The move number limitation 'bug' has been annoying me for about a decade now, so it would bring me great personal satisfaction if there was an opportunity to squish it without much extra work.

[artasparks]

The move number limitation 'bug' has been annoying me for about a decade now, so it would bring me great personal satisfaction if there was an opportunity to squish it without much extra work.

It's a separation of concerns. This task is for parsing. If we wish to invent a new ASCII format, that should be a separate bug (although I don't recommend it).

[dormerod]

Fair enough, thanks.
On 14/02/2015 5:27 PM, "Josh Hoak" notifications@github.com wrote:

The move number limitation 'bug' has been annoying me for about a decade
now, so it would bring me great personal satisfaction if there was an
opportunity to squish it without much extra work.

It's a separation of concerns. This task is for parsing. If we wish to
invent a new ASCII format, that should be a separate bug (although I don't
recommend it).

—
Reply to this email directly or view it on GitHub
#114 (comment).

[artasparks]

Realistically, unless there's a compelling reason to have this, I won't be working on this. If a compelling reason does come up, feel free to reopen.