Как организовать память для текстового редактора?

[Vitamin]

а с того что надо что надо спросить у пользователя что искать, etc, etc,
есть дополнительное взаимодействие ...

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

есть указатель на "Курсор"
в него поместили байт
увеличели X и указатель
все

У тебя редактируются строки из одного символа?

[esl]

Вообще-то те алгоритмы что доступны для 8bit процов спокойно могут быть реализованны практически на ВСЕХ компах.

просто сейчас это уже не имеет такого смысла
когда размер сектора на диске 8к
и сейчас быстрее/надежнее сделать на хорошо известных структурах
редактор это в жизни много больше чем просто набор текста
и сложные структуры дают свои огромные плюсы.

Одним блоком желательно иметь ВСЕГДА И ВЕЗДЕ и любые данные. К тому же описанный метод своего рода "замена" классических одно-двухсвязных списков которая даст им фору по памяти и по сложности обслуживающих алгоритмов.

я вообще в курсе, зачем и описал тут этот метод

---------- Post added at 21:50 ---------- Previous post was at 21:47 ----------

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

Т.е. начинаем искать в хвостовой части текста, как только нашли, все от начала хвоста до позиции поиска надо перекинуть.

заметные, заметные, процесс то интерактивный
отрисовать диалог, спросить, отреагировать на результат поиска

зачем тягать при поиске ????
только когда нашли и надо отрисовать

У тебя редактируются строки из одного символа?

нет конечно, но метод позволяет не использовать дополнительный буфер для редактирования строки
правее курсора - свободное место

[Vitamin]

зачем тягать при поиске ????
только когда нашли и надо отрисовать

А я что написал?

как только нашли, все от начала хвоста до позиции поиска надо перекинуть.

нет конечно, но метод позволяет не использовать дополнительный буфер для редактирования строки
правее курсора - свободное место

И сколько таки нужно операций для редактирования строки размером в N символов?

Напиши прототип. Увидишь и плюсы и минусы, может идеи какие гениальные придут. На форуме обсасывать можно до бесконечности.

[esl]

Напиши прототип. Увидишь и плюсы и минусы, может идеи какие гениальные придут. На форуме обсасывать можно до бесконечности.

гм, я начал с того что сказал что работал с редакторами которые по этой схеме были сделаны
так что в отличии от есть некий опыт

[Vitamin]

гм, я начал с того что сказал что работал с редакторами которые по этой схеме были сделаны
так что в отличии от есть некий опыт

Бгг. Почему-то думал, что ты топикстартер

[esl]

Бгг. Почему-то думал, что ты топикстартер

Топикастер VINXRU- маг и волшебник кода и паяльника

[Advertiser]

[alone]

Home | O(1) | O(M) | O(1) End | O(N*K) | O(M) | O(1) LineUp | O(N) | O(N) | O(1) LineDn | O(N) | O(N) | O(1) PgUp | O(N*K) | O(N*K) | O(K) PgDn | O(N*K) | O(N*K) | O(K) Edit | O(M+N) | O(N) | O(N)

Home, End, PgUp и PgDn везде как минимум O(N*K), потому что надо перепечатать весь экран.
LineUp и LineDn на границе экрана требуют сдвига и вывода новой строки, так что оценка O(1) не имеет смысла.

[Vitamin]

Home, End, PgUp и PgDn везде как минимум O(N*K), потому что надо перепечатать весь экран.
LineUp и LineDn на границе экрана требуют сдвига и вывода новой строки, так что оценка O(1) не имеет смысла.

Перепечатка экрана- отдельная тема. Оценка исключительно для операций над текстом.

[vinxru]

Вчера ночью набросал первую версию программы, что бы оценить скорость. Скорость удовлетворительная. Реакция на Enter и Backspace (в начале строки) быстрее, чем я обычно печатаю.

[vinxru]

Добавил строку состояния. Обновление чисел в строке состояния происходит при каждом нажатии клавиши (деление 16 битного числа и рисование), при этом тормозов так же нет.