Someone or something resets find/replace options

[tmsg-gh]

Latest 215.02 on Debian 12/XFCE.

This is going on for a while now, so I can't say exactly when it started. I always have RE and case sensitive on for both Find and Replace. Every so often, I start C and both fields are reset to off. I set them to on again and sometime later it happens again. It's possible that I press the relevant keys inadvertently but why I should start doing this all of a sudden is not clear (as I said this is "recent" behaviour.)

As a brutal but effective stopgap measure I have fixed the history.json file as I want it and set its permissions to 444, ie no write permission. Of course there are some bits that are not stored now but nothing important, it seems. In the long run we should try to find the reason for this episodic reset... or I'll have to add a one or two-liner of python code to set those flags on init. I have skimmed though the API wiki and found nothing, so how can I do this?

[Alexey-T]

Python API: https://wiki.freepascal.org/CudaText_API#app_proc_-_Search_properties e.g., call app_proc(PROC_SET_FINDER_PROP, { "op_case":True, "op_case_d":True })

[Alexey-T]

I found how app can reset Case/Regex/Wrapped finder options.

this command resets them (quit Cud after you run this command): "add next occurrence of selected word" (shift+ctrl+d)

user.json to repro: user.zip

[Alexey-T]

fixed THAT issue which I found above. from ctrl+shift+D. if you have reset of opts different than mine, it's not yet fixed.

it is not hard to find a repro. run in Cud some commands (which use finder) which you usually use, and restart C after that.

[Alexey-T]

also note that calling of cmd 'find current word next (previous)' reset the REGEX-opt. it is normal.

[Alexey-T]

here are both betas:

cudatext-qt5.zip cudatext-gtk2.zip

[tmsg-gh]

also note that calling of cmd 'find current word next (previous)' reset the REGEX-opt. it is normal.

That's the problem (or part of it) then as I v often use this with the actual Find dialog closed. Why do you think resetting RE for these commands is normal? I've never used an editor with that "feature" and I think it's a bad idea and bad design to have a tool decide these things on its own, behind the user's back.

I think if a user wants RE they should get it and keep it, no matter what. And what comes next? If I save a file, Cudatext resets the lexer to none? If I undo something, EOL type changes to CRLF?

[Alexey-T]

we had reasons for that (reset Regex opt on command 'find cur word next'). code

  //make command "find next" working with new text, issue #2803
  FFinder.StrFind:= Str;
  //and clear regex option (issue #2812)
  FFinder.OptRegex:= false; 

reason is to solve 2 mentioned issues.

2803

2812

a) sync find-dlg text with word-text, b) clear Regex opt, to avoid regex-errors on non-word sel text. are you against solving those 2 issues?

[Alexey-T]

I mean that i understood your POV. but @kvichans (author of those 2 issues) also has POV and his POV tells us that current situation is better. currently user can continue the search with "find next" after cmd "find current word next". this is useful too. if i change the behavour according to @tmsg-gh, this will be broken.

[tmsg-gh]

Well... if I can't find a way to disable that broken design (I've never seen an editor with that "feature"), then that'll be another nail in the coffin of Cudatext. Perhaps I should start to seriously look into ST.

[pintassilgo]

b) clear Regex opt, to avoid regex-errors on non-word sel text.

Shouldn't Cuda escape the selected string for this "find selection" command when regex is enabled? Like, if selection is abc( and regex is enabled, Cuda should use abc\(. Then it would work without regex error and regex user pref can persist.

[Alexey-T]

yes, inserting of escaped string for regex mode, may be a solution. I did not guess it. will try it.

[Alexey-T]

here is this 'new idea' applied. beta linux-gtk2 (tmsg must be using gtk2 as my notes say).

cudatext.zip

[pintassilgo]

Looks good to me. With my main Cuda (Qt5):

1. Copy the content from my previous comment and paste on Cuda.
2. Open find bar and enable regex.
3. Select the first abc( in document.
4. Run find current selection, next.

Result with my main Cuda (current release): Error alert:

Incorrect regex passed: abc( TRegExpr compile: ParseReg: unmatched () (pos 4)

And after that, regex is still enabled in findbar.

I guess both things are unexpected after your fix in #2812, i.e. there should be no error and Cuda should disable regex.

Anyway... Result with your new gtk2 build: No error, finds next match as expected and regex is still enabled.

[Alexey-T]

thanks @pintassilgo .

ah, I missed one fix to 'escape' regex-text on first find-dlg showing. linux-gtk2:

cudatext.zip

any more fixes needed?

[pintassilgo]

Not that I'm seeing. Let's wait for the OP.

[tmsg-gh]

I can't ATM check this as I have too many other things cooking (that's why I also didn't look into those Russian-language issues in the first place). I'll be back at a real keyboard Saturday...

[tmsg-gh]

I've now checked the version in the post above and the problem w/ F3 seems gone. However, only time will tell whether this bug raises its ugly head somewhere else. And I'm also not sure about resetting the case sensitivity. We'll see.

[tmsg-gh]

I've not observed any further trouble so AFAIC you can close this issue. In case I run into a problem, I'll open another one.