Update: I've taken a look at the PR and seen that the 'mod_time VA' is not
related to the mtime file attribute I was talking about above. Apologies
for the noise.
J^n
On Tuesday, August 19, 2025 at 9:24:36 AM UTC+1 jkn wrote:
> Hi Felix
> when you talk about 'mod_time UA', are you talking about eg. the
> time(s) reported by the linux 'stat' command - last access time, last
> modify time, etc (or the Windows equivalent)?
>
> I ask for a couple of reasons:
>
> 1) I would have expected that these were dealt with by the underlying OS -
> having a file with no "mod_time" seems very odd, unless I am
> misunderstanding
> 2) separate to this, I have been having a bit of trouble with the Seafile
> "file sharing" facility I run on my local network. I am occasionally seeing
> an issue with my shared .leo files not being synchronised and I am
> wondering if there is a connection. More likely to be a Seafile issue, but
> you never know...
>
> Regards
> J^n
>
>
> On Tuesday, August 19, 2025 at 4:25:31 AM UTC+1 Félix wrote:
>
>> I've pulled devel and re-tested: The bug is still occuring, and I've
>> found another smaller one.
>>
>> Here's how to reproduce that first bug (in 3 steps)
>>
>> 1- In a new Leo file, create an @clean test.txt with some body text and
>> save. (*The resulting .leo file contains mod_time UAs*)
>>
>> 2-* Close Leo*, edit the test.txt file manually, and Re-Open Leo...
>> Observe that your external file changes were picked up. (*all OK so far*)
>>
>> 3- Save the leo file *without editing *(important!) to trigger the bug
>> -> The resulting .leo has *no* mod_time UA.
>>
>> (But if you edited even slightly the leo file before saving, the UAs will
>> be written normally)
>>
>>
>> Here's how to reproduce the other bug:
>>
>> (same step 1 as first example above) instead of closing leo completely at
>> *step
>> 2, *if you instead just close the tab (and thus keeping Leo opened by
>> having more than one tab opened with some other .leo file)
>>
>> ...and then complete the rest of the actions for step 2: edit the
>> external file 'test.txt' and re-open that .leo file's tab ...
>>
>> (at the end of step 2, before step 3) -> Upon opening that tab for this
>> .leo file, Leo will ask you if you want to reload that @clean from disk (as
>> if it was a 'live' file change when Leo is already opened) screenshot:
>> [image: Untitled.png]
>> Note that you can see underneath that dialog that the @clean body *was
>> already refreshed with the new external file content*. and that
>> responding yes or no does not do any difference. (the new content is used)
>>
>> (From what I remember of using @clean nodes for many years, I think it
>> should just reload the new @clean file content without asking, just like
>> when opening it along with leo itself)
>>
>> I'll easily show you those 2 bugs explicitly by sharing my screen in a
>> zoom if those two descriptions on how to reproduce them are not clear. :)
>>
>> Félix
>>
>> On Monday, August 18, 2025 at 8:19:41 AM UTC-4 Edward K. Ream wrote:
>>
>>> PR #4418 <https://github.com/leo-editor/leo-editor/pull/4418> contains
>>> important improvements to Leo's read/write code.
>>>
>>> Félix remains skeptical that it works in all cases.
>>>
>>> I haven't heard from him in over a week. In the absence of further
>>> comments I think the benefits of wider testing outweigh any remaining
>>> problems.
>>>
>>> Please keep testing devel and report any problems.
>>>
>>> Edward
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/leo-editor/5f7a9b69-492d-473b-ba07-1f7e16592dd0n%40googlegroups.com.
