the logic seemingly mirrors the one from _ff_state_build, creating repetition. I suggest extracting it to a different method to keep things DRYer and more maintainable
we should be careful with LMC, since it can be disabled by user, so this part needs further review and discussion.
general note: LMC is an optional feature. If it's disabled and the log is refetched, it should not be applied.
Please, extract bom-check to a different method. it is violates DRY and SRP. database_flatfile_validate.c:123
Same issue as earlier with copyright. We are not affiliated with Profanity.
Please, extract bom-check to a different method. it is violates DRY and SRP. Repeated in database_flatfile.c:163
Is it a wrong offset or is it gitea's UI bug? It appears that the line is overly offset to the right, violating general formatting
While the comment is useful, it violates general style of this example. I suggest moving documentation to more appropriate places.
Does the switch automatically export/import? It is unclear from documentation.
Typically, prefs are not autosaved and need manual saving via /save command. This place creates an exception, which needs to be discussed (e.g., later we might add /autosave command).
here and in other places: if the method does not exists, then it just passes. I think that we need to log this invalid state.
While the code has a lot of merits, certain parts should be adjusted to follow the best practices, as well as to correct logic. Specific parts would require further discussion.
O_APPEND won't execute since O_EXCL would throw an error if file already exists.