Re: help: adapting your library to new M-x compile

[Stefan Monnier]

>> >     - diff-mode.el:
>> >     A cleanup is included in my compile.el.  The question is why this
>> >     needs compilation-minor-mode at all, only to override its commands?
>> So that C-x ` can be used, but I think it's turned off now.
> For the cases where guessing the changed line number fails?

No: for the case where the user wants to use C-x ` (from a non-diff-mode
buffer) instead of going into the diff-mode buffer and using M-n.
Ideally, the C-x ` would end up using diff-mode's jumping function (i.e.
the same code as run by M-n in the diff-mode buffer), but the current
compile.el does not provide any way to do that.

But note that it's not so easy: when I made C-x ` aware of diff-mode
buffers (by making those buffers use compilation-minor-mode), people
complained because a C-x v = suddenly made C-x ` jump to the next diff
rather than to the next compilation error in their *compile* buffer.
So I changed the code to preserve compilation-last-buffer, so C-x ` doesn't
actually work any more.  Basically, the compilation-minor-mode support in
diff-mode has been slowly disabled piecewise to the point where it now is
almost 100% disabled.  Given the fact that the support was suboptimal to
start with, we're better off just removing the leftover.

>> >     Even though the concepts don't quite fit, it might be interesting to
>> >     derive diff-mode from compilation-mode and let that do the parsing.
>> 
>> No, because it's not line-number based but text-content based: diff-mode
>> assumes that the file might have changed since the diff was generated and
>> only uses the line number as a hint.

> Yes, but it could use the text-properties compile sets, for its hint.
> It would only need different goto commands.  Mine could be tweaked such
> that yours could hook in.

That's possible.  Obviously, the feature-set of compile.el and diff-mode
have a lot in common so there should/could be some sharing, but when
I looked at it, it seemed too difficult and with unclear benefits.

The only way I can think off to move forward on this is to list the
potential real benefits and then to see how to get them.

> I guess the reason it's there is that your parser doesn't work on the fly.
> That's where my idea to base this on compile, i.e. font-lock, comes from.
> Then it'll work both on a diff file and on an ongoing command.

No, the current code is already very much on-the-fly.

> As happened in compile this would mean eliminating a good part of what's
> there in diff-mode as well as almost all of diff.

Yes, diff.el could basically disappear.  But most of diff-mode.el is about
providing ways to turn a -c diff into a -u diff, or to reverse the direction
of the diff, or to allow editing of a diff hunk and automatically update
the hunk's header, or to apply a hunk, ...

> My only problem is what to do with the primitive diff options that don't
> give file names?

I thought compile.el already had code to handle such cases
(i.e. error messages that do not include a filename and where the previous
message that gives the filename might be missing).  If not, it
probably should.

To sum up: as far as compile.el is concerned, backward compatibility for
diff-mode.el can safely be ignored, and backward compatibility with diff.el
is not too important either.


        Stefan