On 8 March 2011 04:33, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 7 Mar 2011 11:15:27 +1100 Lex Trotman elextr@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.
but I followed the existing Find in Files settings save. It's better to at least have Find, Replace and FIF in sync for now.
Certainly.
Cheers Lex
-- E-gards: Jimmy
On Tue, 8 Mar 2011 13:33:29 +1100, Lex wrote:
On 8 March 2011 04:33, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 7 Mar 2011 11:15:27 +1100 Lex Trotman elextr@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 :). 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
2011/3/9 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 8 Mar 2011 13:33:29 +1100, Lex wrote:
On 8 March 2011 04:33, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 7 Mar 2011 11:15:27 +1100 Lex Trotman elextr@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel