basing diff on new M-x compile

[Daniel Pfeiffer]

Saluton, Moin,

Stefan Monnier <address@hidden> skribis:

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

Would be easy to call it via a hook, but I don't understand the benefit of 
this.  diff-mode looks good and works well.  So why have another way?

> Given the fact that the support was suboptimal to
> start with, we're better off just removing the leftover.

I have prepared a slightly modified diff-mode, which doesn't fiddle with 
compile (all removed).  But compilation-minor-mode can be turned on and works.

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

Not so many, except that things then work the same way.  But having diff change 
the last compilation buffer is a drawback which grep also suffers from.  
Someone had lately ripped grep out of compile.el and introduced a separate 
variable last-grep-buffer.  The snag is that it doesn't get used yet and I 
don't know how he wanted to make it be used...

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

Then diff.el is redundant and should just be replaced roughly by a trivial

(defun diff (cmd)
  (interactive clever command prompter)
  (start-process cmd)
  (diff-mode))

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

Currently, I expect a file name earlier in the buffer.  Changing that wouldn't 
be too hard, but it would bloat an already long function even more without 
clear benefit, until something really needs this.  From what you said above, I 
see no urgent need to rebase diff on compile.  And I'm aware of no other 
compiler-like command that doesn't give a file name at all.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå    Esperanto:
                              http://lernu.net/