Re: compile.el's recomputation of locations for omake

[Sam Steingold]

On Thu, Jan 27, 2011 at 9:28 PM, Stefan Monnier
<address@hidden> wrote:
> 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?

I can try, but I no longer use it and I am not planning on resuming...

> 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 ...?

timestamp, IIRC, is the time when we last parsed the compilation
buffer and set up pointers to the source code.

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

maybe...

> - 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.

yes. is this a problem?

> Basically, I think we should rethink this approach.

maybe. I am sorry my approach did not work out.

> 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.

it certainly does (but I don't remember what).

It might well be that this whole thing should be dropped altogether.

I wrote it when I worked for a company which used omake for its build process.
we were quite unhappy with it and they might be switching away from it now.
omake is buggy, leaks memory like crazy, has obscene start up time
(which is why "-P" was introduced)
its development was stuck at v. 0.9.8.5 for 3+ years (until 0.9.8.6
was released a couple of months ago).

I am no longer sure this feature is worth supporting - but I am not
sure it is worthless either.
It is your call.

-- 
Sam Steingold <http://sds.podval.org>