CudaText: Вопрос о внутренней логике выделения текста

[tiun]

Тема сформулирована неудачно, но вписать правильную формулировку помешало ограничение на её длину.
А вопрос такой:

Позволяет ли в принципе внутренняя логика обращения CudaText с выделенным текстом реализовать примерно такой режим, какой был во многих редакторах во времена MS-DOS (например, с системой команд WordStar):
1. Даём команду "Здесь начало выделения".
2. Произвольно перемещаемся по тексту (в том числе и редактируя его).
3. Даём команду "Здесь конец выделения".
4. Произвольно перемещаемся по тексту (в том числе и редактируя его) - при этом выделение не сбрасывается.

[uvviewsoft]

выделение - это просто каретка с 4мя числами. каретка без выделения - с 2мя.
значит при перемещении по тексту мы меняем поз.каретки, и те 4 числа в ней уже пропадут.
простой клик сделает single caret и сбросит 4 числа (с выделением) в 2 новые.

[uvviewsoft]

можно сделать такой хак. ставить 2 маркера https://wiki.freepascal.org/CudaText#Markers / которые бы "для вас значили что тут некий блок".
plugin API дает делать с маркерами +текстом что хочешь.

[tiun]

Немного поизучал API, и возникло несколько вопросов:

1. Я правильно понял, что если я хочу использовать выделения трёх разных типов, то мне нужно будет самостоятельно выбрать 3 числа, которые буду использовать в качестве тегов маркеров, и надеяться, что никаким чужим кодом такие же номера не будут задействованы? Или есть какой-то способ получать номера, которые гарантированно будут уникальны в течение сеанса работы?

2. Судя по наскоро прочитанному, предложенный Вами метод позволит получить практически всё, что мне хотелось бы, кроме одного, но это "одно" убивает всю затею: если какой-то чужой но нужный мне плагин работает с выделенным текстом, то в момент его вызова нужно будет превратить мои маркеры в стандартное выделение, но никакого способа перехватить вызов плагина, чтобы произвести такую подмену, в API нет. Или всё же в процесс запуска плагина как-то можно вклиниться?

[uvviewsoft]

1. правильно, надо выбрать 3 числа.
Надо бы мне уже записать в вики занятые числа
2. можно вклиниться. плагин вызывается по событию on_nnnnnn. можете в install.inf прописать это событие с приритетом.
https://wiki.freepascal.org/CudaText_AP ... s_priority

[uvviewsoft]

Обновил еще раз бету. http://uvviewsoft.com/c/
API версия 357.
сделал получение уникального tag.

>>> app_proc(PROC_GET_UNIQUE_TAG,'')
101
>>> app_proc(PROC_GET_UNIQUE_TAG,'')
102
>>> app_proc(PROC_GET_UNIQUE_TAG,'')
103

[tiun]

можно вклиниться. плагин вызывается по событию on_nnnnnn. можете в install.inf прописать это событие с приритетом.

Но тогда сразу две очевидные проблемы:

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

2. В моём текущем представлении последовательность действий должна быть такой: сначала отрабатывает мой обработчик (как более приоритетный) и переводит "маркерное выделение" в обычное, потом начинает работать сторонний обработчик - и на этом всё. Обратное преобразование выделения в "маркерное" после работы стороннего плагина я не предполагаю, ведь этот плагин может и выделение сбросить, и текст существенно перелопатить. Поэтому до этого плагина не просто выделение преобразуется, но ещё и маркеры удаляются.
А перехватываемые события происходят независимо от того, установлен в редакторе тот сторонний плагин или нет. И если нет, то моя система каждый раз будет понапрасну проделывать свои манипуляции с выделениями. И не просто понапрасну, а ещё и терять свои выделения!


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

[uvviewsoft]

подумал про это и думаю второй вариант и нужен.
--или предусмотреть явную команду преобразования в обычное выделение и вызывать её вручную по необходимости.

можно и так - вы не конвертите в обычное. а просто даете команды "copy мое выделение", "cut мое выделение" которые сами все сделают без делания каретки.

еще есть такое АПИ Editor.attr() для делания аттрибутов- вы можете как то его заюзать, не уверен только что эти цветовые аттрибуты будут работать быстро когда их много. то есть вы можете класть эти аттрибуты на "ваше выделение" (много атрибутов если много строк выделено).

[uvviewsoft]

можно еще добавить красоты если подсветить "ваше выделение" (только целые строки).

[tiun]

По изучении документации, без экспериментов, я предполагал использовать или атрибут "line_len" у маркеров, или set_prop(PROP_MARKED_RANGE, ...).

не уверен только что эти цветовые аттрибуты будут работать быстро когда их много

А что, цветовое подкрашивание при нынешнем прямоугольном выделении работает быстрее?