Lectrote 1.3.8

Technical Development Interpreters
1

New update:

The big change here is a fix to Quixe which should prevent the spurious MORE prompt in fixed-size buffer windows. (This happened in HTML TADS games, for example.) I’ve been staring at that for a while now but I think I’ve taken care of it.

There are more changes, mostly under the hood. Let me know if anything seems broken.

6 Likes
2

You forgot to mention one of the biggest changes: TADS 2/3 support! :smiley:

3 Likes
3

Woohoo Tads support, big thanks!

I have been experimenting with adding an auto-completion with tab button (more precise its adding to quixe submodule).


If anyone in need of compiled version of lectrote, let me know.
4

I am unable to save a script for a TADS game (Captivity) on linux-64:

>script
Failed; an error occurred opening the script file.

5

Trying to play Captivity now, it has two scrollable windows (buffers?), the top one which shows location and turn count, and the bottom for in-/output. Whenever I enter a command the focus is automatically shifted to the top window.

6

Oh crap! I was somehow thinking that TADS support was added in 1.3.6. I apologize.

I’ve added that note to the release page, for it is indeed the biggest change.

7

Hm, I’m not seeing this (on Mac). Both windows have scroll bars, but the focus stays on the bottom window.

Are you getting a MORE prompt in the top window?

8

Yes, I do.

9

Okay, thanks. I’ll keep stomping on that.

1 Like
10

Yeah, both SAVE and SCRIPT seem to fail for all TADS games. Dannii submitted one patch before release to try to improve filesystem issues, but it seems to need more…

1.3.9 will be coming as soon as we figure these things out. :) EDIT: Really I should call it 1.4.0, as TADS is a major new feature.

2 Likes
11

I notice that Electron now supports spellchecking in the input line. (The red-dotted-line convention for misspelled words.) What do people think about this? I find it deeply annoying, but I know not everybody does.

12

…That is of course the built-in Chromium or OS-native spellchecker (depending on platform). It’s not hooked up to the interpreter’s dictionary.

Hooking it up – so that “frotz” is not tagged as a misspelled word in Enchanter – seems like it might be possible. But it feels like an awfully big hack for a small feature.

13

Still the only interpreter I’ve found for Linux that displays the Unicode in Scroll Thief correctly.

But if anyone else is trying to run it under Debian, it seems you have to use the --no-sandbox option for it to start. I guess it’s the same problem that was discussed when Hadean Lands was updated recently. See https://steamcommunity.com/app/376240/eventcomments/3935537639860451865 for details.

Which leads to my main question: When I do use the --no-sandbox option, like so:

$ ./Lectrote --no-sandbox "Scroll Thief.gblorb"

I get an error dialog saying “The game file could not be read. Error: NOENT: no such file or directory, open ‘–no-sandbox’”. Then the game starts as expected. So it looks like Lectrote handles --no-sandbox correctly, but then assumes it’s also a file name?

14

Could be. I thought the binary ate all the browser-specific arguments before launching the app, but maybe not (or maybe not on Linux).

15

Don’t know how I missed the TADS file problems, was sure I had tested at least saving and restoring. Well, I’ll get on it!

2 Likes
16

So, the TADS saving/script problem occurs when compiling TADS from @cas’s terps repository against cheapglk too. Good to know that it’s not my fault, but unfortunately this means a fix will take some work.

So I’m pretty sure I’ve identified the issue: this part of the Glk port of TADS looks like it depends on a GARGLK extension to extract the filename from a fileref.

If you’re not compiling it against GARGLK then even though os_askfile returns a success code, the filename buffer will be empty.

The good news is that garglk_fileref_get_name is really simple:

char *garglk_fileref_get_name(fileref_t *fref)
{
    return fref->filename;
}

I just tried hacking a few things together, and once this function is exposed to osglk.c it works.

So I think the path forward is to formally add this function to the Glk extensions, to add it to RemGlk, and to change the Glk port to check for a new GLK_MODULE_FILEREF_GET_NAME constant instead of GARGLK. It should probably also return a failure code if the Glk library doesn’t have the extension. Ideally before even calling glk_fileref_create_by_prompt!

Edit: first part is done: the spec
PRs for the rest are done too.

3 Likes