Как организовать память для текстового редактора?

[ram_scan]

Подавляющее количество (если не все) текстовых редакторов устроены так как написал esl во втором посте (когда текст расположен вначале и конце памяти а в месте курсора - буфер).

Только процедуру печати экрана целиком нужно делать тоже "двухстороннюю", когда выше курсора текстпечатается снизу вверх (к началу экрана) а ниже курсора - сверху вниз.

Реализация такого редактора получается тривиальной, скорость работы чумовая независимо от размера текста.

При этом больше страницы текста за раз приходится двигать только в случае навигации в начало и конец документа.

[bigral]

Даже не знаю как назвать структуру данных которая предложена(массив с элементами разной длинны и маркером в конце + перемещаемый свободный буфер в средине этого "типо-массива"). Самое интересное что сейчас такие задачи пишутся с какими нибудь двух-связными списками которые сами по себе будут занимать по 6 байт на каждую строку текста + еще при выделении памяти в самой OS будет хранится куча инфы про выделенные блоки (КОРОЧЕ - МРАКОБЕСИЕ)

Может есть еще у этого алгоритма "продолжение" про то как его расширить для редактирования файлов большего размера чем свободное пространство?

[vinxru]

Просто загружаем файл кусками по 16 Кб (из расчета, что у нас 32 Кб памяти под текст). Экран при этом занимать больше чем 16 Кб не должен. Сложность лишь при сохранении, придется весь файл сдвигать, если редактируемый кусок изменил размер

[esl]

Может есть еще у этого алгоритма "продолжение" про то как его расширить для редактирования файлов большего размера чем свободное пространство?

Связные списки всякие - слишком расточительно для ограниченной памяти, там каждый байт на учёт

Я ж писал что микро мир на корвете/ямахе легко работал с файлами больше свободной памяти
Создавал `своп` и работал
Неудобства были ТОЛЬКО при переходах в начало/конец текста
Мог подчитать блок с диска при выходе за границы экрана иногда
Запись файла при выходе - это конечно уже некий процесс, но он не частый, может и потерпеть

[Vitamin]

А какая операция в типичном текстовом редакторе выполняется чаще- навигация по тексту или редактирование в начале большого текста?

[jerri]

Vitamin, Редактирование в произвольном месте. не?

[Advertiser]

[Vitamin]

Vitamin, Редактирование в произвольном месте. не?

Самый тяжелый случай в плане переброса памяти- редактирование в начале большого текста.

[esl]

Самый тяжелый случай в плане переброса памяти- редактирование в начале большого текста.

для описываемой выше схемы - это вообще не играет роли где редактировать
локальное редактирование - всегда быстрое
а вот перемещение по тексту уже стоит, и тем больше чем дальше перемещение

[Vitamin]

для описываемой выше схемы - это вообще не играет роли где редактировать

Ага. Все одинаково тормозит

локальное редактирование - всегда быстрое

Что такое локальное редактирование и где оно медленное?

а вот перемещение по тексту уже стоит, и тем больше нм дальше перемещение

Ну да. В предлагаемой схеме перемещение по тексту будет стоить. В обычных редакторах- не стОит (тупо поиск следующего/предыдущего перевода строки).

[jerri]

Может есть еще у этого алгоритма "продолжение" про то как его расширить для редактирования файлов большего размера чем свободное пространство?

Для чего?
Зачем на машине с 16к свободной памяти редактировать тексты больше чем 16 к?