[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
compile.el's recomputation of locations for omake
From: |
Stefan Monnier |
Subject: |
compile.el's recomputation of locations for omake |
Date: |
Thu, 27 Jan 2011 21:28:49 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
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
- compile.el's recomputation of locations for omake,
Stefan Monnier <=