о текстовых редакторах
Как сделать быстрый текстовый редактор?
Для начала поразмыслим, где именно может
тормозить editor?
Первая плохая вещь - вставка строки,
И по этому поводу мысль
Если просто сдвигать все строки после
вставляемой при помощи Ldir (или чего-
нибудь подобного), то время вставки бу-
дет пропорционально длине текста, Это
плохо, А для больших текстов - просто
ужасно, Можно избежать этого следующим
образом,
Отредактированную и введённую строку
помещаем в буфер, Это очень быстро,
Придется только написать программу,
которая будет маленькими кусочками пере-
писывать весь текст в памяти, Т,е,, до-
пустим у нас есть текст с адреса (услов-
но) О, длиной 1Окб, И мы уже успели от-
редактировать несколько строк и даже
ввести новых, Наша программаа начинает
переписывать текст, начиная с нулевого
адреса, по адресам с 1Окб и дальше, При
этом отредактированные строки не перепи-
сываются, а берутся из буфера, Ну и если
в данном месте мы ввели новую строку, то
она тоже вставляется из буфера, Если
строка была удалена - пропускаем, Таким
образом, после того как мы пройдем весь
старый вариант текста, с адреса 1Окб мы
получим новый вариант, в котором будут
отражены все изменения, 3а это время,
возможно, этот новый вариант тоже успеет
устареть, т,е, в буфере появятся новые
(отредактированные) варианты некоторых
строк, Ну и всё повторится - наша прога
продолжит работу, Считаем, что память
замкнута в кольцо, Вот,
Только придётся все прочие функции
поместить на im 2: курсор, вывод и ре-
дактирование строки, скроллер и всё та-
кое, И пускай при этом они занимают
столько времени, сколько им нужно, Пусть
даже и целиком несколько фреймов, Потому
что программе, которая будет заниматься
обновлением текста быстродействие не
нужно абсолютно, Весь текст может обнов-
лятся даже за несколько минут (хотя -
это вряд ли, скорее всего, самое большее
- она будет работать несколько секунд),
Главное подобрать размер буфера, чтобы
за то время, пока обновляется текст, он
не успевал бы переполняться,
Всё, От размера текста скорость встав-
ки больше не зависит,
Ну, мысли эти, наверное, не новы, но -
именно так : буфер для строк, а не для
букв при опросе клавиатуры - по-моему
никто на спеке не делал, В любом слу-
чае, моя цель не открытия делать - а,,,
эээ,, опытом поделиться, Причём личным,
Вот,
Ну ладно, Это всё хорошо, но есть и
минусы, Во-первых, нужна память под бу-
фер, Я думаю, 1-2kb будет предостаточно,
Во-вторых, потребуется на каждую строку
израсходовать лишних три байта, Это ад-
рес строки (2) и её длина (1), Придётся
организовать табличку с этими данными и
при вставке/удалении строк оперировать
именно с ней, Зато операции
перемещения/копирования/удаления группы
строк будут просто реактивными, так как
сведутся к работе с этой табличкой, Но -
самое плохое, что придётся ограничить
суммарное количество строк в тексте,
Адреса в таблице будут в общем случае
идти не друг за другом, Какие-то указа-
тели будут указывать на буфер, При уда-
лении и копировании строк в памяти будут
образовываться дырки, Но все эти неп-
риятности будет устранять прога обновле-
ния текста,
Памяти, конечно, жалко, Но лично для
меня быстродействие стоит на первом мес-
те, Тем более, что текстов длиной больше
чем 3О кб я в своей жизни ещё не писал,
Вот, Первую плохую вещь, кажется, обош-
ли, Осталась вещь вторая, совершенно
отвратительная - форматирование текста,
Ну и, соответственно, мысль
Алгоритм форматирование я представляю
следующим образом, Берём слово из нефор-
матированного текста, Смотрим, влезает
ли оно в текущую строку, Если влезает,
берём следующее, Если не влезает пытаем-
ся его переносить, Тут, как ни придумы-
вал, у меня получалось два прохода по
слову:
1) Расстановка переносов в слове,
Т,е,, фактически, пометка букв на кото-
рых слово можно оборвать;
2) Просмотр слова по слогам, Аналогич-
но словам: влезает в строку - печатаем,
не влезает - закрываем текущую строку и
начинаем новую,
Вот то, что записано в пункте 1 можно
выполнять на этапе вставки строки в бу-
фер, Для одной строки это по любому бу-
дет занимать немного времени, А в итоге,
при форматировании, для всего текста это
даст существенный выйгрыш в скорости,
Кроме того, при форматировании нам ещё
необходимо выделить в строке собственно
слова - это тоже не так просто, И это
можно сделать при вставке строки в буфер
(при нажатии enter, т,е,),
Вобщем половину всей работы форматилки
можно выполнить незаметно, в процессе
редактирования текста, И этим нужно
пользоваться,
Ну, опять же, это скажется (незначи-
тельно) на расходе памяти,
Как это можно сделать конкретно, Весь
текст сгруппируем по словам, Каждому
слову припишем атрибуты (1-2 байта), в
которых пропишем количество пробелов пе-
ред словом, длину слова, управляющие ко-
ды перед словом и наличие управляющих
кодов в самом слове, Последнее, конечно,
не принципиально, но так же даёт выйгрыш
в скорости - можно отдельно рассматри-
вать слова, в которых присутствуют упр,
коды и слова, в которых они не присут-
ствуют, В 99% слов они не присутствуют,
т,е, цвет, шрифт и т,д, меняется между
словами, а не в них, Вот,
Ну и ещё, сделаем наш шрифт, состоящим
из 128 символов, а не из 256, Переключе-
ние между рус/лат шрифтами придётся
оформлять управляющим кодами, Зато 7ой
бит буквы можем использовать для пометки
допустимости постановки переноса после
данной буквы,
Всё,
Минусы: кодирование/декодирование
(т,е, торможение) при записи/чтении
обычных текстов,
Вот и всё, что я хотел сказать по по-
воду текстовых редакторов,
Одним из моих незаконченных проектиков
как раз и является техт editor, Я смог
реализовать всё, вроде бы, из вышепере-
численного, Но не написал собственно
форматирования текста, Ну и почему-то
работа затормозилась и сейчас движется
крайне вяло, Впрочем, какую-нибудь
aLfa-версию я, наверное, к зиме выпущу,
Вот,
Other articles: