David Kastrup <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Kim F. Storm) writes: > >> In any case, I didn't find any code which actually uses the REUSE >> form of match-data, so that feature is pretty obscure already, so I >> think we should just keep the original behavior of the REUSE arg. > > Look at replace-match-data in replace.el...
I see. But that doesn't contradict my feeling that match-data doesn't have to do anything special about markers in REUSE. But we could make an optional arg RESEAT to match-data which causes the markers in REUSE to be reseated to nowhere (if t), or be freed if RESEAT equals `evaporate'. > > I think it was me that did that piece of prescient paranoia. > >>>> In any case, to me, the match-data interface should not be >>>> considered a user-level feature _at all_. >>> >>> There is no other interface into the number of accessible match >>> strings (which might be nil) rather than >>> (/ (length (match-data t)) 2). >> >> That's still pretty inefficient -- I suggest that we introduce a new >> function `match-count' to return that number. > > No objection here. No idea whether match-size would be more > appropriate. The C code is not really helpful deciding about that > since it uses search_regs.num_regs and that is not suggestive of any > sensible Lisp name. IMO, match-count is better than match-size. BTW, match-count != search_regs.num_regs, as match-data only returns elements up to the last successful submatch. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
