niklasf
Support for mate eval notation starting with M
It would be nice if the use of "M" followed by the number of moves to mate, was recognized as an alternative to the currently supported "#" notation. So things as [%eval M1] wouldn't be put into the text field.
Do you have an example for software creating this notation, and maybe a sample PGN we can add as a test case?
The GUI that I'm developing, En Croissant, uses the M notation. Chess.com uses M when displaying engine lines in the analysis board. CuteChess has a different way of annotating evaluations but it also uses M instead of # (example: 7. Bxd1 {+M35/33 4.3s})
Example PGN:
[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "?"]
[White "?"]
[Black "?"]
[Result "0-1"]
1. f3 e5 2. g4 {[%eval -M1]} Qh4# 0-1
Cool project!
I am hesistating ... The comments by chess.com and CuteChess are just text, so everything goes, but [%eval ...] is aimed at being unambiguously machine-readable, so introducing another syntax seems like a mistake.
The [%eval ...] notation is also just text, it doesn't belong to the PGN standard. Since we're talking about a parser, I think it should be as lenient as possible. The output format wouldn't be changed at all.
It would be nice to eventually add support for the cutechess format too (I'm willing to make a PR for that). However, I understand if you think this is outside of the scope of this library.
Ultimately yes, but at least [% ...] are somewhat formalized command sequences from https://www.enpassant.dk/chess/palview/enhancedpgn.htm. That document also briefly mentions but does not further specify an eval command. HIARCS, Lichess, python-chess and ChessBase(?) set the precedent for the command itself.
Sorry, to clarify: I agree that the parser should be lenient, but I wouldn't preemptively add support for syntax variations that do not exist in real-world PGNs.
And that would only happen if programs like En Croissant start using M notation in [%eval ...], which is easily avoidable, even if they use it everywhere else in the user interface.
I agree, I didn't give it much thought at the time, and I'm planning to change it to #. The intention was to keep compatibility with older versions.
However, the cutechess format is more commonly found, including in other tools like fast-chess.
However, the cutechess format is more commonly found, including in other tools like fast-chess.
Mhh ... right. Would accept a patch to add support.