Another slow restart on folding: First question: Searches done in a specially constructed string?

[Randy Kramer]

Tony,

Thanks very much!

All,

A followup question and some ruminations below.

On Tuesday 05 August 2008 02:22 pm, Tony Balinski wrote:
> That's what it did do (5.5).  Now it provides a pointer to the text in 
> the document's buffer. Since the search routines expect a contiguous
> string and the buffer provides a gap to allow insertion of new text
> at the insert point, the gap is shuffled to one of the two extremes
> (whichever is closest to the gap before the shuffle) before returning
> a pointer to the document's first character in the buffer.

Reading between the lines, I'm guessing that the nedit search routines would 
work reasonably well with any string "passed" to them by a pointer.  Is that 
reasonably close to true?  

(Among my reasons for that guess are that search macros can search an 
"arbitrary" string "passed" to the search macro.)

The reason I ask is that I would expect that when folding is implemented, the 
user will have the option to search the entire document *or* just the parts 
of the document still visible while the document is folded, so I was 
anticipating the need to be able to create two different search strings.  

Hmm, just had another thought, though--to avoid problems with anomalous 
results across the boundaries of visible sections of text separated by 
invisible (folded) sections of text, maybe all searches have to be done in 
the full document, and then, if the user is seeking results only in the 
folded document, a followup filter would screen out any hits that aren't 
(fully) visible in the current folded view.  That sounds more correct, 
although a little more work.

Randy Kramer