Search and replace in the editor

[lazjump]

Hello,

I think I found an unintentional behaviour when search & replace (Ctrl-R) in the editor.

When we select just 1 line in the editor, and press Ctrl-R, the Scope option in the Replace dialog defaults to Global. It should defaults to Selected Text.

Try this:
1. Open a file in the editor
2. Without selecting anything in the editor, press Ctrl-R. The Replace dialog pops up with the Scope option defaults to Global. This is normal.
3. Select some lines in the editor then press Ctrl-R. The Replace dialog pops up with the Scope option defaults to Selected text. This is normal.
4. Now select a line in the editor (just 1 line) then press Ctrl-R. The Replace dialog pops up with the Scope option defaults to Global. This is not the way it should be.

PS. Lazarus 1.2.6 on Windows XP

[Martin_fr]

Yes and no.

This behaviour was probably based on the default setting ("Find text at cursor"). With that the selection (if it as a one line selection), is used as search term.
So if selected text is used for search, then it makes no sense to use it as scope too.

If that option is off, then you are probably right. So, I will wait fo a bit, and see if there are other opinions.

Please report on bug tracker.

[lazjump]

Hi Martin_fr,

I find that the "Find Text at Cursor" option is turned on in my Lazarus.

Then try to uncheck that option. But turning the option off or on does not seem to affect the behaviour.

Please allow me to make a comparison with Delphi 7. In Delphi 7 with similar option turned on, the behaviour is not like that. The Scope would persistently defaults to Selected Text even only one line is selected.

Actually, I found this through an "accident" where the editor replaced all instance of the text I searched... when all I want is to replace in only one line that I selected 
 

[Martin_fr]

Yes currently the behaviour does NOT changes, if the option is changed.
IMHO it would be best if it depended on the option.

If the option is one, setting the scope makes no sense.

But if it is off, I agree it should be changed. Yet I will wait for others to comment.

[lazjump]

Hi Martin_fr,

Perhaps we had mistakenly think the purpose of "Find Text at Cursor" option.

It seems that the purpose of "Find Text at Cursor" option is to determine whether to fill or not to fill the value of "Text to Find" in the Replace dialog with the text at cursor when we press Ctrl-R.

If "Find Text at Cursor" is off, when the Replace dialog pops up then the value of "Text to Find" is left unchanged from the last time it was filled.

If "Find Text at Cursor" is on, when the Replace dialog pops up then the value of "Text to Find" is automatically filled with the text at cursor when we press Ctrl-R.

So, the "Find Text at Cursor" option is working fine in Lazarus, and perhaps it isn't directly related with the behaviour we are talking about.

[Martin_fr]

So, the "Find Text at Cursor" option is working fine in Lazarus, and perhaps it isn't directly related with the behaviour we are talking about.

Yes. Currently it is NOT related.


But if the behaviour is to be changed, then it should be.

Currently: If the option is ON, and if a full line is selected, then pressing ctrl-R or ctrl-F will set the "text to find" to the text of that line.

Even if in the future, the behaviour is changed: If you search or replace the text of the entire line, then a scope set to the same line (which is the selection) will not make sense.


Therefore I said: IF this is going to be fixed in future, it may be that it will only be fixed when the option is off.

[lazjump]

Hi Martin_fr,

From my point of view, the main issue is consistency.

To rephrase the behaviour in a question about consistency: Why a selection of one line treated differently than a selection of many lines?

It is not the matter of filling the value of "Text to search" automatically or not (the purpose of "Find text at cursor" option).

A selected text is a selected text, whether it is has one line or many lines. The "Scope" should always defaults to "Selected text" whether the selection has many lines or one line or even one character.

So the behaviour should be simple and consistent:
- if selection exists, then "Scope" defaults to "Selected text"
- else "Scope" defaults to "Global"

[Martin_fr]

To rephrase the behaviour in a question about consistency: Why a selection of one line treated differently than a selection of many lines?

If there is selected text, the selected text (instead of the "word" at caret) is placed into "text to find".
And the "text to find" is an input that only takes a single line. So for a selection of more than one line, the selection can not be placed into "text to find".

Therefore the behaviour if "Find Text at Cursor" is enabled, is to take the selection, as long as it is no more than one line.

If the selection is placed into "text to find", then setting scope to "selection" is not desirable. (Well there may be cases, but many people are used to the current behaviour.
Changing it now, would affect those people.

I do not know, if people rely on this, if the option "Find Text at Cursor" is off. So I asked.

Btw: open office also follows the one line rule (ctrl-h for replace).

I understand that different editors handle this different.
I understand that there are people (including you) who are used to other behaviour.
And it would be nice to provide the unctionality

Anyway: at least if "Find Text at Cursor" is enabled, the behaviour can not be changed (not as default, not without option). This would upset those who like the current behaviour, and are used to the IDE being like this.

So the possibilities are:

1) Introduce an entirely new option for this. I like to avoid this
2) If no one minds: make it depended on "Find Text at Cursor" (disabled)
  (As I said, I still wait on feedback, people may rely on that behaviour too)

What I try to understand is, if it is important the have "Find Text at Cursor" (that is get the selected text filled in), and yet limit the scope to the selected text.

IMHO this only makes sense, if you do not use the selected text as "text to find". Otherwise, it is just a one time replace of that text.

[Never]

@lazjump
is not the only one thought....
same confusion is with the [ context ]* menu wich is consantly out of context for at least one menu item
openned  bug report also
[ http://bugs.freepascal.org/view.php?id=26988 ]
 and explain the behaivior but propably there are more important bugs to fix first