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

[Vitamin]

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

Откуда тормоза? От копирования 65 символов?

[vinxru]

Откуда тормоза? От копирования 65 символов?

А если я перемещусь в конец текста и там нажму кнопку?

[Vitamin]

А если я перемещусь в конец текста и там нажму кнопку?

Какая разница куда переместишься? Для заполнения буфера достаточно два указателя- на начало текущей строки (он всегда есть) и на начало следующей (он тоже вычисляется для перемещения). А где эти указатели (в начале, в середине, в конце) - глубоко пофиг.

[Barmaley_m]

Текст до курсора - от начала памяти и до курсора
Текст после курсора в конце памяти
Т.е свободное место в середине
При перемещении курсора - перемещаем строки в памяти

Да это же гениальная идея! Просто в реализации, мало накладных расходов по памяти и практически всегда не тормозит на текстах любых размеров. Я когда-то пытался сделать для Speccy редактор и тоже думал над этой проблемой, но к такому красивому решению не пришел. Спасибо!

К слову о связных списках: подобный подход, по-моему, применяется в редакторе Far. Он позволяет иметь строки произвольного размера и/или редактировать большие файлы.

[bigral]

Он позволяет иметь строки произвольного размера и/или редактировать большие файлы.

Вот тут не понял. Собственно про это уже спросил 2 раза но внятно никто не ответил как это сделать.

Детально можно описать алгоритм как отредактированный кусок текста из памяти "вклеится" в то "окно" которое занимал старый текст (отредактированный текст может быть длинее или короче)?

По-моему возникает проблема аналогичная той ситуации что возникает в памяти редактора с "классическим" подходом, нужно вычислить размер нового текста и передвинуть остаток файла вперед или назад а потом вписать содержимое памяти в "подогнанное" окно на диске (довольно муторная и дорогая операция по-моему, особенно с такой файловой системой как в TR-DOS).

[esl]

3. По поводу БОЛЬШИХ файлов я так и не понял что с ними делать, вот у меня есть логи на работе размерами по 1GB ни один из редакторов под linux c ними нормально не работает (помнится под DOS были редакторы которые и по 10Mb логи смотрели без проблем). Это конечно другая задача НО все же, как создать swap file и как его использовать эфективно?

это можно пременить к большим файлам, но смысла нет,
эт скорее схема для экономии памяти

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

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

[vinxru]

Вот тут не понял. Собственно про это уже спросил 2 раза но внятно никто не ответил как это сделать.

Детально можно описать алгоритм как отредактированный кусок текста из памяти "вклеится" в то "окно" которое занимал старый текст (отредактированный текст может быть длинее или короче)?

По-моему возникает проблема аналогичная той ситуации что возникает в памяти редактора с "классическим" подходом, нужно вычислить размер нового текста и передвинуть остаток файла вперед или назад а потом вписать содержимое памяти в "подогнанное" окно на диске (довольно муторная и дорогая операция по-моему, особенно с такой файловой системой как в TR-DOS).

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

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

---------- Post added at 19:17 ---------- Previous post was at 19:13 ----------

А алгоритм получается простой. Перерисовка экрана происходит от положения курсора вверх и вниз. Если при перерисовке мы достигаем конца ОЗУ, то есть еще не всё нарисовали, а данные кончились, значит надо младшие 16 Кб скинуть на диск (или сколько там получилось после редактирования), переместить оставшиеся 16 Кб в начало и загрузить в конец следующие 16 Кб из файла.

[Barmaley_m]

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

Почему же? Идея вполне имеет право на существование. Логи разные бывают. Например, если софт, который сохраняет логи, содержит баг, что приводит к нечитаемости логов другим софтом. С помощью редактора иногда можно подправить лог, чтобы он читался как надо. Когда пишешь и отлаживаешь свою программу, сохраняющую логи, такая ситуация может встречаться часто.

Ну и потом, что гигабайты на современных компах - то сотни килобайт на Speccy. Подход тот же самый. Прочитать или записать 300кБ с дискеты занимает примерно то же время, а в стандартную память такой файл не влезает.

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

[esl]

Почему же? Идея вполне имеет право на существование. Логи разные бывают. Например, если софт, который сохраняет логи, содержит баг, что приводит к нечитаемости логов другим софтом. С помощью редактора иногда можно подправить лог, чтобы он читался как надо. Когда пишешь и отлаживаешь свою программу, сохраняющую логи, такая ситуация может встречаться часто.

не, эт неправильно, логи парсить надо не редакторм а скриптом на ruby/perl/python
они на это заточены, и ворочают ими с сумашедшими скоростями
сколько раз уж делал такие "фиксеры"

java мир ух как любит многопоточные логи ....

[Barmaley_m]

Придумал, как редактировать большие файлы.

Для этого требуется не один, а два своп-файла. Их совокупный размер может вырасти вплоть до размеров оригинального файла минус объем доступной в качестве буфера оперативной памяти, так что если имеется дискета на 800кБ - то на ней можно будет редактировать файлы до ~400кБ размера, если хранить своп-файл на ней же.

Сначала в оперативку загружается часть оригинального файла - по доступному размеру буфера, но оставляя некоторое место для текущих вставок. При выходе курсора за пределы этой области отредактированный текст сохраняется на диск в первый своп-файл, а данные подгружаются в память из оригинального файла. Таким образом, при далеких перемещениях курсора только в направлении конца текста (и малых - в локальной области в любом направлении) когда курсор окажется в конце текста, в своп-файле окажется почти полная отредактированная копия исходного файла. Если теперь переместить курсор далеко назад, за пределы находящегося в памяти куска - то информация с конца текста начинает записываться во второй своп-файл, задом наперед - потому что файлы могут расти или обрезаться только с конца. В освободившуюся память подгружаются данные из первого своп-файла, и редактирование продолжается. При перемещениях курсора за пределы "окна ОЗУ" информация из начала или конца ОЗУ-буфера дописывается в один из своп-файлов, в освободившуюся память подгружаются данные из другого своп-файла, и один из своп-файлов обрезается с конца.

По окончании редактирования в конец первого своп-файла дописываются весь текст из ОЗУ-буфера, после этого все содержимое второго своп-файла дописывается к первому своп-файлу задом наперед. После этого первый своп-файл содержит полный вариант отредактированного текста, второй своп-файл пуст. Он удаляется, удаляется также оригинальный файл, а первый своп-файл переименовывается под имя оригинального файла. Если оригинал и своп-файлы хранились на разных дисках - то процедура немного отличается, но суть, надеюсь, ясна.

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

---------- Post added at 20:01 ---------- Previous post was at 19:58 ----------

не, эт неправильно, логи парсить надо не редакторм а скриптом на ruby/perl/python

Если изменения большие - то можно скриптом, а если небольшие - то сойдет и редактор. Это быстрее, чем писать и отлаживать скрипт. Я часто этим занимался по работе (патчил логи), правда, от их размера редактор (Far) не усирался.

А MIM - это очень мощный редактор. На нем я набирал и редактировал свой диплом, хотя на дворе был уже 2000й год, и мне тогда были доступны редакторы на PC (Far, Word и др.). Тем не менее по совокупности критериев был выбран MIM как наиболее удобный и экономящий время/усилия.