lua-send-buffer, unfinished string error

[deb75]

Hello,

I have this small script :

if not string.find(package.path, "demonstrator") then
    package.path = [[D:\xxx\Documents\code\demonstrator\lib\?.lua;D:\xxx\Documents\code\demonstrator\lib\?\init.lua;]]
        .. package.path
    print(package.path)
end

local map = require("map")
local inspect = require("inspect").inspect

print(inspect(map))

which is correctly run with C-c C-l :

LuaJIT 2.1.0-beta3 -- Copyright (C) 2005-2017 Mike Pall. http://luajit.org/
JIT: ON SSE2 SSE3 SSE4.1 BMI2 fold cse dce fwd dse narrow loop abc sink fuse
> > 
D:\xxx\Documents\code\demonstrator\lib\?.lua;D:\xxx\Documents\code\demonstrator\lib\?\init.lua;D:\xxx\Documents\utils\luarocks-3.7.0\systree\share\lua\5.1\?.lua;D:\xxx\Documents\utils\luarocks-3.7.0\systree\share\lua\5.1\?\init.lua
{
  config = {
    default = {
      tile = {
        path = "c:/Users/yyyy/tiles"
      }
    }
  },
  engine = {
    load = <function 1>
  }
}
> 

Then, if I add a few lines to the script :

if not string.find(package.path, "demonstrator") then
    package.path = [[D:\xxx\Documents\code\demonstrator\lib\?.lua;D:\xxx\Documents\code\demonstrator\lib\?\init.lua;]]
        .. package.path
    print(package.path)
end

local map = require("map")
local inspect = require("inspect").inspect

print(inspect(map))

local a = function(t)
    return 2
end

local g = a({ q = 4, f = 5 })

print(g)

I get the error :

> > >> stdin:1: unfinished string near ''d:/xxx/Documents/code/demonstrat'
> 

Do you understand wht is happening ?

I run luajit on windows 10 mingw64

Regards

[geoffhill]

I also can hit similar errors trying to use lua-mode with lua-5.4.2_Win64_bin on Windows with large-ish (1000LoC) files. The same command (C-c C-l) works fine on OpenBSD with the same source file buffer.

Some debugging shows the subprocess stdin string is generated properly. My guess from reading the Emacs manual is that we are hitting this condition:

Some operating systems have limited space for buffered input in a pty. On these systems, Emacs sends an EOF periodically amidst the other characters, to force them through. For most programs, these EOFs do no harm.

It would appear to be doing some harm in this case. It's not clear to me how this would be fixed without rethinking the whole approach, e.g. using file input instead of interactive.