Да это же гениальная идея! Просто в реализации, мало накладных расходов по памяти и практически всегда не тормозит на текстах любых размеров. Я когда-то пытался сделать для Speccy редактор и тоже думал над этой проблемой, но к такому красивому решению не пришел. Спасибо!
К слову о связных списках: подобный подход, по-моему, применяется в редакторе Far. Он позволяет иметь строки произвольного размера и/или редактировать большие файлы.
Вот тут не понял. Собственно про это уже спросил 2 раза но внятно никто не ответил как это сделать.
Детально можно описать алгоритм как отредактированный кусок текста из памяти "вклеится" в то "окно" которое занимал старый текст (отредактированный текст может быть длинее или короче)?
По-моему возникает проблема аналогичная той ситуации что возникает в памяти редактора с "классическим" подходом, нужно вычислить размер нового текста и передвинуть остаток файла вперед или назад а потом вписать содержимое памяти в "подогнанное" окно на диске (довольно муторная и дорогая операция по-моему, особенно с такой файловой системой как в TR-DOS).
это можно пременить к большим файлам, но смысла нет,
эт скорее схема для экономии памяти
но все-же,
собственно этому методу в памяти "нужно" держать только то что сейчас на экране
все что вне экрана спокойно может быть в "свопе"
и догружаться в память по надобности.
а гигабайтный логи в редактор грузить - имхо изврат редкий
их же не нужно редактировать, их нужно смотреть, другая задача ...
Последний раз редактировалось esl; 02.04.2013 в 19:17.
Дак правильно говоришь. Загружаем в память кусок файла размером в 32 Кб, после редактирования он у нас изменяет свой размер. Дальше нам надо сдвинуть весь файл, что бы сохранить этот блок.
Этого не избежать, в любом случае придется сдвигать байты на диске. Хоть ты весь файл в оперативку загрузи.
---------- Post added at 19:17 ---------- Previous post was at 19:13 ----------
А алгоритм получается простой. Перерисовка экрана происходит от положения курсора вверх и вниз. Если при перерисовке мы достигаем конца ОЗУ, то есть еще не всё нарисовали, а данные кончились, значит надо младшие 16 Кб скинуть на диск (или сколько там получилось после редактирования), переместить оставшиеся 16 Кб в начало и загрузить в конец следующие 16 Кб из файла.
Почему же? Идея вполне имеет право на существование. Логи разные бывают. Например, если софт, который сохраняет логи, содержит баг, что приводит к нечитаемости логов другим софтом. С помощью редактора иногда можно подправить лог, чтобы он читался как надо. Когда пишешь и отлаживаешь свою программу, сохраняющую логи, такая ситуация может встречаться часто.
Ну и потом, что гигабайты на современных компах - то сотни килобайт на Speccy. Подход тот же самый. Прочитать или записать 300кБ с дискеты занимает примерно то же время, а в стандартную память такой файл не влезает.
Как приспособить эту схему к редактированию файлов, которые не влезают в память - пока не могу придумать. Но для работы с файлами в памяти она подходит очень хорошо.
Придумал, как редактировать большие файлы.
Для этого требуется не один, а два своп-файла. Их совокупный размер может вырасти вплоть до размеров оригинального файла минус объем доступной в качестве буфера оперативной памяти, так что если имеется дискета на 800кБ - то на ней можно будет редактировать файлы до ~400кБ размера, если хранить своп-файл на ней же.
Сначала в оперативку загружается часть оригинального файла - по доступному размеру буфера, но оставляя некоторое место для текущих вставок. При выходе курсора за пределы этой области отредактированный текст сохраняется на диск в первый своп-файл, а данные подгружаются в память из оригинального файла. Таким образом, при далеких перемещениях курсора только в направлении конца текста (и малых - в локальной области в любом направлении) когда курсор окажется в конце текста, в своп-файле окажется почти полная отредактированная копия исходного файла. Если теперь переместить курсор далеко назад, за пределы находящегося в памяти куска - то информация с конца текста начинает записываться во второй своп-файл, задом наперед - потому что файлы могут расти или обрезаться только с конца. В освободившуюся память подгружаются данные из первого своп-файла, и редактирование продолжается. При перемещениях курсора за пределы "окна ОЗУ" информация из начала или конца ОЗУ-буфера дописывается в один из своп-файлов, в освободившуюся память подгружаются данные из другого своп-файла, и один из своп-файлов обрезается с конца.
По окончании редактирования в конец первого своп-файла дописываются весь текст из ОЗУ-буфера, после этого все содержимое второго своп-файла дописывается к первому своп-файлу задом наперед. После этого первый своп-файл содержит полный вариант отредактированного текста, второй своп-файл пуст. Он удаляется, удаляется также оригинальный файл, а первый своп-файл переименовывается под имя оригинального файла. Если оригинал и своп-файлы хранились на разных дисках - то процедура немного отличается, но суть, надеюсь, ясна.
Очень эффективно. При таком подходе копирование больших кусков данных на диске сводится к минимуму.
---------- Post added at 20:01 ---------- Previous post was at 19:58 ----------
Если изменения большие - то можно скриптом, а если небольшие - то сойдет и редактор. Это быстрее, чем писать и отлаживать скрипт. Я часто этим занимался по работе (патчил логи), правда, от их размера редактор (Far) не усирался.
А MIM - это очень мощный редактор. На нем я набирал и редактировал свой диплом, хотя на дворе был уже 2000й год, и мне тогда были доступны редакторы на PC (Far, Word и др.). Тем не менее по совокупности критериев был выбран MIM как наиболее удобный и экономящий время/усилия.
Последний раз редактировалось Barmaley_m; 02.04.2013 в 21:05. Причина: исправил ошибки в тексте
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)