Actually, the goal was to convince you to enable replaying the games as they were recorded. It later deviated into trying to convince you to parse correctly the PGN in places where the absence of white space is easily corrected. Speaking of reading the entire PGN specification, below the part that I have in mind. Particularly the word <may>, which you seem to interpret as <must>.

< 7: Tokens

PGN character data is organized as tokens. A token is a contiguous sequence of characters that represents a basic semantic unit. Tokens <<<<may>>>> be separated from adjacent tokens by white space characters. (White space characters include space, newline, and tab characters.) Some tokens are self delimiting and do not require white space characters.>

Also, note that <The import format is rather flexible and is used to describe data that may have been prepared <<<<by hand,>>>> much like a source file for a high level programming language. A program that can read PGN data should be able to handle the somewhat lax import format. >.

Missing space where it can be inferred from the context is certainly something that can easily happen in manually prepared PGN.

As mentioned earlier, in the sequence <Rd7+Kxd7>, the first move is self-delimiting. Just as the first move in the sequeces <Rd7+!Kxd7>or <Rd7+?Kxd7> would be. In all cases, the first move ends just before K, no?

And yes, the entire sequence <Rd7+Kxd7> matches a single "symbol token". Which just goes to show my long-standing assertion that the "standard" is sloppy, since SAN move cannot extend past a [+?!]+, while "symbol token" can.

Incidentally, one boat that you've missed is that recognizing moves ending in [+?!]+ is trivial, with negligible impact on performance, even in Java. It would probably take less effort and energy to fix the code to handle such missing spaces in the move text, than to argue against it.

<PGN import format does not require move number indications. It does not prohibit superfluous move number indications anywhere in the movetext <<<<as long as the move numbers are correct.>>>>>

Therefore, in this portion of the PGN for A Carpinter vs P S Spiller, 1979:

<23.g3 h5 25.Kh2 h4 26.Rg1 Kf7>

the number 25 is illegal. However, <CVD> does not indicate anything abnormal there and renumbers the moves, displaying them thus:

23.g3 h5
24.Kh2 h4
25.Rg1 Kf7

It would be more appropriate to display them perhaps:

23. g3 h5
24. missing missing
25. Kh2 h4
26. Rg1 Kf7

or maybe leave the entries for move 24 empty, or perhaps highlight the number 24 and all the subsequent ones in red, to indicate renumbering.

Any of the above would be much more informative than the current presentation of the game, expecting people to compare the number of moves in CVD and in the PGN in order to figure out what got messed up in the PGN.

Your unending supply of good ideas,

MAJ

1) Being optional MNI could be missing for the most of the game. I feel that it is unreasonable to expect a correct MNI on move #37 if all the previous MNI are missing. How could a human do that?

2) MNI can appear on half-moves and we have to analyze those as well.

3) If we enforce MNI accuracy it will become difficult for people to manually merge back variations sent by somebody else (e.g. who analyzed a specific position). Consider something similar to “Paste Moves Sequence” command in CVD.

4) In our practical example (Benzol’s game) it turned out that he had correct MNI (#23) on wrong moves so no smart handling would’ve resolved it anyway.

Again, I like your suggestion and I assume that standalone parsers should’ve had that feature long ago. I also assume that the end result should be some kind of a warning. It is funny that many parsers don’t implement much more important warnings (if any) so I don’t hold my breath in anticipation.

The thing with CVD is that I’ve always paid close attention to its size. That’s the only way I could minimize the startup time and enhance users’ experience. I’m getting positive feedback from users with dial-up connections and sooner or later mobile devices will become popular and join the same group (roughly, their connection being slightly faster but their overall performance - slightly worse). I believe that in Web-based environment a half-a-second delay does make a difference. In addition, the advanced error handling that I’ve implemented in CVD already puts the parser way ahead of many standalone ones and I’m not eager to extend the gap.

<I always copy it to the clipboard just before submitting it. >

Assuming, of course, that the new computer would be a Mac.

Safari is extremely robust there, and (under OS X) it allows you to do one better over the (rather volatile) clipboard: select the entire text and drag-and-drop it on the desktop. Bingo, instant persistent backup of the message. I do this usually when composing complex messages that require reworking (and end up with two or three intermediate versions of the message).

<Joe>, I didn’t take <WannaBe’s> advice literally as it clearly is a product of his wits. For me, buying a new PC is a too drastic solution to a small problem like <kutztown46’s> chessgames.com chessforum. Especially if it was caused by an inadvertent side effect while typing (quite likely with a laptop keyboard). Nobody wants to see exactly the same problem reappear $2000 later.

http://en.wikipedia.org/wiki/Smiley

<joke> Actually, the <joke level="2">best</joke> advice came from <WannaBe ... Buy a new computer>. </joke>

Need a meta-joke tag somewhere here, too, to indicate joking about joke tags.

Instead of just placing the FEN onto the clipboard, I get a popup window within the main window which contains the FEN string that should have been copied silently onto the clipboard.

Another request is support for <Chess960>, so we can see all of the games from Mainz on this website.

Support for <Chess960> is a very good idea but, last time I checked, I couldn’t find a PGN extension that serves the purpose. Without a clear and final standard the portability part will be questionable. Do you have any further information?

Hi

Oh, I see. That FEN popup window is a feature, *not* a bug. :-)

<<notyetagm>, That FEN popup window is a feature> Yeah, with a good sense of humor you can call it “a feature” but, in reality, it is a quick workaround (or a patch). I myself hate to see an error message in that situation. Recently I learnt more about Copy/Paste in FF and there is some hope that I would make it work. As before, the problem comes from the FF’s security architecture that considers Copy/Paste harmful and disables it by default. The good news is that the user can make some configuration changes to enable it and then we’ll be very close to have Copy/Paste features of CVD work properly in FF.

Do you think all of that is worth the effort?>

Please, visit each of the following pages (they all use CVD). http://chesstuff.blogspot.com
http://www.geocities.com/pilafovi/C... http://www.geocities.com/pilafovi/C... http://www.geocities.com/pilafovi/C...

If nothing different happens re-do the tests but try the following: (*) Scroll down and up the page which might help "activate" the applet; (*) Click inside the applet, e.g. anywhere on the chessboard; (*) Click on the "Refresh" button (second from the left).

I tried your tests, the board behaves the same way in all four of the links.

The board loads up and displays the start position, but the move list is blank.

I tried scrolling up and down the screen and clicking the refresh button on the board application and on my browser and that did nothing either.

When I click into the board nothing happens either.

I can pick up a piece and drag it around the board, but when I 'place' it, the display glitches out and goes blank entirely or goes mostly blank with a bit of the board left.

If you have any more tests in mind just let me know.