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

ВВ>>Собственно, я не понимаю почему бы gap buffer здесь не использовать.
VD>Я незнаю что такое "gap buffer".

Какое-то описание есть здесь. Причем это не самый эффективный алгоритм.

VD>С какой целью? Что есть какие-то проблемы при вводе? Зачем заниматься привентивными оптимизациями темболее когда уже видно что они ровным счетом ничего не дадут?

Меня тут больше потребление памяти занимает, чем скорость. Скорость по большому счету упирается в отрисовку.

ВВ>> и зачем их создавать если без этого можно обойтись.
VD>Есть такое понятие — дизайн приложения. Конечно все что угодно можно написать на уровне битов. Но на практике мало мальски серьезные приложения просто нвозможно создать без применения выскоуровневых абстракций.

Не, ну я же не против абстракций. Собственно, я вообще не пытаюсь критиковать реализацию. Я пытаюсь разобраться. И мне всегда казалось, что дизайн приложения не "измеряется" количеством созданных классов.
На самом деле я пытался въехать во что упирается работа с текстами только по-строчно. Ведь все-таки string[] — это скорее _представление_ данных, чем сам данные.

VD>Тот же механизм редактирования с поддержкой анду/реду является довольно сложным алгоритмом затрагивающим множество программных сущьностей. Для его упрощения был придуман паттерн команада и еще куца разной лабуды. Они делают реализацию в меру сложной (доступной для понимания простым смертным вроде меня). Без них же это просто не подемная задача. По крайней мере я не хочу решать эту задачу без них. Я вообще не получаю удовольствие от возни на уровне битов.

Да, согласен. Но чем gap buffer этому мешает?

VD>Ты лучше ответь на простой вопрос. При вводе текста ты ощущашь какой-то дискомфорт? Или видишь какой-то странный раост используемой памяти?

Скорость хорошая. Но она по большому счету не от этого зависит. Что такое создание одного объекта для перфоманса, даже тысячи.. А память
Как я уже говорил, я собственно не критикую и даже не предлагаю что-то переделывать. Мне интересно почему были выбраны именно такие решения при реализации, а не другие. В чем их бенефит и пр. И вот это мне пока непонятно.

VD>Что тут вообще нужно изучать? По-моему, все и без объяснения понятно. А учитывая, что каждый метод/свойство еще собжены коментариями...

Ну имелась в виду "полная" работа с редактором, включая работу со стилями и пр.

VD>Теперь о реализации. В Сцинтиле, точно так же как и в Rsdn.Editor применяются команды редактирования. Разница только в том, что у меня разные типы команд описываются разными классами и составляют иерархию:
VD>

VD>Command - абстрактный
VD>    MultiCommand
VD>    ModifyTextCommand - абстрактный
VD>        InsertCommand 
VD>        DeleteCommand
VD>        UpdateCommand
VD>

VD>в которой все конкретные (не абстрактные) классы реализуют ICommand.

А зачем?

VD>А в Сцинтиле все запихнуто в один класс и только во время исполнения можно понять с каким типом команды ты имешь дело.
VD>Причем в следствии того, что все запихнуто в один класс команды хранят избыточную информацию, а код работы с командами запутан.
VD>Сдается мне, что ты просто не разобрался в том как устроена Сцинтила, раз говоришь такие вщеи.

Да, да, ты прав. В сцинтилле все ужасно. Тем не мнее когда потребовалось сделать для нее раскраску нужно было разобраться со следующими функциями, что заняло минут 10-20:

SCI_GETENDSTYLED
SCI_STARTSTYLING(int position, int mask)
SCI_SETSTYLING(int length, int style)
SCI_SETSTYLINGEX(int length, const char *styles)
SCI_SETLINESTATE(int line, int value)
SCI_GETLINESTATE(int line)
SCI_GETMAXLINESTATE

А вот в работу со стилями у тебя я до сих пор до конца не въеду. Почем бы это? Может, последствия "тяжелых" новогодних праздников?

VD>Вот в создании лексера действительно на первый план выходит скорость и эффективность. Там действительно есть простор над битовыми манипуляциями. Можешь попытаться применить свои силы на этом поприще. Увидишь, что это отнюдь не так просто.

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