[Geany-Devel] Improving FiF

[Lex Trotman]

[...]

> > 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 at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20131012/ae77d6c9/attachment-0001.html>