[Lazarus] Persistent Blocks and Search, revisited

[Martin]

On 15/09/2012 12:35, Jürgen Hestermann wrote:
>
> > 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.
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)

> > 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.
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.