Feature/big file fast load recyclerview

[lrq3000]

This PR implements a new EditText using RecyclerView to load and allow to edit large files instantaneously

Summary

In summary, this is done by making a new shared interface MarkorEditor and a subclass RecyclerTextEditor the classic editor HighlightingEditor to also be a child of MarkorEditor, and wire DocumentEditAndViewFragment to use _activeEditor for both editor types, so format features work in recycler mode while undo/redo remains non-recycler-only.

All features are implemented because inherited.

The RecyclerTextEditor is only enabled for large files. The threshold is about 512 KB and is defined here:

RECYCLER_EDITOR_FILE_BYTES_THRESHOLD = 512L * 1024L (1,048,576 bytes)

I defined this threshold empirically from my own dataset and phone. Of course this will probably be different for each phone, but as a first implementation, I think it's best to keep it simple, the threshold can be made dynamical later if the static one is not good enough. Or i can be made into a user-facing option, that would be easy I think.

Implementation details

• Introduce and wire MarkorEditor as the common editor abstraction across normal and large-file modes.
• Implement full MarkorEditor support in RecyclerTextEditor, including global selection/cursor mapping, token-aware text insertion, search/highlight state hooks, and watcher forwarding across line-based cells.
• Update DocumentEditAndViewFragment to use _activeEditor for both editor types, enabling format actions and search in large-file mode while keeping undo/redo limited to non-recycler mode.

This was achieved through composition + common contract (since multi-subclass inheritance is not possible in Java), so we implemented a shared interface: MarkorEditor. Both concrete editors implement it:

• HighlightingEditor (classic EditText)
• RecyclerTextEditor (large-file RecyclerView)

Format behaviors already live int he format system (FormatRegistry + ActionButtonBase + format action classes) so we reused that.

DocumentEditAndViewFragment now routes those format features through _activeEditor (MarkorEditor), which points to either editor depending on file size.

Fixes

This PR is a follow-up to PR #2769 (so #2769's commits are also in the history here, this will require a rebase after #2769 gets merged).

This fixes definitely issues related to performance with large files, including #2739, #2716, #2652 .

Test builds

Test builds are available here: https://github.com/lrq3000/markor/actions/runs/23093127494

Authorship

This PR was made by Stephen Karl Larroque (lrq3000) using AI agentic coding (OpenCode and Oh My Opencode with ChatGPT Codex-5.3 and ulw mode in the prompt).

No third-party codebase was used and no internet connection was established by the AI agent during the development of this PR.

Todo

• Maintainers careful review of all the changes, as this is quite a big PR with a lot of changes.

[lrq3000]

PR not yet ready, there are missing features such as syntax highlighting and the actions are not working.

I will make this PR ready for review when I myself will be using this large files PR as my main Markor instance for a couple of days.

[lrq3000]

Progress update: at this point, the app is now stable again, it can open large markdown files but also large todo.txt files, and all actions work by tapping buttons and also by autoformatting (eg, newline in a bullet list will create a new bullet item). In-file navigation such as filter by task priority or markdown table of contents are working too.

Syntax highlighting and undo/redo are still missing.

Test build (will install as Marder, not Markor) available here: https://github.com/lrq3000/markor/actions/runs/23205791477

[harshad1]

what is the bottleneck for the existing editor? iirc it was layout. Can we just speed that up?

[lrq3000]

The AutoFormat causes several tricky bugs, some of which are already present in v2.16.0 (hence before merging PR #2769 speed regression fix).

One example:

If you have a list like this:

1. item a
2. item b

(the two newlines after the list are necessary)

Then select these two lines and copy, then close Markor, reopen it, and paste these two lines at the end, you will get:

1. item a
2. item b

3. item a
4. item b

So far so good. Now try to undo. You get this:

1. item a
2. item b

1. item a
2. item b

And the undo history is exhausted at this point, so you cannot restore the true original state before the multi-lines paste.

This happens because of Autoformat messing up the undo history by modifying the input, and it has various side effects that are different for single lines and multiple lines edits/pastes.

I spotted this because the AI tipped me on Autoformat acting differently for multi-line edits compared to single line edits while improving this PR.

I am not opening a separate issue as I suggest that I fix as many of these autoformat side effects for the classical Markor editor while doing the same for the RecyclerTextEditor (since in this PR both are inheriting from a single parent editor class, so we can try to make fixes that work for both).

[lrq3000]

@harshad1 the UI redraw bottleneck was fixed in #2769, so we got back the same speed as before now that Markor v2.16.1 got released, which is already very good.

However, there will always be a limitation with the current implementation because the whole file needs to be loaded in RAM and drawn all at once, so the loading speed is proportional to the file size.

This PR implements a second editor class that leverages the RecyclerView class which allows to load and draw only a part of a file if I understood correctly.

In practice, this allows to decouple the loading delay from the file size, so that opening files of any size is effectively instantaneous.

This is however an experimental approach than no other stable editor ever implemented on Android, the only precedent is BigEditText which was just a proof of concept. This is however not a new concept at all in computer science, it's actually quite old, and lots of editors implement it on desktop OSes.