Skip to content

lua-send-buffer, unfinished string error #193

Open

Description

@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

Activity

  1. geoffhill commented on Oct 28, 2021

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions