Yes, I see it now. I only tested it with multiline blocks. But I find
that behaviour a bit illogical. Why should the search dialog suddenly
use the block as default (instead of the text at cursor) only because
it consists of one line only? That makes no sense. I would want to use
the text at cursor in *all* cases (independent from persistent blocks)
because I may not even be aware that a block is still active. This way
I have to think about this side effect whenever I use the search
function.
I don't disagree.
I just pointed out, that nothing changed. For non persistent blocks, it
was ok to use the block, and since you usually not search for multi line
strings it was ok to limit it to one line blocks.
So the behaviour is the same for persistent and non-persistant blocks? I
may see a merit in having this default for non-persistent blocks
(because in general there will be no block selected when starting the
search function) but for persistent blocks it's a nightmare.
For persistent, I would actually think the past was to limit it to
one-line blocks, but only if the cursor is IN or AT the block
I think that this is trying to be too smart. Users have problems to
consider such side effects. KISS would be better here (Keep It Simple
and Stupid). It should always work predictable without doing lengthy
thinking.
There are many reasons why a block is selected when start searching for
something (especially in persistent mode) so it's not a good idea to use
it as default at all (independent from whether it's a one or more line
block). I think the way it was in Turbo Pascal was the best. If a user
wanted to search for text from the code he could simply put the cursor
on a word and the search dialog took it as default (no need to think
about current block definitions). With Shift+CursorRight the default
could even be extended.
So my wish would be to switch off using the block as search default (at
least in persistent mode). Maybe one day I am able to do such things
myself but currently I am still learning about Lazarus/Free Pascal.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
