Quoting Randy Kramer <[EMAIL PROTECTED]>: > 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.)
It can be used this way and is for search_string/replace_in_string macro built-ins. > 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. Could be done with the document's buffer by using the gap area as placement for the null terminator, I suppose. > 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. -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
