[Geany-devel] save find settings

[Lex Trotman]

2011/3/9 Enrico Tröger <enrico.troeger at uvena.de>:
> On Tue, 8 Mar 2011 13:33:29 +1100, Lex wrote:
>
>>On 8 March 2011 04:33, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
>>> On Mon, 7 Mar 2011 11:15:27 +1100
>>> Lex Trotman <elextr at gmail.com> 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 :).

Hrumph, cough cough, I'd prefer "interesting", "innovative",
"individual" rather than crazy :-)  in fact you'd be crazy to think my
ideas are crazy :-D

> More seriously, I actually think saving searches together with all
> their options is overkill.

Ok, so why save the whole search string/regex, lets just leave off the
last character, the user can add it just as easily as they can re-set
the options.  Yes, it sounds silly.  But both the search string/regex
and the options need to be complete and correct to repeat a search, so
why are the options treated different to the search string?

>
> 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.

Well I'd say that they tend to be the same as the previous search.

So either the UI should maintain its setting unless restored from
saved search or it should always go to a user set default.  I'd prefer
UI.


Cheers
Lex

>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>