Re: Compile issues

[Stefan Monnier]

>> I'm not sure I understand the above.  Have you submitted a python-mode
>> package here in emacs-devel?
> No, to gnu-emacs-sources.

OK, well I missed it, then.  I think that if you want it included in Emacs,
it's best to send it to emacs-devel.  Things I see on gnu.emacs.sources
I generally assume that the author does not (yet) intend to include it in
Emacs (and I sometimes mark it "look into it if you have time" if I think
it should be part of Emacs or that some part of it should be merged in.
In the case of python-mode, I seem to remember that the mode by Barry was
deemed "best left with the Python package", so I tend to not consider these
things to be directly relevant to Emacs).

>> I think in this case (and most others), what does help is a concise but
>> precise bug-report.  I still haven't seen that about your
>> erlang-mode code.

> I don't understand how what I said about `next-error' wasn't concise
> and precise enough.  Usually I get told off for being too concise.

Well, I didn't notice that your issue w.r.t erlang mode was the same as your
issue about next-error's optional argument (or the fact that C-x ` failed to
work at all before something like M-x first-error).  If that's all there
was, then it's fixed and thank you for reporting those bugs.

But I thought there was more to it.

> I thought I'd also been clear as clear as possible about
> missing/confusing documentation and rms agreed with at least some of
> that.  However, it's difficult to be clear about things I don't
> understand or know about.

<please-ignore>
I get the impression that your original message was:
- a few good bug-reports
- a whine about the new compile.el which was ill-advised since it assumed
  that the above bugs were considered as features and would thus never be
  fixed.  But I mistakenly interpreted this whine as a very vague bug-report
  about something not working quite right in some unknown package which does
  things you didn't explain.  Sorry about my misunderstanding you.
</please-ignore>

> I do understand the i18n and compiler issues.  Was that unclear?

I can't remember what you're referring to.

>> Of course, maybe you'll be able to fix your erlang-mode code,
>> but I think it would be better if it's not needed (and I assume you
>> agree),

> No, I don't agree, unless you provide a general facility for dealing
> with errors in REPLs (which I'll try to abstract if I ever get it
> working with the new scheme).

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?

>> so if you could explain to us what does erlang-mode do that
>> breaks with the new compile.el, maybe we can improve compile.el's
>> backward compatibility to cover this case.

> What it does in the released version is broken in Emacs 21.2 anyhow.

Once more, I have no idea what you're referring to.

> I fixed that by having it use `compilation-minor-mode' in the inferior
> buffer and sent a patch.  This simply fails to find any errors with
> the development Emacs.  I don't know how it's broken or whether it's
> possible to make it DTRT now.  That's all I can say until I have time
> to digest the new compile.el completely and/or do enough debugging.

If you tell us what the user does, how Emacs-21.2 behaved, how the new
compile.el behaves, and how Emacs should behave instead, maybe we can try
and fix it for you (or help you fix it at least).

> The released erlang.el at least:

> * Redefines C-x ` to a command which calls next-error (with no arg);

> * Calls compile-internal;

> * Sets compilation-error-regexp-alist, compilation-parsing-end,
>   compilation-error-list, compilation-old-error-list and
>   compilation-last-buffer.

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 to see whether my
pending fix will work.
Support for copmpilation-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.


        Stefan