On Sat, 12 Oct 2013 08:24:56 +1100 Lex Trotman elextr@gmail.com wrote:
The key point of the "project" option is that the file patterns are stored in the *project* file not in the *user* preferences.
I know, and never proposed to make patterns indicated as "project" editable.
Hopefully explained better above, sorry. Note that the combo box value and the "custom/non-project/whatever we want to call them" file patterns are meant to be saved in the user preferences, and it works for me.
I had a momentary lapse of reason, writing in the response to Martitz than the patterns are not saved, but that's of course wrong. The current value is saved.
Anyway, comparing the current FiF patterns against the current project patterns to decide where to paste the new project patterns when switching to another project will not be reliable. Close the project, restart, and there's no way to guess.
The "same functionality" can be achieved by using a check box, since the distinction between "all" and "custom" is nonsense. That'll still block editing, but at least won't be so clumsy.
I wasn't meaning to argue *for* a combo, just the distinction between project and custom/non-project/whatever. As we agreed, "all" is redundant if the delete is available, so a "project" check box is fine by me so long as it does the same as the project setting on the combo.
Since "project" does provide functionality, I'm changing the proposition: make it a check box. A single click will be enough to (un)lock it, and a double click (check-uncheck) will load the project patterns and enable editing.
(From UI standpoint, it may be better to make Files label a button, and the text between Files and Project on click - it'll look very similar to the current combo box. But I'm not a HIG expert.)
[...]
We are not using POSIX grep, it doesn't even support recursive search AFAIK. We are using GNU grep, and the above options work on our supported platforms, *NIX and Win32.
I understood that in the past there was an attempt to not limit this to GNU Grep.
Personally I would agree that it isn't worth supporting anything else, but Colomban needs to approve that decision and the documentation needs to be updated to note the limitation, and I guess the label on preferences->tools->grep should be "GNU grep" to make sure its understood thats all that is supported.
Yes. Unless there is another grep which has a --include options for patterns.
And you won't be able to produce one --include= directive for each pattern in Files with the usual substitutions.
By "usual" I just meant using the %, not what the actual possible substitutions would be.
--include=%p will simply produce --include=<all patterns>. We would need something like {--include=%p} to signify what text to repeat for each pattern.
I'll explain again. The only point of the checkbox is to be able to quickly disable the extra options, which is the same as clearing them, *except* that you can restore them quickly.
If we consider them so important as to have an extra interface element, why don't we use a normal history, and have several sets of options?
"why don't" == "doesn't, and nobody cared enough to do it" ;-)
:) On the same hand, we don't even save the Files history, and not even the current values of 'Search for' and 'Replace with'.