compile.el's recomputation of locations for omake

[Stefan Monnier]

I'm having some trouble with the timestamp business that you introduced
to try and handle the "omake -P" case.  Could you help me understand
exactly which scenario it's trying to handle?

Some more specific questions:
- The comment says:

;; Once any location in some file has been jumped to, the list is extended to
;; (COLUMN LINE FILE-STRUCTURE MARKER TIMESTAMP . VISITED)
;; for all LOCs pertaining to that file.
;; MARKER initially points to LINE and COLUMN in a buffer visiting that file.
;; Being a marker it sticks to some text, when the buffer grows or shrinks
;; before that point.  VISITED is t if we have jumped there, else nil.
;; TIMESTAMP is necessary because of "incremental compilation": `omake -P'
;; polls filesystem for changes and recompiles when a file is modified
;; using the same *compilation* buffer. this necessitates re-parsing markers.

  but it doesn't explain what data is stored in TIMESTAMP.  Is it the
  timestamp of when the location was visited by the user, or the
  timestamp of when all the locations of the file were turned into
  markers, or ...?

- As far as I can tell, the code first turns all the locs from (col
  line file) to (col line file marker), and then the locs that are
  visited (and only those) are extended with the additional (timestamp
  . visited).
  Is that on purpose?  Is it right?

- The code does:

    (setcdr (nthcdr 3 loc) (list timestamp))
    (setcdr (nthcdr 4 loc) t)))         ; Set this one as visited.

  But AFAICT, this is identical to

    (setcdr (nthcdr 3 loc) (cons timestamp t)))) ; Set this one as visited.

  So the VISITED part seems unnecessary, since TIMESTAMP is only non-nil
  when visited is non-nil, IIUC.

- The time-check used to decide whether to recompute the locations looks
  at the TIMESTAMP entry, which will be nil for any not-yet-visited
  loc, AFAICT.  So we'll end up recomputing the locations pretty much
  every time, except when the user visits a location she
  already visited.  Am I missing something?

- The compilation-buffer-modtime used is changed whenever the
  compilation process outputs something.  That means that for a traditional
  (not "omake -P") compilation, if you visit an error before the process
  is finished, it will be recomputed if you try to visit it again later.

Basically, I think we should rethink this approach.  One venue that
seems more promising would be if omake outputs some special text
whenever it starts a new compilation, which we could recognize to mark
subsequent locations for recomputation.


        Stefan