[...]

> > custom - this is exactly the same as entering something in Files.
>
> Well, its "Not Project", ie you need some way to switch away from using
> project settings, how good "Custom" is as a name is open.

So it only exists because Project exists, and has no intrinsic value.

The key point of the "project" option is that the file patterns are stored in the *project* file not in the *user* preferences.

The project patterns are edited in the project preferences and the changed value appears in the FIF dialog field.

This is consistent with all the other places project settings override user settings, they need to be edited in the project prefs so the user understands that they are saved in the project file.

I'm not sure this is such a brilliant general UI decision, but its an attempt to ensure that users are not confused by the "complex" idea that one set of settings can override another, and that they know which set they are editing. I don't think this setting should deviate from the norm.

> > project - this is not exactly the same as placing the Project 'File
> > patterns' in Files. It pastes them, all right, but then locks the
> > field, so you can't add / remove / edit a pattern. And the only reason
> > to lock them is "consistency": the 'project' choice must correspond to
> > these patterns exactly. Well, if you do a Find, and then switch to
> > 'custom', and then open the Files history, you will be able to edit
> > the patterns after all... Last and least, 'project' grays the patterns,
> > making them less visible.
> >
>
> Make sure this functionality isn't important to the project plugin(s). I
> remember vaguely some significant discussion on the subject during one of
> the project plugin developments.

If a plugin can access the field, it can simply fill it with something
and lock it, without using an additional combo box.

Its not just the project plugins, the built-in project does it too, see above.

Of course, if I change FiF, I will make sure that the plugins work.

> The fact that you can edit the paths when you have switched to custom is
> irrelevant, that doesn't save to the project.

I could not understand this sentence, but agree about "not saving the
project". It doesn't save "all" and "custom" either. :)

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.

> > Proposition:
> > Remove the combo box.
> > Add a paste icon on the right of files, above the Directory selection
> > icon, and set it's tooltip to "Paste the project patterns, if any".
> >
>
> This is not the same functionality, choosing project on the combo is a
> sticky choice that follows the project settings, with this change the user
> would have to remember to paste when changing the project setting or after
> a custom search.

And it also blocks editing the patterns. The most common starting point
for specifying custom patterns does not work.

Explained (hopefully) above.

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.

Or we can check if the field contains the current project patterns,
and fill it with the new project patters on switch. Big deal.

If "project" is selected copy whatever the project has in it. Blank means "everything" so it too has to be copied. There is really no need to check if its the same, just copy it :)

> > FiF checks if a project is open, but not whether it really contains
> > 'File patterns' - RFC.
>
> Which is the project's problem, not the search's. Search should not impose
> requirements on projects.

It doesn't, and I do not propose such a thing. It's just strange that
"project" is disabled if there is no project, but enabled if there are
no project paths.

See above, no patterns means "everything".

[...]

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.

> The hard coded grep options thing has always been a
> problem (eg see the Note in the manual). The grep setting in tools should
> accept a whole command like most of the other settings, probably with the
> usual %something substitutions.

"should" == "does not, and there's nobody willing to do it"?

Yep, or "nobody thought it was important enough to do it" :)

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.

> > 5. Pressing ENTER in Directory does not activate Find.
> >
> > Proposition: obvious.
>
> I thought that was a PR, but I can't find it, nvm.

Maybe I was unclear. ENTER in 'Search for' or 'Files' activates the
Find button. ENTER in Directory does not.

Yes, you were clear, I just thought it had been raised, but anyway, yes it should be fixed to be consistent.

[...]

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" ;-)

Cheers

Lex

--
E-gards: Jimmy
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel