Right now we can set the filename when we call the parser manually, but we can't override the line and column information. Usually, it isn't required, because the parser mostly parses the contents of the file as a whole. This is not the case when using REPL interactively from the text editor via some integration. In the editor, when sending the expression to the REPL it would be parsed and evaluated separately from the file, and the error message is written in the relation to the expression without the rest of the file prior to it.

Right now it is not possible to send this additional information to the base Fennel REPL, and it wasn't an issue because most of the time the ,reload is used to actually load the code to the REPL, and ,reload passes the file as a whole. We can still send expressions to the REPL but the line and filename information gets lost because there's no way to send this data alongside the expression, so I suspect this is why the REPL never had the need for setting this information per expression.

I'm writing a custom REPL that accepts specially formatted messages for the purpose of implementing a custom protocol over the default REPL. I would like to pass in the information about where the expression came from, mainly the line number, column number, and filename so the error pinpointing can be reported and parsed back by the client, highlighting errors in the edited file.

Right now we can easily implement passing line and column information to the fennel.parser functions via the options table, and use them as initial offsets, but I suspect it may break error pinpointing or some other functionality that uses the output of the ast-source function. So maybe instead they should be stored as offsets that only applied when the REPL prints messages about the source code. This needs further thinking.

However, for the purposes of the custom protocol, there's also a need to somehow tell the parser that the REPL is using about the custom filename, and the line and column offsets from the readChunk function. Right now it's impossible to pass this information to the underlying parser.