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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.