I'd very much like this to be hidden behind a Device:isKindle branch, because nobody else in their right mind should care about it ;).

I understand the dislike for the format, but I think it's mainly a "middle step" to allow people to use tools that parse that kind of file. A kind of extra compatibility feature, as kindles have quite a bit of market share.

A standard across software, even if a bad one, could be nice to have, so we can avoid remaking the same tools multiple times :')
So I thought that having an extra format that is used by different tools could be beneficial to the project.
It's kind of funny in a way how even Koreader can parse "MyClippings.txt", if you think about it :')

For example, there is an Obsidian notes plugin that then allows you to orderly import the highlights and notes incrementally (ignoring highlights you already have imported) and with a custom template that you can specify, as well as splitting them on a one-note-per-book basis.

Locking it behind a "on kindle only" would make for a bit on inconsistency to me across versions (given I'm using tools that parse that format, I'd like it on all platforms... Pdfs suck on smaller e-ink readers, so Koreader on desktop is much better), which I never understand very well when it comes to software...

That said, yeah, this format makes no sense as a "final product", so I'd totally see if members of Koreader would push against this feature. :')

I made the PR before checking for other issues and seeing a similar issue discarded before - mainly because I needed to use the tool and wanted to see if I could make my way through an unknown repo and make changes - and later saw the maintainer that disapproved of it suggested making new tools that parse Koreader's format.
I could do that, but it takes much more energy than modifying Koreader's code to have an extra format, mostly due to the struggle of having to maintain a project which is basically the same of another one, so having to constantly "check" and update the other repository...

If the members find it more interesting, we could work towards having a user-facing template that can be modified from them for some of the formats (markdown?), so that you could use placeholders like "---/n{{page}} - {{date}}/n/n> {{highlight}}\n\n{{note}}" for example, although sharing the option across devices would require you to manually save it somewhere, as a user.
This would remove the need for a lot of "middle-ware" to format things as you do with other tools I think, although it wouldn't split up the highlights to different files for different books, but that would probably out of scope.

Super thanks for considering it and fixing up the code style 🌸☺️
Really love the project and I'm glad to help in any way I can :)

Fair enough (I was under the assumption that there were very few actually useful tools built around this specific format, which colored my initial response) ;).

Thanks for the benefit of the doubt and reading :)
This is the Obsidian tool (absolutely love it): https://github.com/hadynz/obsidian-kindle-plugin

And other tools:
To notion: https://github.com/paperboi/kindle2notion and https://github.com/arkalim/kindle-to-notion
To logseq: https://github.com/theBenForce/logseq-plugin-my-highlights
To markdown with custom template: https://github.com/rc2dev/fyodor

There's even a whole service that takes care of handling myClippings for people https://my.clippings.io/ 🤣 Amazon did such a "great job" with their exports :')

Thanks for the catch on remaining "myClippings" and love the attention to naming 🥰

I guess it doesn't make much sense to export a single document with this exporter. Anyhow, did you tested it? does it work (ie: doesn't crash, produces an expected output)?

Yeah, everything seems to work as expected.

• Program doesn't crash
• No error messages in the console
• Exports correctly notes from all books as well as from one book

Gif: (The first "success message" didn't show because I pressed immediately)

Added a bug fix: The previous base.lua model for Exporters would getFilePath by either using the name of the book (if the table had just one entry) or defaulting to "all-books".

This means that files that use the same extension would get written one after the other, in the same file.

By adding a new property to the model all_books_title, you can now specify the name that the exporter will give to the file containing all the books' highlights, removing the collision.
If the property is missing, the function still defaults to "all_books", maintaining backwards compatibility without the need to specify the property value in each target.

Following this fix the "MyClippings" file will now be called <timestamp>_MyClippings.txt when exporting all the notes, otherwise defaulting to the title of the book.

Oh wow, how did I miss this jewel :D
Thanks @Mochitto !

I would probably find this really useful.

When using Kindle PW3 I used KindleMate to extract MyClippings.txt info in one tweakable format. Now I can add all my KOReader-read books to this bunch :D
My inner OCD is happy 😃

Super happy this will help you ☺️🌸