[Geany-Devel] Improving FiF

[Dimitar Zhekov]

On Sat, 12 Oct 2013 08:24:56 +1100
Lex Trotman <elextr at 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'.

-- 
E-gards: Jimmy