Cudatext: 'Select all' don't work with "Hi" option in Find dialog [1.133.6.1]

[JairoMartinezA]

[Alexey-T]

Also the find-next don’t work.. it is by design, Hi mode performs internal find-first call which makes its selection.
I should disable
Find-prev
Find-next
Select-all
with Hi option on.

[JairoMartinezA]

Hi Alex,

I think the two features "Hi" and "Selects" don't need to be mutually exclusive IMHO, what you think @xcme, @halfbrained?

[xcme]

Also the find-next don’t work.. it is by design, Hi mode performs internal find-first call which makes its selection.

Do you mean in latest beta, after changing the logic according #3422 and #3385)? It works in 1.132.0.5 but seems completely broken in latest beta. For example, it doesn't work by selecting these menu items on the screen, but works by pressing hotkeys (F3, Shift+F3).

@JairoMartinezA, sure, they don't. Moreover, I expect that highlight all should be enabled by default. :)

[Alexey-T]

I think the two features "Hi" and "Selects" don't need to be mutually exclusive IMHO,

yes, but we have now "incremental search" is embedded to "Hi" and incremental search is incompatible with "select all".

[Alexey-T]

@xcme

For example, it doesn't work by selecting these menu items on the screen, but works by pressing hotkeys

yes, see my reply to Jairo. it's the reason. 'select all' don't work with 'Hi'.

[Alexey-T]

@xcme To solve this for you, vote for #3431 - you will turn off the inc-search and 'select all' will work for you

[Alexey-T]

try new beta
cudatext-win-x64-1.133.6.1b.zip
which has disabled 'select-all' with 'Hi'.

[xcme]

try new beta

Could you, please, enable Find Next/Prev/Select all to test it? F3/Shift+F3 work, but not from menu.

And what exactly does Alt+E do when you are on the search dialog? It moves caret but I don't understand the logic.

[Alexey-T]

Alt+E is calling 'select all' (I see it in the 'more' menu). select-all is disabled with "Hi" as it conflicts with incremental search...

[xcme]

Alt+E is calling 'select all' (I see it in the 'more' menu). select-all is disabled with "Hi" as it conflicts with incremental search...

How could it be? It perfectly works with hotkeys.

Do these find Next/Prev do the same as

?

[Alexey-T]

disabled 2 items on 1st pictiure by mistake. reverting.

[xcme]

And how could it be that find prev has Shift+Enter, where here I see:

?

Does it mean that Shift+Enter is hardcoded?

[Alexey-T]

'shift+enter' is a hotkey local to Find dialog! not app wide.

[xcme]

select-all is disabled with "Hi" as it conflicts with incremental search...

inc-search is embedded to 'Hi' option in tthe last beta. it is 'find-first' from 'initial caret pos', where 'initial carret pos' is remembered on Find dlg showing. (to reset it, hide dlg+ show dlg).

We don't need to remember initial caret pos with 'find all' because caret will be placed on every match. If these search function are really incompatible, could you try a workaround, when CT temporarily disables 'hi', perform 'search all' and then enables it again? I

[Alexey-T]

why do we need a workaround? it works like in ST3 now.

find-all don't need the initial-pos, but "find-next" needs it - find-next is running after the find-all found all matches.

[Alexey-T]

'Hi' works in 2 stages

1- find-all and placing borders on mathces
2- find-next from 'initial-pos' to show caret on next match

@tmsg-gh FYI

[xcme]

why do we need a workaround? it works like in ST3 now.

Generally, yes, except that fact that ST3 supports 'highlight all' and 'fill all' at the same time.
Without HL:

With HL:

find-all don't need the initial-pos, but "find-next" needs it

Exactly, but we don't need 'find-next' if we are trying to perform 'select all', because all matches are selected and caret is placed everywhere:

(This is from CT)
In that particular case initial-pos doesn't matter and it's doesn't matter was the initial-pos on line XX or not. Correct?

[xcme]

Thus, we know that 'select all' basically works. And this:

'Hi' works in 2 stages

1- find-all and placing borders on mathces

works as well. So, 'find-next' is not needed, because only border is absent. All other job has been done already, right?

[Alexey-T]

Stage-2 is indeed not needed for 'select-all', so I need to rewrite 'stage 2' for this, maybe todo for me.

[JairoMartinezA]

So, at the end Alex, will it be mutually inclusive the "Hi" and "Select all" options?
Currently in 1.133.6.4b I cannot select all matches, in comparison with ST, ST allows it.

[Alexey-T]

I will work on it (little later).

[Alexey-T]

I added this, select-all works now. it may cause some regressions though, pls test.

[xcme]

Looks nice, but found something to discuss/fix.

1. Highlighting sometimes doesn't work during changing text on search string
   Hi is "on", text is bb bb b b, Ctrl+F, type "zb", then remove "z". The "b" letter should be highlighted but usually it isn't

2. Highlighting doesn't work during changing source text (old issue)
   Hi is "on", text is b. Ctrl+F, type "b", Alt+E, Ctrl+F, "z" (replacing "b"), Ctrl+Z. Now "b" is here but is not highlighted

3. Non obvious logic with multiselection (old issue)
   Text is bb bb b b, Ctrl+F, type "b", then Alt+E, Ctrl+F. Press "z". How many "z" would you get? 6 or 4?

[Alexey-T]

Points 1,2: cannot repro (seems editor event OnChange don;t work for you. I will try it on win10 later.)
Pls post a new issue?

Point 3: 4 'z' as result. it's OK: because adjacent selections are merged (so we had 4 selections)

[Alexey-T]

posted as 2 new issues, thanks, it's not related to Subj.

[Alexey-T]

Cud release 1.133.7.