page anchors

[Boruch Baum <boruch_baum@xxxxxxx>]

The huge merge of last year still has me hamstrung because of all the
non-Xemacs stuff stuck in, so I'm still catching up. After what I'll
call the --xemacs++ merge, there were three emails to
written to the list in Japanese:
  13526 Hideyuli SHIRAI
  13528 Katsumi Yamaoka
  13533 Katsumi Yamaoka


1] I don't understand the Japanese, or what SHIRAI-san's patch was
   doing, but one of the actual changes made to the code undermined the
   rationale I had for the feature `w3m-search-name-anchor', which was
   to allow quick navigation among a page's headings and sections,
   without being burdened by having to scroll through each and every the
   footnote anchor, or other anchor.

   The patch that was applied was very different from what was in the
   email, and altered the data structure of
   `w3m-anchor-list-filter-alist' in a way that I like in principle (it
   is a good and potentially useful additional feature), but it is used
   in a way that undermines use of `w3m-search-name-anchor'. If you
   compare using M-x w3m-search-name-anchor for any medium or long
   wikipedia page, with and without the patch, you will immediately see
   the difference, especially if you are using ivy or helm or ido. The
   patch causes all the footnote references and minor annotations to be
   included instead of just the headings and anchors suitable for a
   table of contents.

   If you all agree, I propose keeping the feature, but deleting the
   particular example from the default:

     (defcustom w3m-anchor-list-filter-alist
       '((".*" . "\\`cite_.*[0-9]\\'")
         (".*" . "\\`mw-head\\'")
         (".*" . "\\`p-search\\'"))
     etc.

2] Does the patch to function w3m--get-page-anchors really accomplish
   anything in practice? My memory of when I was testing it was that in
   practice anchor2 had nothing useful beyond what was already in
   anchor. If the purpose of the patch was to exhaustively collect every
   single anchor, that defeats the purpose of being useful, because so
   many of the anchors are for footnotes and other minor things, not
   headings or items for a table of contents index.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0