А не думал текст тупо в виде массива строк хранить? 99.99% редактируемых файлов состоит из большого количества коротких строчек, а на остальные 0.01% поебать вообще, потому что это либо какая-нибудь бинарщина, либо ещё что, не требующее редактирования. В конце концов, если совсем припечет, всегда можно открыть другой редактор.

(Reply to this) (Thread)

можно тогда вообще все пункты пропустить, и сразу перейти к «открыть другой редактор». потому что зачем стараться, писать заточеный под себя редактор, чтобы в итоге всё равно ебаться с другими?

алсо, за хранение текста как массива строк надо убивать, потому что их ресайз режет память на фрагменты. а для начальной загрузки файла требуется или как минимум textsize*2 памяти, или ебаться с буферизированым чтением — чтобы распарзить файл на строки. делать undo тоже менее удобно.

попробуй сам написать массив строк, а потом gap buffer, и ты удивишься: gap buffer, даже с теневыми кэшами — будет проще в реализации. и эффективней.

вдобавок, на gap buffer можно спокойно натравить любой существующий движок регэкспов (потому что редактор без регэкспов нахер бесполезен): просто сдвинуть дырку в конец — и опа, у тебя есть красивый линейный буфер с тектом. ну, и для других применений линейный буфер тоже часто удобен.

реально, лучше gap buffer — по соотношению простоты реализации и удобных фич — для редакторов текста пока что ничего не придумали. как только память перестала быть ограничивающим фактором — gap buffer начал заруливать всех остальных.

а вот уже для word processor типа abiword я бы взял piece chain, аугментированый какими-нибудь деревьями для быстрого поиска позиций и строк (b-tree, например).

за счёт теневого кэша со смещениями строк, кстати, элементарно реализуются даже достаточно продвинутые штуки типа visual word wrapping и text folding (который ненужен).

у меня этот же движок используется и для реализации простого rich editor (который шрифты, цвета, такое вот всё): буфер раскраски просто используется для хранения стилей текста. вообще, буфер раскраски можно применить кучей интересных методов: хранить там ссылки на объекты, которые умеют себя рисовать и знают свои размеры, например — и оп: в редактор можно вставлять картинки и прочую еботу, например.

в апдейтнутой версии движка я вообще забил на обновление кэша смещений по запросу: просто тупо чиню его полностью при каждом изменении текста. для тех же 210 мегов починка занимает около пяти миллисекунд. опять тупая скорость железа победила красивые алгоритмы.

(Reply to this) (Parent) (Thread)

потому что их ресайз режет память на фрагменты

Да ладно, беспокоиться о фрагментации памяти? Несуществующая проблема.

а для начальной загрузки файла требуется или как минимум textsize*2 памяти

Зачем? Когда будем изменять строку - тогда и расширим буфер.
Вообще-то, даже если сделать строки немутабельными и тупо пересоздавать их при каждом новом изменении - не будет заметно НИКАКОЙ потери производительности. Любой хуевый пека умеет экран пикселями заполнять в реальном времени есличо - даже очень длинная строчка это вообще ничто по сравнению с графикой, ноль, пикосекунда.

(Reply to this) (Parent) (Thread)

>Несуществующая проблема.
в следующий раз, когда будешь удивляться, почему какая-то софтина такое жирное тормозное говно, выжирающее всю память — посмотри в зеркало. увидишь там ответ.

>Зачем?
а также когда будешь удивляться, почему что-то делает глючную херню. ответ там же. я даже написал, зачем — но ты не просто подумать поленился, ты и читать-то не стал.

если тебе несложно, исполни, пожалуйста, одну мою маленькую просьбу: никогда не пиши программ. я буду ОЧЕНЬ благодарен. пожалуйста.

(Reply to this) (Parent) (Thread)

в следующий раз, когда будешь удивляться, почему какая-то софтина такое жирное тормозное говно, выжирающее всю память — посмотри в зеркало. увидишь там ответ.

Хочешь сказать, что софт становится жирным тормозным говном именно из-за фрагментации памяти? Ок.

(Reply to this) (Parent) (Thread)

вот именно поэтому — не пиши. не надо. ты в принципе не понимаешь, как это делать.

(Reply to this) (Parent) (Thread)

Зато ты понимаешь, поэтому твоим охуенным софтом пользуются дохуя людей по всему миру, включая других охуенных программистов. (на самом деле нет по всем пунктам лол)

(Reply to this) (Parent) (Thread)

спасибо, продолжай, пожалуйста. ты великолепен в своём полном непонимании, практически идеален.

(Reply to this) (Parent)

Ты не понимаешь, что такое bottleneck и на какие места нужно забивать хуй в пользу действительно важных оптимизаций. Твой охуенный редактор тратит N циклов на всякие внутренние операции со строчками, а потом в дело вступает шревтовый движок и тратит N * 10000000, чтобы вывести это на экран. Удачных микрооптимизаций, юный падаван.

(Reply to this) (Parent) (Thread)

ёбта, говорящий помидор!!!

(Reply to this) (Parent) (Thread)

Дрочи, дрочи. Всё-таки замерь на досуге, сколько времени твой говноэмулятор терминала экрано обновляет по сравнению со всем остальным.

(Reply to this) (Parent) (Thread)

ёбта, дважды говорящий помидор!!!

(Reply to this) (Parent)