I noted this in a code comment in #114, but it deserves an issue since it blocks this mode from being fully useful.

Commands that depend on the server (eg pygn-mode-display-board-at-pos) stop working after a certain distance into a long PGN. The docstring for process-send-string says

If STRING is more than 500 characters long, it is sent in several bunches

This is probably the reason for the bug. We may need to use a process sentinel to detect whether the server is in the right state before accepting a response. Or we may need to use a tempfile to hand off request payloads, which would probably entail a regrettable performance penalty.

Per https://github.com/dwcoates/pygn-mode/pull/92/files#diff-96c9fc246f6b0220f76428b02d085cd2R40

uci-mode.el already anticipates being in its own repo.

I have put multiple libraries inside the same repo before, and my memory is that it is simpler dealing with MELPA when they are separated.

From #174 :

After this PR, pygn-mode-follow-minor-mode works correctly, IFF pygn-mode-next-move and pygn-mode-previous-move are used to navigate. But if I move the cursor freely through variations and comments, the "follow" board window eventually stops being updated at all, and the follow mode stops working.

We need to

• find out if this is an old bug, or whether it was introduced by the tree-sitter port
• check whether the recent #177 happened to affect it
• track down the problem and fix

I get this error when i call pygn functions to display a board, any idea why?

pygn-mode--parse-response: Bad response from ‘pygn-mode’ server -- no :version. Attempted restat

Black pawns, that should be black, are faced white, as shown in the screenshot below. (Also tested by loading Emacs with no init and a new fresh installation of pygn-mode.)

PGN example:

[Event "Testing PyGN"]
[Site "localhost"]
[Date "2023.03.20"]
[Round "?"]
[White "Player1"]
[Black "Player2"]
[Result "*"]

1. e4
*

I saw that pygn-mode-pgn-to-board is already returning the missing fill=#000 information for the "black-pawn" in SVG... Inside that function, we find a call to pygn-mode--server-query and, from that one, a call to pygn-mode--server-send. From inside the last one, when process-send-string is called and writes out the Python server response on *pygn-mode-server* buffer, the fill=#000 is already missing...

Strangely, when the same string that is given as STRING argument to process-send-string is input on the server running on the terminal (with the same command python -u /home/username/.emacs.d/elpa/pygn-mode-20220531.1422/pygn_server.py -), it has some extra information before the SVG and does not lack the fill=#000 information for the "black-pawn"...

Any hints for the difference on server response when it is running form terminal compared to Emacs' one?

Why just fill=#000 for black pawn is missing among that cumbersome SVG information when server on Emacs is in play? (Remember, by running the PyGN server on terminal, it DOES return the information correctly.)

After #60, the GitHub banner description should be changed to match:

• An Emacs major-mode for chess PGN files, powered by Python

I'm getting this error [ ] Bad. The pygn-mode-script-directory ('c:/Users/Alejandro/AppData/Roaming/.emacs.d/elpa/pygn-mode-20211021.2325/') is bad or does not contain working server script (pygn_server.py). after running pygn-mode-run-diagnostic. Any idea why?

pygn_server.py is in the directory. I'm using Windows 10. I don't know what the problem is.

the complete diagnostic is as follows:

[x] Good. We can execute the pygn-mode-python-executable at 'python'

[x] Good. The pygn-mode-python-executable at 'python' is a Python 3 interpreter.

[x] Good. The pygn-mode-python-executable at 'python' is better than or equal to Python version 3.7.

[x] Good. The pygn-mode-python-executable at 'python' can import the Python chess library.

[ ] Bad. The pygn-mode-script-directory ('c:/Users/Alejandro/AppData/Roaming/.emacs.d/elpa/pygn-mode-20211021.2325/') is bad or does not contain working server script (pygn_server.py).

The IDEA comments say

and there exists

https://github.com/meain/evil-textobj-tree-sitter

so let's try it.

• Python 3.7+
• Chess lib version 1.6.1
• pygn-mode-run-diagnostic = good

Output:
pygn-mode--python-chess-guard: The Python interpreter at ‘pygn-mode-python-path’ must have the Python chess library available

The pygn-mode works in my setup but does not provide any syntax highlighting when I edit PGN files. This is not a regression, I have been using pygn-mode for three years, and the syntax highlighting has never worked for me.

Emacs version:

• GNU Emacs 28.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8)

Package versions (MELPA):

• pygn-mode-20230606.42
• tree-sitter-20220212.1632
• tree-sitter-langs-20230705.525
• uci-mode-20210626.1956
• nav-flash-20220726.1117
• ivy-20230410.1815

The configuration provided by ~/.emacs.d/init.el

;; PyGN mode
(use-package pygn-mode
  :ensure t
  :bind (:map pygn-mode-map
              ("C-c C-n" . pygn-mode-next-game)
              ("C-c C-p" . pygn-mode-previous-game)
              ("M-f" . pygn-mode-next-move-follow-board)
              ("M-b" . pygn-mode-previous-move-follow-board)
              ("C-c SPC". pygn-mode-display-gui-board-at-pos)
              ("C-h $" . pygn-mode-describe-annotation-at-pos))
  :hook (pygn-mode . visual-line-mode)
  :custom
  ;; pygn-mode-pythonpath is not automatically updated after pygn-mode
  ;; package update.  To workaround this issue I set the variable
  ;; here.
  (pygn-mode-pythonpath
   (concat (getenv "HOME")
           "/.emacs.d/elpa/pygn-mode-"
           (mapconcat 'number-to-string
                      (pkg-info-package-version 'pygn-mode) ".")
           "/lib/python/site-packages/")))

Output of the pygn-mode-run-diagnostic command:

[x] Good. We can execute the pygn-mode-python-executable at 'python'

[x] Good. The pygn-mode-python-executable at 'python' is a Python 3 interpreter.

[x] Good. The pygn-mode-python-executable at 'python' is better than or equal to Python version 3.7.

[x] Good. The pygn-mode-python-executable at 'python' can import the Python chess library.

[x] Good. The pygn-mode-script-directory ('/home/gszasz/.emacs.d/elpa/pygn-mode-20230606.42/') is found and the server script is callable.

[x] Good.  The `uci-mode' library is available.

[x] Good.  The `nav-flash' library is available.

[x] Good.  The `ivy' library is available.

------------------------------------

All pygn-mode required diagnostics completed successfully.

Example

(goto-char (point-max))

M-x pygn-mode-echo-fen-at-pos
; Wrong type argument: integer-or-marker-p, nil

Tree-sitter brought a deeper understanding of the structure of the file, and is naturally more strict. But this does not match the previous behavior. In addition, if an exception is to be thrown, it must be meaningful. This needs testing, and thinking through.

Intuitively, I think some of the defuns could reman strict in their understanding of placement in the buffer, but the commands made more lenient.

The next/previous game commands and next/previous move commands should travel in the reverse direction when given a negative prefix arg.