To say I fully understand what is going on here would be a mistake, but below are my thoughts on it. I’d appreciate being told how I am wrong! :-D
…it’s important to point out that it works,mainly, because the Find All in files operation, scans each file, from its very beginning to its very end, and only that way!
I agree. But then in your post you change it up and start talking about Find Next instead of one/all of the file-level searches (Find All … / Find in Files). And that’s where I start disagreeing. :-)
place the caret right after the upper letter U. This time the search wrongly gets a match, from the caret location till the very end of file ! And if caret is located, at any position, further on, you get a match although it shouldn’t
I disagree. I think the match here (and at any caret positions farther downward in the file) is correct.
So perhaps a key thing here is how \A functions when used with a search function that does NOT operate at the file level. Let’s take a simple example. Put the caret on the U in Use from @guy038 's example above (the change.log file). From there do a Find Next (downward direction) on the regex \A.. It matches the U even though \A is supposed to only match at the start-of-file. Why is this? Well, Find Next always starts at the caret, and the Boost regex function that eventually gets called knows nothing about the file, it just knows about a string of data to be searched–and that string in this case is whatever is at the caret position and extending through the end-of-file. Thus to the Boost function the U is the start of the string to be searched. So the \A assert matches and the . matches the U.
…and despite, Scott, of the Wrap around option which, internally, forces N++ to scans file, from its very beginning to its very end ???
The forcing you mention is only for the Replace All case with Wrap around ticked. However, above you were talking about Find Next instead, which, when Wrap around is ticked and direction is downward, MUST search from the caret to end-of-file, and then, if a match is not found there, a second search is done from the beginning-of-file to the original user caret placement position. Note that two “internal” searches may be done for only one “user” search. Side note: The Replace-All with Wrap-around search behavior is discussed in more detail here.
Note that, for the current discussion of Find Next, the Wrap around option could be ticked or not, it doesn’t matter or change anything relevant to the use of \A.
I’m also disturbed because, in the Find result panel, it displays, only, the first line of files, which do not contain the string Use API site scope, although it logically matches all the file contents
This does not disturb me at all. :-D
Anytime there is a multi-line match during searching, only the first line gets written to the Find-result panel. When Use API site scope is not present in the file, the regex matches the whole file contents (as you said), which given a non-trivial file, would be multi-line data…and only the first line is properly put in the panel.