Re: map-extents and narrowed buffer
Hrvoje Niksic <[email protected]>
| Newsgroups | gmane.emacs.xemacs.design |
|---|---|
| Message-ID | <[email protected]> |
Kyle Jones <[email protected]> writes: > Hrvoje Niksic writes: > > I've just noticed that (map-extents FUNCTION nil nil nil) maps over > > the extents in the whole buffer, not only the narrowed portion. > > > > I wouldn't argue that it's a bug, but it certainly surprised > > me. > > Me too. But I think it works that way to match the behavior of > make-extent and set-extend-endpoints which both allow setting the > start/end position of an extent outside the clipping region. I get that, but why does that have to imply that nil endpoints don't default to the narrowed range? The following describes the cases the code was designed to handle (I think): ;; Assume (point-min) == 1, (point-max) == 100 (save-restriction (narrow-to-region 30 60) ;; [1] Should map in [30, 60) because narrowing is in effect. ;; Currently maps in [1, 100). (map-extents function nil nil nil) ;; [2] The same as the above. (map-extents function nil (point-min) (point-max)) (map-extents function nil 30 60) ;; [3] Explicitly set non-default endpoints work when they're within ;; the accessible portion. (map-extents function nil 40 50) ;; [4] But they also work outside the accessible portion. (map-extents function nil 20 70) ;; [5] However, specifying bogus values signals an error. (map-extents function nil 0 150)) I seriously doubt that there's any code that actually depends on the current behavior of #1. In fact, there might even be bugs lurking with functions that misbehave in strange ways iff narrowing is in effect. Investigating one such bug in my own code is exactly how I discovered this.