Message 'No todos in this file' after a task has been completed about sleek

[ransome1]

@mdbdb @TriggerDingus in 2.0.12 we were tweaking the filewatcher settings a bit, because some had issues with sleek and file syncing applications. Actually this has been a constant pain for years now. We also introduced new settings to tackle difficulties, which could arise in environment, where there is file syncing involved.

@aisbergde @RobLW @42web-ch this is also a heads up for you guys. In the next pre-release (2.0.13-rc.2) I will revert the default settings of the filewatcher to pre 2.0.12 since it seemed to worked better for the majority of users. 2.0.12 has only just been released and is already producing bug reports connected to the change.

I will furthermore remove the 3 settings we introduced over at #676.

Instead I will introduce 1 new setting named chokidarOptions. This new setting represents the chokidar options object as described here: https://github.com/paulmillr/chokidar?tab=readme-ov-file#persistence

Like this you will have all of Chokidar's options available and can adjust the filewatcher precisely to your environment. Since you might have already adapted to the 3 new options you will now need to apply your changes using the chokidar syntax. For example:

{
usePolling: false,
interval: 100,
atomic: true
}

Chokidar has many more options, which can help figuring out a working setting for your particular environment.

[ransome1]

@mdbdb is there by any chance some file sync happening in the background, for example Synchting, Dropbox, Google Drive and so forth?

[ransome1]

@mdbdb @TriggerDingus before you start wrapping your head around all those Chokidar options, can I ask you to check out this pre-release and tell me if the issue still occurs? https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.2

If the config migration worked, it should regress to the behavior of sleek 2.0.11, where I understand you did not face these issues.

@aisbergde @RobLW @42web-ch you're invited to check the new option and let me know if this works for you.

[TriggerDingus]

@mdbdb @TriggerDingus before you start wrapping your head around all those Chokidar options, can I ask you to check out this pre-release and tell me if the issue still occurs? https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.2

If the config migration worked, it should regress to the behavior of sleek 2.0.11, where I understand you did not face these issues.

@aisbergde @RobLW @42web-ch you're invited to check the new option and let me know if this works for you.

I completed several tasks with the AppImage and no issues so far. I'll keep using it this afternoon and report if it happens again.

[GaloisGecko]

I have the exact same issue. I tried it with a file that is not synced to any other storage. But I observed that the issue occurs if and only if the task is recurring: If I complete the following task

2024-03-27 test  rec:+1d due:2024-03-27

the UI will show no tasks any more, but if I complete

2024-03-27 test due:2024-03-27

all remaining open tasks will stay on the UI as desired.
Maybe it helps to narrow down the issue.

[ransome1]

@GaloisGecko

the UI will show no tasks any more, but if I complete

What exactly does the UI show?

And how do your filter settings look like in the drawer?

[GaloisGecko]

This is the UI including filter settings before I complete the recurring task:

And after I complete the recurring task, it looks like this:

If the task would not be recurring, it would vanish, but the other task would remain on the UI.

[ransome1]

Is this the latest pre-release (2.0.13-rc.2) or 2.0.12? If it is the latter, does the same happen with the pre-release as well? There is an AppImage in that release for a quick glance.

[GaloisGecko]

I am still on 2.0.12, sorry for that.
Update: Now I checked with the AppImage for 2.0.13-rc.2 and it works fine! The tasks do not vanish any more!

[mdbdb]

@mdbdb @TriggerDingus before you start wrapping your head around all those Chokidar options, can I ask you to check out this pre-release and tell me if the issue still occurs? https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.2

If the config migration worked, it should regress to the behavior of sleek 2.0.11, where I understand you did not face these issues.

@aisbergde @RobLW @42web-ch you're invited to check the new option and let me know if this works for you.

I just marked some of my tasks as done with version 2.0.13-rc.2 under the same conditions as before (todo.txt is synchronized via Syncthing).

➡️ The error no longer occurs!

[ransome1]

@mdbdb has been released with 2.0.13. If it occurs again, check back in here. We now have several ways to adjust to your environment with these settings.

[42web-ch]

@ransome1 Hi, thanks for the update. I am switched from debian to arch on my work pc. All works fine on the new setup!

[RobLW]

Apologies I've been neglecting the app recently so not noticed changes/issues.

I've just updated Fedora from 39 to 40. The issue took place then. When I opened the app and laid my mouse over the tabs, I noticed that it was referring to a location that I think was for temporary files.(sorry I forgot to make actual note or screenshot).

Thinking about it now, I'm wondering does the app use a temporary file while open, and occasionally writes this back to the actual todo files?.
If this is the case then when we reboot without closing down the app (which is always the case for me) the system will wipe the temp files and the app loads again expecting to find those files rather than loading the todo files in my home dir.? Just a thought.

EDIT:
ah just run it from the command line and noticed it does:
Watching new file: /run/user/1000/doc/4f9257d5/todo_2024_02.txt
Which I guess is the temp file I'm talking about above.

I'm using 2.0.13 flatpak.

On a side note I also saw this error when starting, even though the file is there with setuid on it.
[2:0425/122434.527260:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory