Julian Bradfield writes: No. Neither extents nor their endpoints are markers, and markers are not extents. Extent behavior with respect to swallowing text inserted at an endpoint of the extent is entirely determined by the start-open and end-open properties of the extent. Markers do not have such properties, so the only way to get different behavior (ie, inserting text at a marker pushes the marker toward the end of the file instead of toward the beginning) is by changing the function call, which is why `insert-before-markers' exists. There are clearly applications where it makes sense for extent and marker behavior to be distinct in this respect (eg, in font-locking you don't want to have to fiddle with the openness or closedness of an extent depending on the kind of insertion you're doing). Do you have an application where you'd like it to work the other way around? Or is it incompatible with That Other Emacs? As for why this isn't documented, it is documented.<wink/> The documentation of `insert-before-markers' doesn't mention extents, so `insert-before-markers' should be assumed to have the same behavior as `insert' with respect to extents. I suppose we could add an explicit caveat to the docstring, though, as it's not necessarily intuitive that extent and marker behavior are not linked to each other. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Julian Bradfield writes: Sure. In most applications I can thing of, though, there would be an "inert" separator such as "|". So the picture I would expect is [xxxxx]|[yyyyyy] (where the square brackets are metacharacters indicating closed extent endpoints and are not displayed). In fact, you could wrap the separator in an invisible extent, but that would be a little weird for users. In many others, the "natural" arrangement would be start-open, end-closed (aka append-only extents). There's also explicit set-extent-endpoints, and the insert-then-delete dance. Does VM really sometimes insert and sometimes insert-before-markers at the same place? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Julian Bradfield writes: Erm, but translated to XEmacs and using an extent `e' instead of two markers, that's just ;; at initialization of the extent ;; for this to work the extent must not include the newlines (set-extent-property e 'end-open nil) (set-extent-property e 'start-open nil) ;; on each update: (let ((start (extent-start-position e)) (end (extent-end-position e))) (goto-char start) (delete-region start end) (insert updated-summary-text)) There are other ways to accomplish the same end with different settings of extent closure (but they require inserting first, then deleting). The requirement that the newlines be outside of the extents is a bit delicate, but the dance around the markers is a bit ugly, I think. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Sorry, ignore me. That's exactly what you did do. For some reason I didn't see what was in front of my eyes! But yes, it does require there to be a separator newline between the two summary entries. Then you'd have to special-case that in order to work out which message is selected by the summary cursor when it's between extents. VM of course isn't going to use extents for this anyway, because it has to work with fsfmacs, and mainly with fsfmacs - VM XEmacs users seem to be in a small minority of VM users. It's just my add on that uses extents, because it's much easier, and I don't care about the non-XEmacs users;-) So I guess for my purpose it would have worked to set extents that were double-closed, as you suggest, from start to end-1 - provided I'm willing to assume that in practice the summary format will always end with a newline, which is not actually required by VM. I didn't think of that! _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta