proposal for new action app_proc(PROC_SET_EVENTS_EX, text)

[Alexey-T]

param 'text' of this new action will be totally different than in PROC_SET_EVENTS. it must contain pairs "some_key=some_value" separated by ';'.

possible keys:

• 'module=cuda_xxx' - sets internal field for the module name. next (un)subscribing will use that field.
• 'lex=Name1,Name2,Name3' - sets internal field for comma-separated lexers list, next subscribing will use that field.
• 'filter=value1,value2,value3' - sets internal field for event-filter(s), comma-separated; next subscribing will use that field.
• 'unsub_all' w/o '=' - unsubscribes module from all events.
• 'unsub=on_xxxx' - unsubscribes module from single event. ignores previously set fields 'lex' and 'filter'.
• 'sub=on_xxx' - subscribes module to single event, uses previously set fields 'lex' and 'filter'. event name can be with '~' and '+' suffixes, like in install.inf.

@badrelmers

[badrelmers]

• unsub and sub are very welcome, does it solve this also? PROC_SET_EVENTS should not reset the old events

• filter i think should be filter=event1:value1,event2:value2,event3:value3 to solve this https://github.com/Alexey-T/CudaText/issues/6142#issuecomment-3619389667 otherwise in the future if we add more filters it will be error prone if filters names conflicts, for example if a lexer is called mystring and a filter is called mystring then the api will have to be fixed in the future, it is better to fix it now i think.

[Alexey-T]

the design on that API action was bad. new proposal is:

1. PROC_EVENTS_SUB: Subscribes to event(s). First unsubscribes only from specified events, for all combinations of lexers/filters for these events. Param "text" must be 4 values ";"-separated: "module_name;event_list;lexer_list;filter".
2. PROC_EVENTS_UNSUB: Unsubscrines from event(s). Param "text" must be 2 values ";"-separated: "module_name;event_list". If event_list is one symbol "*" - unsubscribes from all events for that module.

later, when we make sure these 2 actions work ok, maybe will add more:

3. PROC_EVENTS_ENUM: Enumerates info about all events for specified module, or for all modules (will think later). Return format - will be designed later, maybe it will be the 'same' as info lays in the memory, ie corresponding to Pascal lists.

[badrelmers]

this is very nice and promising, i m ready if you need any testing

[Alexey-T]

I want to work on this, maybe this or next week.

meanwhile. I asked several mate programmers about help for new idea of Py plugin. they all busy. copy/paste:

Details

Idea of new plugin is - alternative to FindInFiles4 plugin, more simple, more useful for complex searches.

• show dlg similar to SynWrite's FindInFiles
• it must write all search-results to the Cud's bottom-panel (and handle double click there)
• it must show dlg NON-modal way
• it must handle search NOT via Python but via finder_proc(). it loads file to hidden Editor object via Editor.load(), then searches there using finder_proc(), then (if replace needed) saves via Editor.save().

are you interested to help?

[badrelmers]

i already made something similar to that, i was going to tell about it to publish it but i did not find time to finish it, it is still in alpha and i did not finish all the options but the important things are already done. i make it because FindInFiles4 make cudatext freeze/hangs and it is so slow, so this is what a fixed first, i used threading so cudatext never hangs, and instead of searching with python i used ripgrep , vscode builtin search use ripgrep too, it is hyper super fast, and allow to use pcre2 regex

this is the first plugin a made, so i need to revise it again because i learned a lot of things after making this

i had problems with cudatext api , it does not run from a thread, but i fixed it thanks to God by running the api in the main thread and doing everything else from the thread, this is what solved the cudatext hangs

things from your requirements that i already made are:

• it must write all search-results to the Cud's bottom-panel (and handle double click there)
• it must show dlg NON-modal way

it also have a left side panel similar to vscode it can also search on multiple folders at the same time

i plan to add (TODO):

• multitab search, every search is done in a seperate tab inside the bellow panel
• search on search result
• add search and replace , but ripgrep do not support this, i have to find a solution!

do not test this options, some of them are not finished yet

but the default search works fine currently, so you can test its potential now

if you like it tell me and i will finish it if God will.

cuda_badr_search_ripgrep.zip

you have to have ripgrep in path

[badrelmers]

here is the ripgrep version i used or download it from its github ripgrep.zip

[Alexey-T]

I like it. Lets finish this plugin. After that i will test it.

[badrelmers]

ok, once i finish sync edit plugin i start with this

[Alexey-T]

first iteration: PROC_EVENTS_SUB, PROC_EVENTS_UNSUB.

• get updated 'cudatext.py' from this github
• beta win64:

cudatext.zip

ps. UNSUB action must unsub totally - whenether event is from app_proc, from install.inf, from plugins.ini.

[badrelmers]

it works perfectly as expected and as described in the api, PROC_EVENTS_SUB, PROC_EVENTS_UNSUB and the new sel/selreset for on_caret_slow. great job.

i think this api needs nothing more. i hope you will have time to implement PROC_EVENTS_ENUM too

thank you very very much!