font-lock-mode:correction-to-previous-report

[Luc Teirlinck]

The bug I previously reported is real and the fix I described works.
Nevertheless, the situation is not as totally obvious as I previously
thought.  Since it is not obvious, I probably do need to describe an
example of the bugs involved.  Go to a Dired buffer, make sure it
contains a directory, include some files of both larger and smaller
size in front and behind the directory.  (You probably already have
Dired buffers that fit the description and the little experiment will
not harm them.)  Put the buffer in font-lock-mode, but make sure not
to add a support mode.  Use C-x C-q.  Put mark and point around the
actual files (i.e just omit the headers).  Now try to sort the files
by size using M-5 M-x sort-numeric-fields.  Result:Invalid search
bound (wrong side of point).  There is nothing wrong with the
sort-functions, font-lock-mode is the culprit.

I refer to my previous report for the details on what is going on.
The reason for this addendum is that I now believe that there actually
is a good reason for font-lock-fontify-anchored-keywords to move point.
It has to do with the efficiency when called from its main caller.  As
mentioned before one pays for that efficiency by having the caller
malfunction.  Not a good deal.  However, the save-excursion solution
may actually be unnecessarily radical and inefficient.

The solution given by the attached context-diff has the following
advantages over the previously proposed solution:

1.  I believe it is more CPU-time efficient, although I did not actually
    time anything.

2.  It is minimal.  I am pretty sure that it will not introduce other
    bugs by getting rid of the described one.  I do not believe my
    previous solution did either, but I am less confident there.

One could add a little line to the documentation string of the two
functions warning people that they can move point and that, if this is
undesirable in their programs, they should use a save-excursion.
(This is NOT included in the attached context-diff).  I believe the
enclosed fix takes care of the internal font-lock.el problems
resulting from that fact. I am not sure of that, however and the
previous solution is more robust in dealing with potential further
point-move-related bugs caused by these two functions.  Maybe somebody
who knows font-lock.el better than I do could take a look at this and
decide which of the two (or maybe a third) solution is better.  I lean
towards the one described here.

On the other hand, why is MATCH-ANCHORED (the cause of all this
trouble, but nevertheless a powerful tool) not described in the
Emacs21 Elisp manual?  Are the problems I am describing well-known and
is that the reason?  Just in case they are not, the context-diff:

cd ~/
diff -c /home/teirllm/elisp20.6/font-lock.el /home/teirllm/font-lock.el
*** /home/teirllm/elisp20.6/font-lock.el        Thu Oct 21 16:32:19 1999
--- /home/teirllm/font-lock.el  Thu Dec 21 14:45:28 2000
***************
*** 1452,1458 ****
          (if (numberp (car (car highlights)))
              (font-lock-apply-highlight (car highlights))
            (font-lock-fontify-anchored-keywords (car highlights) end))
!         (setq highlights (cdr highlights))))
        (setq keywords (cdr keywords)))))
  
  ;;; End of Keyword regexp fontification functions.
--- 1452,1459 ----
          (if (numberp (car (car highlights)))
              (font-lock-apply-highlight (car highlights))
            (font-lock-fontify-anchored-keywords (car highlights) end))
!         (setq highlights (cdr highlights)))
!       (goto-char (min (point) end)))
        (setq keywords (cdr keywords)))))
  
  ;;; End of Keyword regexp fontification functions.

Diff finished at Thu Dec 21 15:10:56