Re: new style Emacs compile

[Daniel Pfeiffer]

Saluton, Moin,

Stefan Monnier <address@hidden> skribis:

> > Backwards compatibility compilation-error-regexp-alist for compile.el is
> > desirable, but I don't think it is essential.  Not that many users
> > customize it.  It would not be a disaster if they had to make a change.
> 
> I agree that the case where the user has changed the value is rather
> unimportant, but I know of several unbundled elisp packages which change it
> to support a particular related tool.  My sml-mode is one such example which
> will be fixed pretty promptly, but there are many more.

My structure mostly adds variants, i.e. file, line and maybe column can also be 
lists rather than indexes.  The tail has changed.  Where the formats were 
before there are new elements, while the formats will go into the file-list 
(because they pertain to the file name).  This means that for all matchers not 
using the secret function-feature or formats the compatibility is given.

> > Can you put a rule for this in words?  Or maybe someone can explain the
> > idea behind the existing TeX message parser to me?  Is it adequate at all,
> > or does it fail in 30% of messages containing a ')'?
> 
> The current parser in tex-mode.el fails so often (for me anyway) that
> I never use it.  I have worked on fixing it, but it's not ready for
> install yet.  Furthermore, my "better" tex-mode parsing is done in elisp,
> not via error-regexp-parsing.

This doesn't help.  If nobody can say what to look for, Emacs can't look for 
it.  I've asked on the TeX newsgroup and got one disheartening reply so far:

] If you want to avoid reinventing the wheel, take a look at how AUCTeX does
] it. In short, it is quite nontrivial.  Actually, AUCTeX currently does a far
] worse job at parsing the error messages than preview-latex, so maybe the
] latter is a better example.  But the latter explicitly turns off a number of
] error message types in order not to get confused with a bit more
] reliability, so it's not the philosopher's stone either.

> >> Of course another way is to make the old sml-proc.el hack unnecessary.
> >> That would be preferable, indeed.
> 
> > I'll try to do that.  This will also be usefull for diff.  Diff has one
> > more challenge, in that I must altenate between two filenames.
> > Currently this is not done, but then the current diff command is not
> > really useful.
> 
> It'd be better to just change diff.el so it uses diff-mode.el
> rather than compile.el.  I don't think the alternating behavior is
> very useful (or convenient for that matter).

Oh yes, diff will surely use an enhanced diff-mode (like grep uses the new 
grep-mode).  By alternating behaviour I meant that in:

--- dir1/a      2003-11-10 09:23:58.000000000 +0100
+++ dir2/a      2003-10-22 22:27:32.000000000 +0200
@@ -3,11 +4,10 @@

clicking -3,11 would go to those lines in dir1/a while +4,10 would do the same 
for dir2/a -- and so forth however many difference groups there are.  And a new 
command could be configured like the -p option to patch.  I.e. it would know in 
which directory to find the file a corresponding to dir1/a.  Or more generally 
(also useful for remote-compile) there would be a translation function "when 
diff says dir1/a go to foo/bar".

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

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