Lua table index is nil

[archpaladin1]

Just did a fresh git pull and rebuild of wordgrinder today. I can run the program and save a new workbook without issue. However, when trying to open the same workbook again, a la

wordgrinder name.wg

I get the following:

Lua error: [string "src/lua/fileio.lua"]:504: table index is nil stack traceback: [string "src/lua/fileio.lua"]:504: in function 'loader' [string "src/lua/fileio.lua"]:595: in function 'LoadFromFile' [string "src/lua/fileio.lua"]:602: in function 'loaddocument' [string "src/lua/fileio.lua"]:628: in function 'LoadDocumentSet' [string "src/lua/main.lua"]:154: in function 'WordProcessor' [string "src/lua/main.lua"]:426: in function <[string "src/lua/main.lua"]:282>

This is OpenSUSE tumbleweed, Lua 5.3.6.

[davidgiven]

That's not good. Could you attach name.wg, please? (Assuming there's nothing confidential in it.)

[archpaladin1]

I actually made up the filename, but it happens with all my documents.

I tried to reproduce the issue on a new file that I could attach and found it happens when I rename the document 'main' in the document list. If I just start a document, write a line of text, save, close, and reopen it, the error does not occur. problematic-file.zip

I've attached a sample file that produces the error for me, compressed as a ZIP as github apparently doesn't like the 'wg' file extension.

[archpaladin1]

Okay, another interesting piece of information: the document name must be at least two numbers with a space.

I use wordgrinder for journaling and have habitually titled documents by date, formatted as 'YYYY MM DD'.

The following document titles didn't reproduce the error:

main test main foo bar 2023

But as soon as I tried

2023 05

the error occurred.

[davidgiven]

Well, the good news is I have a fix. The bad news is that it's revealed a much more architectural issue.

So there's a bidirectional lookup table used to map document names to indices and vice versa. When the file is loaded, I look to see if each document is referenced by name or number. What you were seeing was a bug where the code to detect numbers was wrong --- it was thinking that '2023 03' was a valid number, which it wasn't. (The fix was to add one character to a string.)

Unfortunately the architectural issue is that if the document name is a number, the whole thing falls over. I've patched around this by preventing people using numbers as document names. I have actually been reworking this whole area as part of a massive refactor, but that's still in progress --- it should arrive soon.

Thank you for the good bug report; it was really useful in tracking this down, embarrassing though the result was...

[archpaladin1]

I'm glad to help. Thanks for maintaining the software!

I can confirm that making the single line change referenced in the above commit will resolve the problem on the latest pull from the master branch.

I recognize that this is part of a larger architectural issue, but as far as I'm concerned the issue is resolved. I leave it to your discretion whether you want to close the ticket.