Stream mode: Phase 4 finale

[merv1n34k]

Hey!

I suppose this is the last piece of the stream mode functionality. With this PR (and 3 others) we essentially have a system, where both editor and engine have full push/pull capabilities. This in turn let us create a smart approach for fetching and updating engine requests for tex project (possibly even quite large ones with complex nested inputs). What is more interesting this approach completely eliminates the issue from PR 3, when engine restart was required.

Now, if the editor can detect and provide file(s) with register command to the driver and the engine simply pauses and continue upon open command. Like in this scheme:

1. Editor sends (register "a.tex") (register "b.tex") -- marks both as promised
2. Engine sends Q_OPRD "a.tex" -- driver can't find it, file is promised, stores query, doesn't answer yet
3. Driver emits (request-file "a.tex") -- engine blocks on socket
4. Editor sends (open "a.tex" "...") -- driver stores edit_data, skips rollback
5. Driver resolves deferred query -- engine gets A_OPEN, continues
6. Engine sends Q_OPRD "b.tex" -- same as step 2
7. Driver emits (request-file "b.tex") -- engine blocks
8. Editor sends (open "b.tex" "...") -- same as step 4
9. Driver resolves deferred query -- engine continues, zero restarts

Additionally, I have added timeout for Makefile test targets to fix the issue with long running tests, cap on 120s is generous.

Report

Problem

Phase 3's request-file is non-blocking: the engine fails the missing file immediately with A_PASS, TeX errors out, and the engine terminates. When the editor later provides the file, the engine must fully restart. Every missing file costs one restart.

Solution

(register "path") lets the editor pre-declare files it will provide. When the engine hits Q_OPRD for a registered-but-not-yet-provided file, the driver doesn't answer - it stores the query, emits request-file, and the engine blocks on the socket. When the editor sends open, the driver resolves the stored query in the same engine_step call. The engine continues as if the file was always there. Zero restarts.

How it works

Details

The editor sends (register "ch1.tex"), which sets promised = true on the file entry. When the engine later asks for ch1.tex via Q_OPRD and lookup_path fails, the driver sees e->promised and instead of answering A_PASS, stores the query in a deferred struct and breaks without responding. The engine blocks.

The driver emits (request-file "ch1.tex"). The editor responds with (open "ch1.tex" "content..."). interpret_open stores edit_data but skips notify_file_changes for promised files - calling it would trigger a rollback that kills the blocked engine.

On the next engine_step, the deferred check at the top sees deferred.active and edit_data present. It resets seen = -1, replays answer_query with the stored query, and flushes. Q_OPRD now finds edit_data and responds A_OPEN. The engine resumes.

What changed

Details

• state.h -- added bool promised to fileentry_t
• editor.h/editor.c -- parse (register "path") as EDIT_REGISTER
• engine_tex.c -- deferred struct on tex_engine, defer logic in Q_OPRD handler, resolution check at top of engine_step, cleared on rollback and prepare
• main.c — interpret_register sets promised = true, interpret_open skips notify_file_changes for promised files receiving first content, EDIT_REGISTER case in command dispatch
• EDITOR-PROTOCOL.md — documented register

P.S. I have built this PR on top of #125 , when we will finish with it I'll rebase this one to make a clean git history.

[merv1n34k]

I have also fixed the issue with errors on stream with pipe test - this is due to race conditions (quite noticeable on ubuntu) - I switched to FIFO like in the last 2 tests, now it should be robust.