If I run guile in a terminal (GNOME Terminal 3.28.2), select the first block from the file, and use my middle mouse button to paste it into the guile prompt, I get the expected answer: $4 = 139 scheme@(guile-user)> If I do the same with the second block, I get no response, and it appears that Guile has hung in some way. I have to type C-c to get a new prompt: ^C^CWhile reading expression: User interrupt scheme@(guile-user)> The max line length for the first block is 4087. For the second it's 4113. Could there be a 4K buffer or limit involved somewhere? I tried to simulate this in code as follows: (define (make-sexp n) (define (accum s n) (if (zero? n) s (accum (string-append s " (\"AAAAAAAAAAAAAAA\" \"aaa\")") (- n 1)))) (string-append "(" (accum "" n) ")")) (length (with-input-from-string (make-sexp 5000) read)) But that is fine, so it appears there isn't a problem in the reader itself. Any ideas? This is a problem for me in practice when evaluating Guile code (via Geiser) from an Org file, with data coming from large Org tables (as initially reported here: https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00177.html). Many thanks, Neil Neil Jerram writes: > "Jose A. Ortega Ruiz" writes: > >> I cannot see what it is, but there's something in that expression that >> makes scheme readers hang. I just pasted it in a vanilla guile repl >> (started with run-scheme, no geiser involved), and it never gets >> evaluated. The same thing happens with a MIT scheme vanilla repl. And >> the same thing happens if i try to evaluate it in a guile repl in a >> terminal, so it's not even emacs fault. Maybe there's some non-ascii >> char in there? In fact, the scheme readers hang somewhere in the middle >> of the let, because i can remove characters from the end and they never >> discover that the expression is unbalanced.... > > Thanks Jao; the plot thickens... > > The line length is quite close to 4K; I wonder if that could be > relevant? > > Anyway, I will also check for odd characters... > > Neil