socket repl on emacs eats whitespace

[timsgardner]

arcadia.debug=> (count "a       b")
3
arcadia.debug=> (count (read-string (str "\"" (apply str (repeat 10 " ")) "\"")))
10

[sogaiu]

Used wireshark to observe the associated network traffic for:

(count "a       b")

What showed up as transmitted was:

(count "a b")

Doesn't that suggest the problem is occurring before arcadia is receiving the data?

[sogaiu]

I just tried with a direct telnet connection to port 37220 and got the correct count -- 9 instead of 3.

[sogaiu]

Using edebug on inf-clojure lead to some searching, which turned up: inf-clojure--make-single-line removes consecutive spaces in strings.

Ordinary sending from the repl in inf-clojure seems to involve at least the following chain of calls:

inf-clojure--send-string ->
inf-clojure--sanitize-command ->
inf-clojure--make-single-line

It seems that inf-clojure may be one of the culprits here...

[sogaiu]

@timsgardner If you can still reproduce this and it's still relevant for you, may be you'd be interested in a change I'm testing for inf-clojure.

The change is a modification to inf-clojure--send-string to not send a sanitized string, but rather to just send the original string with a newline appended:

(defun inf-clojure--send-string (proc string)
  "A custom `comint-input-sender` / `comint-send-string`.
It performs the required side effects on every send for PROC and
STRING (for example set the buffer local REPL type).  It should
always be preferred over `comint-send-string`.  It delegates to
`comint-simple-send` so it always appends a newline at the end of
the string for evaluation.  Refer to `comint-simple-send` for
customizations."
  (inf-clojure--set-repl-type proc)
  (let ((sanitized (inf-clojure--sanitize-command string)))
    (inf-clojure--log-string sanitized "----CMD->")
    (comint-send-string proc (concat string "\n"))))

So far it seems ok here.

[sogaiu]

When a region that contains two forms is sent, it appears necessary to send an extra newline to trigger processing of the second form.

Analyzing the socket repl code, it seems that data-available? is returning a falsey value so read doesn't get triggered for the second form. Is this appropriate?

I got the impression that data-available? tries to check whether there is any more data on the network stream to read, but this doesn't seem to work in this type of case. Would it work to check if there is anything in the LineNumberingTextReader *in* instead?