Хороший текстовый редактор должен быть полезен для всех видов работы программиста, которые могут выполнять, и включает в себя открытие файлов, размер которых иногда может составлять несколько гигабайт. Поэтому я бы не рекомендовал набор разума, где все должно быть буферизовано в ОЗУ.
Я бы рекомендовал создание дерева поиска кусочков, представляющих файл, где один срез может быть:
- Ссылка на диапазон байтов в фактическом файле на диске, или
- ссылку на отредактированную страницу.
Когда вы открываете файл, вы начинаете с вставки одного элемента в дерево, которое представляет собой просто диапазон, представляющий весь файл, например.для 10-MiB файла: с
std::map<size_t, slice_info> slices;
slices[0].size = 10*1024*1024;
Когда пользователь редактирует файл, создать «страницы», который некоторые разумные размеры, скажем, 4 KiB, вокруг точки редактирования. Дерево сплайсируется в этой точке. В примере, точка редактирования находится в 5 МиБе:
size_t const PAGE_SIZE = 4*1024;
slices[0].size = 5*1024*1024;
slices[5*1024*1024].size = PAGE_SIZE;
slices[5*1024*1024].buffer = create_buffer(file, 5*1024*1024, PAGE_SIZE);
slices[5*1024*1024 + PAGE_SIZE].size = 5*1024*1024 - PAGE_SIZE
Вы можете использовать отображаемые в память файлы как для только для чтения буфера (исходный файл) и для скопированных редактируемых буферов (последний будет помещена в каталоге temp). Это также позволяет восстановить, если редактор выйдет из строя.
Использование страниц фиксированного размера значительно сократит фрагментацию кучи памяти, поскольку все блоки имеют одинаковый размер, и вставка текста никогда не потребует перемещения более 4 килобайт данных перед вами.
Это упрощенное описание, чтобы дать общую идею, не вдаваясь в слишком много подробных подробностей. Реальная реализация, скорее всего, должна быть более сложной, например. позволяют переменному количеству данных на странице справляться со переполненными страницами и объединять множество небольших фрагментов, так что выполнение подстановки регулярного выражения в большом файле не создает слишком много небольших буферов. Вероятно, необходимо ограничить количество секций, которые вы должны иметь в дереве одновременно, но ключевым моментом является то, что когда вы начинаете вставлять туда, вы должны убедиться, что работаете с не слишком большим срезом.
Для регулярного выражения я не думаю, что производительность является большой проблемой, если весь редактор не зависает во время его запуска. Попробуйте Boost.Regex, он, скорее всего, будет достаточно быстрым для ваших нужд, и он также достаточно общий, чтобы подключить любую стратегию буферизации, в которой вы нуждаетесь.
То же самое относится к подсветке синтаксиса, если вы запустите его в фоновом режиме, это не повредит пользователю, пока он печатает. Вы можете использовать ломтик подход к Вашей выгоде здесь:
- Каждый ломтик может иметь мьютекс, который может быть заблокирован во время операции редактирования, что позволяет подсветку синтаксиса или анализа типа «IntelliSense» работать в фоновом потоке.
- Вы можете сохранить состояние механизма подсветки синтаксиса, чтобы всякий раз, когда вы делаете редактирование в срезе, вы можете перезапустить подсветку синтаксиса с начала этого фрагмента, а не с начала файла.
Мне не известны никакие автономные синтаксические механизмы подсветки, но они обычно основаны на подстановке регулярных выражений (см., Например, файлы подсветки синтаксиса в vim).
Удачи вам в этом, это невообразимо трудная задача. Помните, что если вы делаете клоун с функцией к функциям Vim, вы можете оказаться в психиатрическом учреждении! : wq –
Самый большой вопрос, почему вы это сделаете? vim имеет 30 лет интеллектуального капитала, вложенных в него, что вы можете сделать, чтобы конкурировать с этим? Если вам нужен другой тип редактора, это одна вещь, но переделать vim в значительной степени суждено потерпеть неудачу. (Извините, ненавижу быть негативным nancy) – Whaledawg
Я могу много написать об этом, но все сводится к тому, что Али и Уайладг уже сказал. Не делай этого. Если вы уже спрашиваете об этом, вы не собираетесь это делать. – Rook