Re: [anjuta-devel] Search Dialog in Anjuta 3.2?

["Johannes Schmid" <jhs jsschmid de>]

Hi!

> That's good as you seems quite busy recently I haven't expected it for
> Anjuta 3.4.

Thanks for your feedback! Yes, I have been quite busy working and it
sometimes hard to motivate yourself for coding when you have been working
for 8-10 hours.

> 1. It's really annoying that the search is case insensitive by default
> while almost all programming languages are case sensitive.

This is one of those things that are wrong for 50% of the people whatever
you try. But we could possibly save the state with gsettings so that you
at least don't have to always set it.

> 2. I would prefer a check box for regular expression and case
> sensitivity. I think it's quite difficult for a new user to imagine that
> he can get this option by clicking on the search icon. Moreover there is
> enough space on the right.

Even as I proposed it I don't like the current UI with the menu. But
checkbuttons don't scale very good either. In english that *might* work
but in Germany you would have two check boxes

[x] Groß/Kleinschreibung beachten [x] Regulärer Ausdruck

which will of course work on my 24' desktop screen but not really on my
13' notebook anymore.

What I was thinking about is an extra button with an [Options] symbol that
pops up the menu. The current state should then be shown either in the
remaining space (can be ellipsized if needed) or in the statusbar.

> 3. Some editors do case sensitive search if the user type upper case
> characters in the search string, this can be another option if you prefer.

Looks like a rather random choice to me.

> 4. It will be nice to be able to search in the selected text only.

If you have some selection the search should start inside it AFAIK already.

> 5. In the new "find in files" window, the Search, Replace and Find
> Files buttons are not aligned on the right.

Have to look at the GtkGrid options to get this right but shouldn't be a
big deal.

> 6. I'm not sure that selecting the type of files is very useful. Most of
> the time, you have only one language in your project. Moreover as the
> syntax is different you can expect that you will not find the same
> string in several languages.
>
>
> 7. Perhaps we could add a way to have a custom filter. But as I have
> said above, I'm not really convince of its use.
>
>
> 8. Now the main point, I don't like the Find Files button. I think it
> would be better to just remove it and fill the list box below with the
> result of the search only. I mean add only the files containing a
> matching string.
>
> It means that you cannot filter the file before the search but I think
> it doesn't matter that much because nothing is changed. It will just
> take a bit longer but I think it would still be probably faster than
> manually unchecking files.
>
> It is more annoying for a replacement, so perhaps we can do such
> operation in two steps. First the replace button is disabled and you do
> a search only. When it's completed the replace button is enabled and you
> can replace the string in all the matching files. Before doing the
> replacement you can remove some files from the list. It means one more
> click for a replacement but I think that's fine.
>
> As a bonus, it will hide the fact that the project manager is too slow
> too as this operation will be done at the beginning of the search. :)

The "Find in files" button has it's origin in regexxer which is one of the
best search tools IMHO. But I like the idea of combining "Search" and
"Find files" into one button so I will try to implement it. It's not a big
deal.

> 9. For checking and unchecking files in the list, it should be possible
> to select a range of files.

What UI would you propose here? Popup-menu?

> 10. It could be nice to display the files in a tree view corresponding
> to the file hierarchy. In this case perhaps checking a range of files is
> less important as you can check or uncheck a parent.
>
>
> 11. I think the number of occurrences is not enough. I would like to
> have the line number and the text where the search string has been
> found. Even a one line context is useful to easily see which are the
> expected matches. You can display this as children of the matching
> files. Moreover, the file could be open at the right line to see more
> context by double clicking on the corresponding line. It will even allow
> me to select which match will be replaced.

In general I agree with this points but I won't have time for it this
cycle. The latter is a bit tricky because there is no easy way to find the
line of a match as you only get the string position.
Of course we could break up a file in lines but that would break multiline
search with regular expressions. And counting the newlines between the
matches also seems like a slow solution though we might try that. But as I
said, I don't think it's doable in the last week.

Regards,
Johannes