Why get rid of these at the top, to go use the uglier local widget = require("ui/widget/keyvaluepage"):new{...} below ?
I don't think there's any risk of require loop here.
I admit I sometime do it when it's a rarely used module, to wait to load it - so it might be fine for ImageViewer and KeyBaluePage - but DocSettings is probably always loaded, so it doesn't really need this treatment.

BookInfo page and its parts (description, cover) may be shown without Docsettings sometimes. So it has been moved to getBookProps where it is used.

The same for KeyValuePage: if we ask to show book description only, it is not needed.

I understand you do not like require():new and prefer local before?

Yes, but then, why not do the same for InfoMessage and require it in onShowBookCover() and onShowBookDescription(), which are both rarely used?

It's also not the number of times it is used that should make it be at the top, rather how frequent/heavy it is, and if other modules would already have require() it and it is most probably already in memory. ie. for KeyValuePage, readerdictionary.lua does it at the top, so it's already in memory (or soon will be in your "start in file browser").

If you start with doing that, we'll shrink the top of our files quite heavily :)
And require("ui/widget/keyvaluepage"):new{...} is just ugly. It's fine for quick shorthands like needing a function form util.lua, but otherwise, it brings nothing.

I understand you do not like require():new and prefer local before?

Yes, I would prefer a local = require(...) on one line and the :new{} on the next, it's more readable - and what we mostly use.
(But the little require("util").doSomeSstuff() are small and fine).

Just saying, do not go too crazy with moving them all into where the function they are used. It feels OK for ImaveViewer, which we seldom need, also OK for KeyValuePage even if we do require it at top elsewhere, but DocSettings is so common.

The wording is a bit inconsistent (Last read date: vs Date modified:, shouldn't it be Modified date: ?
But I would keep using File date: (modification time is the Linux/Lua technical name for the info ; it's the creation date or the copy date for copied files depending on the tech used to do that copy, or the modification time for PDF with highlights written into them).

But: attr.access may or may not be updated by the OS when the file is read from. And "read from" may be just when extract and cache book info, or fetching book info, and it's not really the "last read date" as we expect it in a book reading application :)
For a field name "Last read date", I would expect the date to come from the doc settings file data.

I think the only valid and interesting info is attr.modification, and it should just be named "File date" to not imply anything else.
(Even if my Windows 10 Explorer shows "Modifié le" ("Modified at" in English I guess) :)

This inconsistency goes from the old FileChooser sorting that I have kept there and here.
There are 3 types of date for sorting.
Does it make sense? Or to keep just modified?

I see, the 3 linux timestamps I get with:

$ stat frontend/util.lua
Access: 2023-02-20 17:45:06.557652131 +0100
Modify: 2023-03-28 20:40:24.195326654 +0200
Change: 2023-03-28 20:40:24.207326417 +0200
 Birth: 2023-02-20 17:45:06.557652131 +0100 (didn't even know about this one :)

These have some technical meaning in Linux.
On my Linux, I have the filesystem mounted with "noatime" to limit useless writes to disk, so it isn't updated. Real devices (or appimage users) may or may not do that, we can't really know. And no real idea how it works on the FAT32 filesystems on our devices.
Showing them may have different meaning for the users, if they know how their devices work, and the process to transfer books to the devices, so, different users may get different infos from reading these 3 times.
But for most users, it's probably hard to make sense on each of these 3 values - or they may all show the same date.

As for sorting in KOReader, I'm always disappointed when I'm using it and trying the 3 options, to try to see the last files I added - I copy files with Windows Explorer, which preserves timestamp - and depending on how i got the file (old ones on my harddrive keep their old date, downloaded as epub get the time downloaded, downloaded as zip get their time inside the zip when extracted), so it's most often always useless, to me.
I think it was discussed at the time they were added, may be it made some sense to some people, don't remember.

So, dunno :)
If you'll end up keeping showing attr.access, it may be best to use its litteral name, "Last access time" - to distinguish it from "Last read time", which should only be our "last read in KOReader" time, the docsetting date.
Change is most probably = to Modified, so useless.

@NiLuJe or @Frenzie probably have more thoughts about that.

I think Windows created (birth) and modified are much more useful than access and change time. To me those others aren't useful.

lfs.attributes doesn't provide "birth" date. So, show modification only?

atime will very much be useless 99.99% of the time, so, yeah, +1 for only mentioning mtime ;).

And to sate my curiosity about btime, it's a Linux extension, only available when calling statx, which requires Linux 4.11+ & glibc 2.28+ ;).

(It's implemented in stat on BSDs, and apparently ntfs3g, too; but the TLDR; being: nope, can't have it).

btime usually seems to be the same as mtime anyway due to modern programs taking the safe approach (though on Win created usually seems to be maintained)

Is this something happening per book or per page ? Looks like it's when a page contains no word ? So, its possible that on books with mixed text and pictures pages, we'll get to see "Current page lines/words" on some pages and not on others ?
Not sure what is best: showing:hiding, or always showing them, with the possibility of Current page lines: 0 or Current page lines: N/A (which could mean: lines not available on that page, or info about lines not available).

Anyway, you have the same situation in CRE document, ie. for the cover page. It most often shows Lines: 0 but Words: 1 or 2 for such pages. Dunno why 1 or 2 words, may be it grabs bits from prev/next pages. So if deciding about having lines and words, best to trust Lines first.

I think it should be consistent between PDF and CRE.

Done

@Frenzie : what's the grammatically correct name for this function ? (again, singular/plural... :/)

LineWordNumbers
LinesWordsNumbers
LineWordNumber
LinesWordsNumber
NumbersOfLinesAndWords

An option was getCurrentPageNumberOfLinesWords.

Probably LineWordCount?

getCurrentPageLineWordCount or ...LineWordCounts (as it returns 2 numbers) ?

Yes, good point. Let's go with that. ^_^

Oh, this one is nearly everywhere at top of files, and nearly never in a function.

As I understand, require does not double load already loaded module, but it does check every time if the module has been loaded.
So what are the benefits of having all the requires at the top?

You said it: it does check every time if the module has been loaded.
So, having it at the top avoid that checks every time your function is called. (even if that check time is peanuts/small, it must be just checking if a thing is in a table, and not worth fighting).

But this is not why I insist on these: it's just for consistency, whether it's good or bad, in all our modules, we have many standard require= at top, it's not worth changeing that and start inlining them now as you will edit modules.
(Again, except for heavy or rarely used modules, which are best require()d when they are about to be used.)

It makes it simple to glance at the top of the file to see what it uses. It's a fairly common pattern for that reason.

You could just increment a counter, instead of accumulating in the table words.

I will do.