It seems that an old issue with persistent blocks is back again in the editor of current Lazarus snapshots.
I like to use persistent blocks but this is defeated by the fact that blocks are used as default string when invoking search. Some time ago this was not the case anymore (with some older build) but now it is back again at least with the last two snapshots I installed (the last one today).

Anybody knows about this and/or has changed it back?

Afaik it was always the case (and I remember a recent post claiming it was different, but even then, when tested myself, it was not.) The only time blocks (persistent or otherwise) are not used as default is if they are multiline.

The other option is to disable "Find text at cursor" in Options/Editor/Misc. However this will also affect using the current word at cursor, if there is no selection.

----
Giving it some more thought (locking at the name of the option), the following change could be made. (applying only if "Find text at cursor" is on.

If the caret is outside the block, then the block is ignored. It could also be , if the caret is not at one of the exact borders of the block. But given that we are only looking at one line blocks anyway, and that "being in the middle of the block" makes the block a "text at cursor", I prefer the limit of "outside the block" (imho more logical and intuitive)

----
For all else, I can accept a patch that adds an explicit option (applying to persistent and otherwise)

Yes, that was me who was happy that it suddenly was fixed (though it seems it was not ;-))

The only time blocks (persistent or otherwise) are not used as default is if they are multiline.

Ahh! That could be the reason. I didn't know that this distinction is made. Yes, now that I test it it seems I only had a multiline block and that this was the reason for letting me think that it is fixed now.

The other option is to disable "Find text at cursor" in Options/Editor/Misc.

Why can't the block be ignored completely if it set persistent? I don't know for what reason a *single* line block is used for search but multiline is not (it could be used the first line). This arbitrary behaviour is very annoying. The predictable behaviour of *not* using any persistent block is much better.

Giving it some more thought (locking at the name of the option), the following change could be made. (applying only if "Find text at cursor" is on. If the caret is outside the block, then the block is ignored.

Why that? In general, the cursor position is completely independend from a peristent block if I invoke search. I don't want to pay attention to this. It should work the same *all the time* (not only if the cursor is outside the block). The cursor only should decide about the search default (in all cases). Just ignore the block (if persistent).

I do not know, why or who did that limitation. Some people may be used to it now and I see no reason to abandon in (I can except extension)

It says "text at caret" not "word at caret". The determinations of the boundaries are not described.

A block/selection is a text too. Same as a word, or line, or paragraph is. A text could also be a statement (pascal statement, a limited expression (string, individual argument from a comma separated parameter list, ...))

Currently the implementation is: selection if available (and single line), otherwise word. That is correct (as far as the description goes). Except, if the caret is not at (or in) the selection, then this is not matching the description.

I don't want to pay attention to this. It should work the same *all the time* (not only if the cursor is outside the block). The cursor only should decide about the search default (in all cases). Just ignore the block (if persistent).

In that case I am happy to accept a patch for an option. It can be a checkbox, or even a dropdown (allowing to add any other desired behaviour / e.g include multi line)

---
Bottom line is:

If desired I can add the caret at/in selection check. I am happy to do this, and it can be done very quick.

If you want more, then it should be an option, and existing behaviour (with the exception of the in/at check) should be kept as one of the options.
I have no plans to implement such an option in the foreseeable future. Patches can be accepted.

Martin wrote

> Why that? In general, the cursor position is completely independend from a peristent block if I invoke search. It says "text at caret" not "word at caret". The determinations of the boundaries are not described.

I didn't say anything about boundaries. I only asked, why the block selection is related to the search default when the block is a persistent block. This is completely illogical and unintuitive. The block maybe somewhere out of view of the user and is still used as search default? Who wants such a behaviour? And for what reason?

A block/selection is a text too. Same as a word, or line, or paragraph is. A text could also be a statement (pascal statement, a limited expression (string, individual argument from a comma separated parameter list, ...))

What has this have to do with default search strings?

> I don't want to pay attention to this. It should work the same *all the time* (not only if the cursor is outside the block). The cursor only should decide about the search default (in all cases). Just ignore the block (if persistent). In that case I am happy to accept a patch for an option.

Who wants the current behaviour? I doubt that anybody does. It is completely illogical for persistent blocks (it may have some merit for non-persistent blocks but not when blocks are persistent).

Which is why I said it should/could be limited to only if the caret is in/at the block.

Your opinion... And maybe the opinion of others.

Anyway. I told you:
- What I will do on my own (no patch needed). For all else, I have a huge list of things that to me have a higher priority.
- What patches I will accept.

If an other developer will implement something else, or accept other patches, that is fine.