Re: Compile issues

[Stefan Monnier]

>> In the case of python-mode, I seem to remember that the mode by Barry was
>> deemed "best left with the Python package",
> There is no assignment for it an it appears not to have Emacs support
> as a priority, shall we say.

Ah, so that was the reason.  Thanks.

>> so I tend to not consider these things to be directly relevant to
>> Emacs).
> I don't understand.  Shouldn't Emacs have a Python mode, especially
> one that's potentially better than the XEmacs one?

100% agreement (except I don't care much whether it's better than the one
in XEmacs).  Please send it to me and I'll install it.
BTW, it'd be best if you installed it yourself (you supposedly don't have
write access any more, but it shouldn't be hard to get it back).

>>> I do understand the i18n and compiler issues.  Was that unclear?
>> I can't remember what you're referring to.
> Various of the patterns presumably won't work with internationalized
> applications in locale fr_CH, for instance (I assume that `file'
> becomes `fichier', for instance) and it doesn't look as though they
> all work with non-ASCII commands and/or filenames.  I also commented
> on the classification and apparent redundancy of he patterns.

Oh, I see now.  Are these problems specific to the new compile.el or
where they somehow absent in the old compile.el ?
Given the current state of compile.el the priority is to fix the cases
where it works less well than before.

>> Again, I have no idea what you're talking about.  Or are you talking
>> about situations like the one of tex-mode where each compilation is done
>> in the same comint buffer?

> Probably more or less; I don't know exactly what either TeX mode does.
> Since it's a module compiler, I guess it's pretty much the same as an
> inferior SML REPL, but it's along time since I used one.  I assumed
> that sort of thing would be generally familiar.

Yes, it is.  In Emacs-21.2 there was no particular support for it and
packages hacked around with compilation-forget-errors and
compilation-parsing-end but it wasn't always satisfactory.
I intend to try and recover the Emacs-21.2 behavior first and then to
introduce a more principled way to support such use.

>> If you tell us what the user does,
> Types C-c C-k and then C-x `.

Where?  When?  After which other command(s)?

>> how Emacs-21.2 behaved,
> Found the error location.
>> how the new compile.el behaves,
> Says `No more errors yet' (with M-x first-error).
>> and how Emacs should behave instead,
> Find the error location.
> I doubt that helps.

You bet.  Looking at http://www.erlang.org/download/contrib/erlang.el (I
assume that's what we're talking about), I don't see anything that would
obviously break with the new code.  But maybe the problem is that the new
compile.el reads compilation-error-regexp-alist too early and doesn't
notice when erlang.el adds stuff to it.  Basically the problem is that in
the old compile.el the variable was only read when you hit C-x ` or
somesuch whereas in the new code it is read immediately when you turn on
the compilation-mode.

>> Support for compilation-parsing-end is in my local tree, but since its
>> semantics was unclear, I'd need to know how it's used
> It's used to avoid processing errors before that point in the buffer,
> reset at each compilation and possibly by the next comint input of any
> sort.

Well I guessed that much ;-) but that's *why* it's used rather than *how*
it's used.  Anyway, looking at the code, it looks like it'll work just fine
with my patches.

>> Support for compilation-error-list (via compilation-parse-errors-function)
>> is also upcoming, but I need more precision to know whether that
>> backward-compatibility stuff is good enough for Erlang.

> I think it's just used to clear out the errors from previous
> compilations.  I don't think there's anything Erlang-specific about
> this, and it would apply just the same to what cmuscheme should do,
> for instance.

Indeed.


        Stefan