Forum > General

"Find" could be made better very easily.

(1/4) > >>

When I press Ctrl+F and put in a search string, I expect the editor to find the next matching string and it does. But then when I press Ctrl+F again I expect it to look for the next matching string and not the one it just found. Yes, I can get the result I actually want by pressing F3 instead but why frustrate people like that? We've already learned what Ctrl+F means, why make it do something slightly different that no-one will ever want it to do? No-one ever wants to search for the same string in the same place while they still have it highlighted just to check that it's still there, and yet this is what has been implemented.

Ctrl-F starts the search process, F3 continues it.  If you keep starting it, you should expect it to keep starting.

I don't know of any application that uses Ctrl-F in the way you think it should work.


There are a few details that make this less easy(desirable) than you think.

First lets see, if I understand you correctly.

If I press Ctrl-F the 2nd time (while the found term is still selected), there are 2 things that happen.
1) The dialog opens again
2) The dialog goes to "selection only"

You probably dislike both. But what irritates you is probably mostly (2).
If only the dialog would open again. And if you could then just press enter, and if that would then find the next match (instead of the current highlighted one), well then you could just press enter, and find what you want.

But of course, if there is a selection, then the user may want that selection to be searched.
At the time of ctrl-f the IDE can not know the users intent.

- I search for a very long (multi word match).
   Maybe a regular expression like: writeln.*;
- Now that block is selected
- I want to find something in that block.
  The IDE may fill in the search term, with the entire selected block.
  But the IDE does not know, if I am going to replace the search term with something else.
  So - since a block is selected - the IDE should switch to search "selection only".

And this is exactly what the IDE does.

So up to this point, everything is actually useful (useful, for some usecases).

The "strange" thing that happens is something else. And it does not matter, if or if not the selected block came from a previous search, or was set by the user directly.

If I select any amount of text, that does not extend over the line bounds, then this text will be the new search term. That also is correct and useful. And it can be disabled in the options (but that will not help here)

If text is selected then search settings are adapted to search selected text. (I don't think that can be disabled by any IDE option)

However, searching inside a selected block only makes sense, if the search term is not equal to the selected text.

- the user double clicks a word to select it
- the user hits ctrl F
- the dialog fills the search text with the selected word and goes to "only selection"
- the user does not change anything. Neither the search term, nor the "only selection"
The search is pointless.
But its a user error.
=> if the word was selected by the user before, then there is no sensible alternative action.
The settings the user confirmed for the search simple are pointless. But the user confirmed them.

In the case of the word having been selected by the user, when there was no previous search, it would be a very unpredictable action to ignore the settings that the user confirmed (however pointless they are). So the IDE must not go and search the next word outside the selection.

After all, the user may have just forgotten to change the search term. In that case the user may be glad to find the selection still as it was.

So your suggestion makes only "some sense" in a very specific case.
It would require state-keeping what the users last action was.

It would also risk irritating users who might not understand the pattern, and only be irritated because the search would sometimes adhere the settings and sometimes ignore them.

And, even if the last action was a search: The above case where the user forgot to change the search term => it could still apply.

So it is not easy at all. Others might find it irritating. And it would add complexity for no gain (changing one complaint for another is not a gain).

The only possible change that could be made, is to give users the option that the IDE does not adapt the search scope to "only selection".

Then you could hit ctrl-f and just hit return, and it would search to the next occurrence.

But it would still open the find dialog, and you still need to do an extra keypress.
So - I guess - it would not really help you either. So I don't think such an option is needed/helpful

Btw, have you got on editor (to which you are used) that behaves, as you said it should?

What editor is that?


--- Quote from: Martin_fr on June 17, 2021, 03:36:46 am ---Btw, have you got on editor (to which you are used) that behaves, as you said it should?
What editor is that?
--- End quote ---

The two text editors I use most behave like this: vi (/) and Emacs (CTRL-S). Find a match with / or CTRL-S, and / or CTRL-S to find the next match.

On the other hand, I have no problem with the Lazarus IDE editor on macOS using CMD-F (find) and CMD-G (find again) which is consistent with other macOS GUI editors like TextEdit.


[0] Message Index

[#] Next page

Go to full version