On Tue, 8 Mar 2011 13:33:29 +1100, Lex wrote:

>On 8 March 2011 04:33, Dimitar Zhekov <[email protected]> wrote:
>> On Mon, 7 Mar 2011 11:15:27 +1100
>> Lex Trotman <[email protected]> wrote:
>>
>>> It just occurred to me that the case insensitive setting for regex
>>> search and the case insensitive setting for non-regex search are
>>> separate settings.  I don't know if that is really clear.
>>>
>>> One makes the non-regex search case insensitive, the other adds the
>>> i modifier to the regex and they don't have to be the same.
>>
>> To me, this is a technical difference, and I'm not sure why it should
>> be exposed to the user. I often search (insensitive) sql scripts for
>> regex, or C-language-family files for plain text.
>>
>
>Yes for the user its just a part of the particular search, but I see
>it as two different settings one that goes with regex search and one
>that goes with non-regex.
>
>>> But they use the same UI element, which could be considered bad
>>> design.  Even so they should be saved/restored when the dialog is
>>> switched to/from regex and they should both be saved to disk
>>> independently.
>>
>> In fact they are implemented in search.c as "current UI state" and
>> static function-local "previous UI state if regex is checked"...
>>
>
>Of course it should always use the displayed value, the point is when
>to save and restore that value.
>
>
>>> But I am not sure that the current code achieves this.
>>
>> It doesn't: the "previous state" is not saved, I was explicit about
>> that. But the patch at least separates the find-previous-state and
>> replace-previous-state, which were improperly using the same
>> variable.
>
>I'm not criticising the patch, its a worthwhile fix.  I'm just
>pointing out an extra improvement if someone has the time and
>inclination to work on it.
>
>>
>>> In fact case sensitivity and other settings should also be saved as
>>> part of previous searches, so if I pick a previous search from the
>>> list I get the right settings too.
>>
>> As of me, the full searches should put in history, saved and
>> restored,
>
>Agree, thats what I was pointing out in the hope that someone has the
>time too look at it.

Wow, you guys have crazy ideas :).
More seriously, I actually think saving searches together with all
their options is overkill.

Not sure either about separating the 'case sensitive' option for regex
and non-regex searches. I think as a user, it doesn't matter that much,
as regex and non-regex searches always differ a lot and so does the
'case-sensitive' flag.

Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc

Attachment: pgp3SArKR2NYz.pgp
Description: PGP signature

_______________________________________________
Geany-devel mailing list
[email protected]
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Reply via email to