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

[Stefan Monnier]

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

So the code seems to have bug since it only sets the time stamp on the
locations the user actually visits.

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

Yes, it's a problem because:
- the reparse is not needed (we're presuming a traditional compilation,
  so reparsing is never needed).
- more importantly, in case the user has edited the buffer in the mean
  time (adding/removing lines), the reparsing will end up using
  incorrect line numbers that don't take into account the lines
  added/removed whereas the markers that were present before the
  reparsing did take that into account.  So the reparsing is not only
  a waste of time, but it also worsens the behavior.

>> Basically, I think we should rethink this approach.
> maybe.  I am sorry my approach did not work out.

No need to be sorry.

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

Thanks.  I'll disable it via a `compilation--omake-hack' variable, then.


        Stefan