Is there a predefined mode to run a regex case sensitive search?

[aborruso]

Hi,
if I click | and search [a-z], I get also records that contain "AAA".

Then to run a case sensitive search I click on z| and then use re.search("[a-z]", fieldname).

Is there a special keyboard combination to make | search case sensitive?

Thank you

[aborruso]

@anjakefala @saulpw is there a way to do it?

Thank you very much

[geekscrapy]

You can set the option regex_flags to nothing: vd --regex_flags=''
Or in your visidatarc file: options.regex_flags=''

[geekscrapy]

If you set this permanently in visidatarc you can override regex flags when entering regex like so:
(?i)tHiS is nOw CASE INsensitive

[aborruso]

It would be great to have as default the case insensitive (the current) and to have something like (!i)tHiS is nOw CASE INsensitive do disable the insensitive.

Thank you @geekscrapy

[frosencrantz]

I'll mention something I suggested in #1806 (comment).

Visidata instead of starting with a blank input field, it would start with a leading prefix, that you can then modify with the regular keyboard editing keystrokes.

When you type | instead of getting a blank input field, the input would already start with (?i) and you could type [a-z] and then the input would be (?i)[a-z]. If you didn't want case-insensitive, you would edit the input to delete the leading (?i) and then your search would be case sensitive. This puts the user in control of the search flags at the time of the search, and it would not be hidden from the user in options.

[aborruso]

Thank you very much @frosencrantz

[saulpw]

Interesting idea (again), @frosencrantz. I'm thinking that if the "input dialog" can take a simple dictionary as a "prompt" (including default values) and then return a dictionary with the same spec, then for the regex search/select, we'd add a field for "regex flags" using options.regex_flags as the default,, which could be changed to with Tab and edited by the user. To get away from the difficulty of making the dialog pretty (which is half of what's stopping me from just coding up the input dialog), I'm thinking that we can just make the "dialog" take up the bottomost rows of the pane, one line per input field, with nothing fancier than simple color/attribute/link markup. It won't look as nice as a popup central dialog, but it should be clearer than hacking up the single input field that we have now, and give us a lot of options in both the present and the future.

[frosencrantz]

@saulpw that sounds brilliant. That is a simple protocol and implementation for a "dialog". I love it. I've wanted dialogs for a while, and this sounds like it could be powerful. It does not have to be perfect at first. If it is useful and there is demand, there will be room for more features.

[frosencrantz]

@saulpw Thanks for adding this! This is now in the develop branch, 0869019. I need to try it some more, but I think this is a great new feature.