[Builder] Find/replace implememtation

[Erick Pérez Castellanos <erickpc gnome org>]

Hi:

I've started this the weekend, and haven't move very far mostly
because I've been reading Builder's code.

Now, there's things to consider when doing find/replace

+ Do we want the find/replace dialog to belong to a particular view,
or application wide. By doing it application wide we allow the user to
switch between sources and keep executing the same search.
+ There's two mockups for the feature, one making it dialog and one
making it part of the chrome on a view [1]. By choosing one over the
other we kinda fix the issue stated before
+ Also, some code editors has the ability to "find in files" an
SublimeText at least has the ability to replace on various files at
once. Do we want this?
+ Just another thing, we might want to mark the gutter/scrollbars with
the place of the occurrences if/when the file is huge.

## On the implementation front

Considering the issues before solved, where do we attach the
find/replace functionality. If it would be local is easy, that would
make it part of GbEditorFrame (or at it launching from there). If we
should to make it application wide, we need to hear on the activation
of GbEditorViews from someone so we can adjust to it when the user
change the source he's viewing/editing.

## Schedule

I'd like it to get it in time for 3.15.4, but as with every simple
thing made right it takes time to cook the details. I'm guess it will
be done after the release on Monday.

[1]: https://wiki.gnome.org/Design/Whiteboards/GeditFindReplace

Your thoughts on this.

On 14/01/2015, Christian Hergert <christian hergert me> wrote:
> On 01/14/2015 06:26 AM, Erick Pérez Castellanos wrote:
> > > ## Search Results Layout
> >
> > ```
> >   +----------------+-------------------------------------------------+
> >   |      Switch To | my-widget.md                              [==-] |
> >   |                | my-widget.ui                              [=- ] |
> >   |                | my-widget.c                               [=- ] |
> >   |                | my-widget.h                               [=- ] |
> >   | Jump to Symbol | my_widget_init                            [=- ] |
> >   |                | my_widget_class_init                      [-  ] |
> >   |                | my_widget_do_something                    [-  ] |
> >   |                |                                          2 more |
> >   |  Read Docs For | GtkWidget                                 [-  ] |
> >   |                | GtkTextView                               [-  ] |
> >   |                | GtkSourceView                             [-  ] |
> >   |                |                                         20 more |
> >   |     Calculator | hex(3*10) = 1E                                  |
> >   +----------------+-------------------------------------------------+
> > ```
> >
> > "Switch to" and "Open Document" could be merge, in the end its the same
> > thing.
> > Also I think preferences could be excluded from here. There's a
> > shorcut to get into the preferences dialog and search inside the
> > dialog. The same for actions, those are available from the command bar
> > and it has autocompletion.
>
> Merging Switch To and Open Document makes sense from the user
> perspective. A bit harder from the implementation perspective (since the
> Git index knows nothing about open documents). But I think it's
> worthwhile to do this merging.
>
> I'm wondering if we can replace the command bar with the global search
> (with the exception of VIM mode). I think once history is exposed into
> the command bar, it will stand well on it's own (so I think the answer
> is no, we can't replace it).
>
> > > ## Shortcuts
> >
> > On the idea of limiting the output we could do something like:
> > "c: my_widget" will show only the results of the "c" search providers,
> > the colon will act as a delimiter and if the user want to search for
> > the string `c:` it can always wrapped into single-quotes.
>
> Yes, the idea is to only show the relevant search provider's results
> when the character prefix is matched.
>
> I don't think we can provide meaningful results with a single character
> search query, so I'm not too worried about a delimiter between the
> provider and the result.
>
> As we get a real search engine, (with bi-grams and tri-grams), then
> things like quoted strings makes sense.
>
> > > ## Search Context
> >
> > Again, if the user clicks on the "X more" link there's no need to show
> > the results of other providers, clearly the user wants the results of
> > that provider and not the others
>
> My thought was that we'd slide in from the right the search query
> limited to that provider. (With the standard back arrow at the top to go
> back).
>
> Technical detail: This will execute the query a second time, but just
> for that provider. This way we can discard items that are not high
> enough score without creating costly objects for them in the normal case.
>
> -- Christian