Force-disable `fastdirty` on large files

[DUOLabs333]

Is it possible to add an option to force-disable fastdirty on all files, even on ones larger than 50KB?

[cutelisp]

From what I can see: no. fastdirty seems to be hardcoded to be enabled when the file size exceeds a constant (50KB). Maybe we could turn this into an option so the user can choose the threshold? Or perhaps make the fastdirty a threshold itself (similar to autosave)?

Note: Shouldn't it be "enabled" instead of "disabled"? https://github.com/zyedidia/micro/blob/d7e43d497448cc30a20c38b8d76388877f6918e7/runtime/help/options.md?plain=1#L145-L146

[dmaluka]

Note: Shouldn't it be "enabled" instead of "disabled"?

Yes it should.

[dmaluka]

Maybe we could turn this into an option so the user can choose the threshold? Or perhaps make the fastdirty a threshold itself (similar to autosave)?

I think that's a wrong direction to go. This threshold is basically a hack around the fact that this stupid md5 hashing (i.e. fastdirty=off) is a hack around the fact that micro doesn't do what every other damn editor does, i.e. doesn't check if the undo stack isn't empty when checking if the buffer is modified or not.

I wrote about that here: https://github.com/zyedidia/micro/pull/3430#issuecomment-2295308300

If we fix that (i.e. make fastdirty=on check if all changes have been undone, not just check if there were no changes at all), it seems we can enable fastdirty by default (since even without hashing it will be reasonably accurate; while currently fastdirty=on is barely usable). And if we do that, we can also remove this threshold, since fastdirty will be enabled by default, so it will be only disabled by users who are willing to pay the performance price, even for large files.

[cutelisp]

i.e. doesn't check if the undo stack isn't empty when checking if the buffer is modified or not.

Is that enough? Since I can add a char and delete it -> undo stack won't be empty although the buffer isn't modified. Right?

[dmaluka]

The buffer is modified, twice. The result happens to be identical to the original buffer, so what?

[cutelisp]

I was just pointing out that, with this approach, Micro can flag a buffer as modified even if its content hasn’t changed. In fact, you already wondered about this :https://github.com/zyedidia/micro/pull/3430#issuecomment-2295343252

[dmaluka]

Yes, obviously. So? I'm not aware of any other editors implementing this hash-based "super precise" logic instead of simple undo-based logic, and I'm not aware of any users of those editors complaining about lack of this "super precise" checking.

But I easily see why micro users (including myself) complain when this "super precise" logic is forcefully disabled for large files, - not because undo-based logic as an alternative wouldn't be enough but because undo-based logic as an alternative simply isn't there.

[cutelisp]

I'm not aware of any other editors implementing this hash-based "super precise" logic

Right, as I said I was just pointing out... I wrongly thought almost every editor would track "dirtiness" precisely . Zed and helix seem to do it, probably not with hashing tho.