Refactoring and documenting nrepl

While I was learning how nrepl works I decided to help future generations and document and re-factor in a systematic way `nrepl-client.el`.  The code was very dificult to follow for two main reasons, not always intuitive or systematic naming conventions and pretty chaotic organization of the file. Client side was spread all over the place.

For readabilty purposes I have made the changes it in 3 steps. 

- First commit is a refactoring pass and consists of mostly variable and function name changes. Some, mostly stylistic, code  improvments are there. The changes should be pretty self explanatory from the diff.   
- Second commit is the re-organization of the file structure.  I have moved the stuff around in chapters, namely:

       - BENCODE
       - CLIENT: PROCESS FILTER
       - CLIENT: INITIALIZATION
       - CLIENT: RESPONSE HANDLING
       - CLIENT: REQUEST HANDLING
       - SERVER
       - UTILITIES
       - CONNECTION BUFFER MANAGEMENT
       - CONNECTION BROWSER

   There are no explicit code changes in this commit.

- Third commit is mostly the documentation changes. I have added a hopefully comprehensive documentation of the client-server communication both in the comment section and in each of sections. 
Fair enough.

-- 
Bozhidar Batsov
Sent with Airmail

On August 7, 2014 at 22:57:17, Vitalie Spinu (notifications@github.com) wrote:

In cider.el:

> @@ -125,16 +125,12 @@ start the server."
>            (let* ((nrepl-project-dir project-dir)
>                   (cmd (format "%s %s" cider-lein-command cider-lein-parameters))
>                   (default-directory (or project-dir default-directory))
> -                 (nrepl-buffer-name (generate-new-buffer-name
> -                                     (nrepl-server-buffer-name)))
> +                 (nbuffname (generate-new-buffer-name (nrepl-server-buffer-name)))
should be at least server-buffer-name.

Let's make it abbreviated server-buf-name. Clear meaning, no confusion with globals, will not interfere with potential refactoring. Good compromise.

—
Reply to this email directly or view it on GitHub.