В настоящее время я разбираюсь с тем редактором с подсветкой кода, что выкладывал на 4pda.to раньше для примера.
Из-за чего вожусь? - а просто я уже много лет хочу добавить подобный редактор в jbak2 и заменить им тот, который имеется в ней сейчас (стандартный класс EditText ).
И дело не в подсветке кода, а в скорости открытия больших файлов.

Но сколько я не думал об такой реализации, сколько не размышлял, всё равно выходила только одна стандартная схема - пишем свой адаптер для текста и загружаем текст в EditText небольшими кусками, со всеми вытекающими отсюда прелестями, как-то: обработка любого нажатия клавиши на клавиатуре (причём не в самой клавиатуре, а в редакторе), неважно стрелка это или вставка/удаление символа/строки, полная обработка выделения посимвольного, строкового, всего текста и многих прочих нюансов.
И всё это сразу корректировать в исходном тексте (и в edittext), чтобы иметь возможность сохранять изменения.

В общем, такую работу я точно не потяну с моими теперешними мозгами. А если и потяну, то вся работа по приведению всего в порядок, займёт не один год и думаю, даже не 5 лет...

Вы спросите - а почему в стандартном EditText  так не сделано? Неужели разработчики андроида за столько лет об этом не подумали?
Не знаю, думали или нет, но стандартный класс EditText  очень перегружен всякими ненужными для редактора текста  функциями.  А они очень сильно замедляют работу класса на этапе размещения текста (setText).
Отсюда и долгое открытие в редакторе больших текстов - само чтение большого текста в переменную, занимает от силы пару секунд, а всё остальное время, это размещение и форматирование этого текста в EditText. Что и вешает на этот период всю программу.

Поэтому программисты вынуждены писать свои реализации EditText для редакторов текста, отбросив все эти ненужные функции. Причём наследуются не от EditText, а от View.
Вот тогда и получается, что вся загрузка текста в свой EditText, происходит НАМНОГО быстрее и практически не нагружая процессор.
Именно так работают QuickEdit, редактор ABC, ещё несколько. Вернее, это я так думаю :)
И поэтому-же, не всегда клавиатура jbak2 может полностью и правильно работать в таких редакторах - в них просто отсутствует реализация каких-то команд клавиатуры (хотя они и все стандартные), поэтому они просто игнорируются. Или клавиатура не получает какую-то необходимую ей для реализации функции информацию, которую должен предоставлять редактор.

Прочитав недавно одну статью, я полностью убедился в своей правоте (а многого и не знал).
А голая компиляция той программы что я выкладывал на 4pda, совершенно пустая, без всяких ресурсов, только один код, весит тем не менее почти 2mb.

Вроде и ерунда по современным меркам, но в jbak2 keyboard я такое точно не включу.