David Kastrup <[EMAIL PROTECTED]> writes: > If INTEGERS (the optional first argument) is non-nil, always use > integers (rather than markers) to represent buffer positions. In > this case, and if the last match was in a buffer, the buffer will get > stored as one additional element at the end of the list. > > Notice the last sentence. This keeps the description for Element 2N > and Element 2N+1 valid. > > I think that, if at all, the evaporate thingy should also occupy the > last element on the list rather than the first. We got enough > inconsistency already as it is.
That's probably a good idea -- I'll give it a try. > >>> Should not (match-data whatever '(evaporate marker1 marker2 ...)) >>> also clean up the markers passed in for reuse? >> >> It should, yes. Currently, it just reseats the markers on the list. > > Oh, it does? I thought that it just recycled the CONS cells, but not > the markers. It used to do that, but my patch changed it to reseat the markers. 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. > >> 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. -- 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
