Oh, then you are seeing too little: I know a couple of phone numbers, where something in the middle of the number indicates a different call route. I.e. there is a common country prefix, a couple of digits which depend on the call route (and are not of equal length) and a postfix which identifies the SIM card in the calling device. Consequently it would be convenient to have, e.g. a single white-list entry for such a caller.
Though this is surely not a common case, such use-cases exist.
Still, this could also be achieved with the usual “shell-style” wildcards “*” and “?” (or even “*” alone, for a loss in matching precision), if +3957*1234 is allowed.
Now I am confused and have to take the time to look at the code some time:
- Why is @windes only able to obtain a working prefix matching when entering “
^+3957” (as advised by @ric9k), if this is not using a RegEx currently? - No, I did not intend to state, “This should be implemented via RegEx”. I merely stated, “If this already accepts RegExes, please do not drop this feature”. Thinking about it (see first paragraph of this message), “shell-style” wildcards (“
*” & “?”) are sufficient. - I absolutely do not believe that one must be able to input RegExes (if supported) via GUI: A
dconf write /sailfish/voicecall/filter/<filter-list> ["’RegEx1’, ‘RegEx2’, ‘RegEx3’"]is fully sufficient, when properly documented.
Though I would be glad, if one can enter RegExes at the GUI when they are supported. - But as @windes correctly pointed out, one must be able to input all characters needed for simple matching and the explanation of this dialogue must clearly state which input is expected rsp. possible here.
Currently I perceive exactly this as the main culprit for simple users to utilise this feature, not its functionality.