Thread: "Fast Forward" links don't seem to be correct

If you go to a regular, non-chapter-heading page in the PG docs, such as
http://developer.postgresql.org/pgdocs/postgres/extend-type-system.html
and try the "Fast Backward" link, it goes to that chapter's heading
page, which seems reasonable.  But the "Fast Forward" link points to
the same place.  Shouldn't it lead to the *next* chapter, instead?

This seems to be the case not only in HEAD, but for all the on-line
release versions since 7.4 (the first to have these links).

            regards, tom lane

Tom Lane wrote:
> If you go to a regular, non-chapter-heading page in the PG docs, such
> as
> http://developer.postgresql.org/pgdocs/postgres/extend-type-system.ht
>ml and try the "Fast Backward" link, it goes to that chapter's heading
> page, which seems reasonable.  But the "Fast Forward" link points to
> the same place.  Shouldn't it lead to the *next* chapter, instead?

It probably should.  The stylesheet code, however, doesn't seem to make
any attempts about it:

(define (next-major-component-chunk-element #!optional (elem (current-node)) (in-chain #f))
  ;; Return the next major component of the document that is not a descendant
  ;; of the starting element.  This is essentially 'next-sibling' but skips
  ;; over things that aren't chunks.
  (if (or (navigate-to? elem) in-chain)
      (if (member (gi elem) (major-component-element-list)) ; <--- It's a chapter or other major chunk.
          (if (node-list-empty? (node-list-first-element (follow elem)))
              (next-major-component-chunk-element (parent elem))
              (let ((nd (node-list-first-element (follow elem))))
                (if (navigate-to? nd)
                    nd
                    (next-major-component-chunk-element nd #t))))
          (ancestor-member elem (major-component-element-list))) ; <--- Else picks ancestor (should pick something
afterancestor). 
      (empty-node-list)))

I tried to change that but my first attempts seem to make the build take
forever.  I'll play around with it some more.

At least I think that's where it's happening ...

--
Peter Eisentraut
http://developer.postgresql.org/~petere/