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

[esl]

Тормоза будут не такие и больше.

Переместить 36 Кб текста в памяти, а это как раз оперативка Специалиста, будет быстрее, чем перерисовать экран размером в 12 Кб шрифтом в 6 пикселей. То есть шрифтнадо двигать и AND+OR накладывать на экран.

эт понятно
в таком случае можно выводить построчно, и проверять, не надо ли еще скролить (и если надо - не обновлять что осталось)
скорость реакции будет заметно выше, а "временный бред" на экране - терпимо

так было на Корвете в ChiWorker сделано.

[Advertiser]

[Hacker VBI]

А если работать с буффером? и обрабатывать блоки при выходе курсора за его пределы?

[ram_scan]

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

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

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

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

[bigral]

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

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

[esl]

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

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

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

[jerri]

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

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

[esl]

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

в случае если редактор ТОЛЬКО для конкретной машины/случая - може и не стоит
но MIM был (и использовался для работы с БОЛЬШИМИ текстами)
на Ямахе/Корвете/УКНЦ/СМхх
у нас преподы набирали методички в нем, и очень ценили что есть ОДИН файл а не кучка.

хотя это вопрос привычки конечно

в том-же мим очень не привычная для большинства схема копирования/вставки, отдельные буфера для "символов"/"строк"/"кадратных блоков"

при этом уже тогда (1988 как минимум)
было Undo/Redo
Квадратные блоки
"бесконечный" текст
"псевдо директории"

[vinxru]

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

[Vitamin]

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

[jerri]

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