Здравствуйте, alsemm, Вы писали:

A>У тебя сейчас, если я ничего не путаю, так:
A>

A>class Document
A>{
A>    string[] lines;
A>public:
A>    string getLine(int idx) { return lines[idx]; }
A>};
A>

A>Такое решние дает очень эффективную реализацию Document::getLine. В минусе то, что время выполнения вставки/удаления строки не const и растет с увеличением количества элементов в массиве lines[].

Нет. Строки это наследники класса DocumentRow. В документе они хранятся в коллекции DocumentRowCollection. DocumentRowCollection внутри себя хранит динамический массив DocumentRow (List<DocumentRow>).

A>Этот специальный класс (Document, если ничего не путаю) инкапсулирует string[], так? Я об этом писал.

Не так, как видишь. И об этом рассказано в стаье.

Что касается скорости, то дабавление или удаление даже в огромных текствых файлах (3 метра и больше) занимает меньше 1% времени вставки. И вообще вставка небольшого кличества строк в любую точку документа для пользователя незаметна (выглядит как ралтаймная операция).

В свое время я задумался не будет ли тормозить List<T> в качестве основы для коллекции строк. Думал, а не использовать ли BigList<T> из PowerCollections. Но тесты показали, что в самом большом текстовом файле который я смог найти на своей машине (около 3 метров) List<T> вел себя даже лучше чем BigList<T>.

A>Тебя в сцинтиле все устраивает? Видимо нет, раз взялся за свой редактор. А почему сцинтилу не стал "подкручивать"?

Потому что в Сцинтиле был ряд проблем устранение которых практически невозможно. Вот они:
1. Сцинтила написана на С++ причем в такой манере, что ее практически невозможно переписать на МС++. А редактор нужно использовать в управляемых приложениях. Неуправляемый С++-код в таких условиях приводит к ряду проблем (от плохой интерграции и траты ресурсов, до невозможности запуска прилоежния в 64-битном окружении).
2. Стили в Сцинтиле наначаются битами. Это очень неудобно для моих потребностей.
3. Сцинтила трудно поддается рефакторингу. Опять же С++-ный код для которого нет человеческих средств автоматизированного рефакторинга. Плюс написана она кривовато.
4. Сцинтила не юникодная. Возня с UTF-8 и т.п. сильно задалбывает.

Плюс было интересно написать аналог Сцинтилы на управляемом языке чтобы было можно сравнивать результат.

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

A> IMHO потому что, разбираться в чужом коде радость та еще. Ты идешь по тому же пути — захотят расширения делать, пусть правят код, а не плагин пишут.
A>Плагины и открытый код вещи не взаимоисключающие.

Мы, в свое время, пытались делать плагины-интерфейсы к Хоуму. Потом отказались, так как смысла это не имело. Намного проще и эффектинвее просто развивать проект.

A>Уже были вроде посты про то, что писать свой стайлер для твоего редактора пока не очень удобно.

Да, это так. Но проблема тут в том, что именно вопрос со стайлером и вообще форматером банально плохо проработан. Когда доведем его до ума, то и вопросов не возникнет. Нет же вопросов по работе с клавиатурой?

A>...
VD>>И как это поможет тебе с рисованием той же рамки?
A>Так же как с фонтом.

То есть ручками рисовать конкурируя с основным кодом? Мне это не нравится.

A>Я код написал чтоб принцип был понятен. На самом деле на каждый токен фонт рожать не надо, заводим в FontChangeDecorator std::map<HFONT, HFONT>, где ключи — шрифты от
A> существующего декоратора, а зчачения — новые, увеличенные и все дела.

ОК, согласен. Производительность можно поднять. Но иделогических проблем это не снимает.

VD>>А как на счет рассчета переноса строк? Забить на него? Лично я против. Мне нужен удобный в использовании редактор, а не набор компромисов.
A>Все считается и перенос строк и прокрутка. Не в лоб конечно, но и каши в коде нет. Кстати, у тебя можно иметь строки разной высоты? Например, если в одной строке шрифт высотой 10, а в другой 20, то они будут 10 и 20 или обе по 20 высотой? У меня можна

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

Так что разная высота строк это самое простое.

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

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

A>Я не навязываю свое решение, просто озвучил свой взгляд на задачу раскраски текста. Чем плохо на проблему с разных сторон посмотреть?

Разные мнения и решения всегда полезны. Просто так же как ты имешь право высказать свое мнение, я имею право с ним не согласиться.

Полезны же здесь аргументы. Ведь они наталкивают на мысли. Да и несогласие при некотором количестве качественных аргументов может превратиться в согласие.

VD>>Мне нужна простота, ясность и скорость.
A>Сколько методов нужно реализовать юзеру чтобы написать свой стайлер? В IDecorator-е он всего один

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