Very fast changes to files on disk after they are saved are not detected on linux

[ilo-3a29]

In both textadept 12.9 and nightly, very fast changes to a file on disk after they are saved are not detected by TA and do not pop up a reload prompt or fire a FILE_CHANGED event.

This causes problems when using textadept as an editor for languages such as uiua, where the typical development flow is to leave the compiler watching for changes and modifying the source file when it detects it has been saved (for reformatting, updating special comments within the file with information for debugging, etc). This often happens faster than Textadept detects as a changed file after a save, and the user is not prompted to reload the file.

My exact distro is Fedora Silverblue 42, 64-bit, running textadept from the linux executables in the README (for both 12.9 and nightly). I've reproduced this in a fresh install with no configuration changes.

Reproduction

the smallest reproducing case I could find was to run inotifywait -e close test.txt | (read; echo 'change!' >> test.txt) and change the test.txt file in textadept and save it. TA doesn't prompt to reload the change to the file.

To reproduce with uiua: run uiua in the same directory as a file with the .ua extension open in textadept. Enter some uiua code like self * range 10 and save the file. The compiler will reformat the file, and it will have changed on disk, but textadept does not register the change.

[M0JXD]

I think this issue is multifaceted. One part is that Textadept is not checking in those scenarios.

It says it's running uiua in the background, and the launched inotifywait will run whilst Textadept is focused as inotifywait waits to detect a change from Textadept first before changing the file again.

But Textadept only tries to notice a file change when the Window comes back into focus or when buffer/view is switched, which simply isn't happening as it stays in focus in those scenarios.

textadept/core/file_io.lua

Lines 277 to 290 in fc2c574

	--- Detects if the current file has been externally modified and, if so, emits
	-- `events.FILE_CHANGED`.
	local function update_modified_file()
	if not buffer.filename then return end
	local mod_time = lfs.attributes(buffer.filename, 'modification')
	if mod_time and buffer.mod_time and buffer.mod_time < mod_time then
	buffer.mod_time = mod_time
	events.emit(events.FILE_CHANGED, buffer.filename)
	end
	end
	events.connect(events.BUFFER_AFTER_SWITCH, update_modified_file)
	events.connect(events.VIEW_AFTER_SWITCH, update_modified_file)
	events.connect(events.FOCUS, update_modified_file)
	events.connect(events.RESUME, update_modified_file)

Unless it forces Textadept to constantly check the file for changes I'm unsure what the solution is. Maybe something like this in its init.lua would work?

local function update_modified_file()
    if not buffer.filename then return end
    local mod_time = lfs.attributes(buffer.filename, 'modification')
    if mod_time and buffer.mod_time and buffer.mod_time < mod_time then
        buffer.mod_time = mod_time
        events.emit(events.FILE_CHANGED, buffer.filename)
    end
end

events.connect('check_timer',  update_modified_file)
timeout(0.2, function ()
    events.emit('check_timer')
    return true
end)

However even this has issues, as lfs.attributes only has so much resolution and inotifywait command happens within milliseconds of the change from Textadept it often doesn't detect the change with that. If I modify to add a sleep the above works: inotifywait -e close test.txt | (read; sleep 1; echo 'change!' >> test.txt) I'm unsure how responsive it needs Textadept to be for uiua?

Edit: Correct pronouns. Sorry about before 😞

[ilo-3a29]

Ah, I misunderstood how textadept was checking for file changes and assumed something like inotify was being used rather than it checking for changes based on comparing modification times when some events fire. Presumably changing this in the core would require using inotify or similar, which is both platform-specific and that may be adding more external deps for a very niche use case. If this is just out of scope or not reasonable given TA's other goals I understand. I'll leave this open, but understand that this may just be something that is out of scope for core TA.

Thanks for the ideas for workarounds, I'll try those.