[Geany-Devel] Improving FiF

[Dimitar Zhekov]

On Thu, 10 Oct 2013 09:54:37 +1100
Lex Trotman <elextr at gmail.com> wrote:

> On 10 October 2013 07:01, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> 
> > Proposition: move the presentation to glade as much as possible, and
> > fill the content with code, as in any normal program.
> 
> Well, not everybody likes Glade or XML, but why only FIF, why not all
> search dialogs?

I don't like XML either; only because I'm at the FiF dialog ATM.

> > 2. The all/project/custom combo box. This thing has 2 functions
> > dedicated to it, and about 50 LOC in total. So what it does?
> >
> > all - this is exactly the same as leaving the Files empty.
> 
> Yes would seem to be an alias of the delete button on the entry.  Are you
> sure that the delete button is always guaranteed to be present, and not
> deprecated by GTK3 or removed by themes or ... something else that removes
> it?

I'm not sure about the future of GTK+ at all, but that's another theme.

In the eventual future absence of the clear icon, you are free to clear
the text with Delete/Backspace if it's selected, or with Ctrl+A and
Delete/Backspace if it's not.

> > 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.

> > 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.

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. :)

> > 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.

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.

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

> > 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.

> > 3. For non-recursive searches, grep does not allow a directory to be
> > specified instead of file. To work around that, we read the directory,
> > back-parse all --include=*.x patterns, and match them manually.
> >
> > Proposition: grep -rl --include=*.c --exclude-dir=[^.]*
> > --exclude-dir=.?* void . :)
> >
> > We pass our Directory as a workind  directory to spawn, and the
> > recursive search already uses . as a grep FILE argument.
> > --exclude-dir is supported since more than 5 years.
> >
> 
> But not in POSIX grep.

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.

> 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"?

And you won't be able to produce one --include= directive for each
pattern in Files with the usual substitutions.

> > 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.

> > 7. [ ] Extra options. Unchecking this is the same as clearing the text
> > field, except that you can re-enable them later.
> >
> > Proposition:
> > Make 'Extra options' a label.
> > If we want to keep the options, add a normal history. Personally I
> > don't care about them.
> >
> 
> In the absence of grep in tools prefs being a full command, this is where
> your --include and --exclude should be the default value.

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?

-- 
E-gards: Jimmy