[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compile issues

From: Dave Love
Subject: Re: Compile issues
Date: Fri, 02 Apr 2004 19:14:10 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

address@hidden (Daniel Pfeiffer) writes:

>> ??  You may disagree that C-x ` is the normal interface implied by the
>> manual, but it clearly doesn't work.  I'm worried if it's non-trivial
>> to make it work.
> I had never said I couldn't make it work.  I was only discussing to
> find out what exactly people wanted.

If someone says they're `thinking about various remedies for this' it
sounds non-trivial.

> And by the time you wrote this, you'd already been informed that
> it's solved.


> Infos are all kinds of bla, like something creating a directory, or makepp
> telling you it's reading a makefile.  You can go to these things if you want,
> but that's not normally required.  If you generally want to go to these, set
> the threshold as described in NEWS.

That's not at all obvious, especially as it seems to be contradicted
by examples in compilation.txt (at least `gnu' and `ibm' entries).  I
assumed it covered messages like this from the DEC compiler, which I
realize are currently not recognized but should be:

cc: Info: <file>, line <line>: ...

> I'm not so good at custom, maybe I should tell it which options were added in
> 21.3.50.  Or should I make that 21.4, for whenever that may appear?


> And the Python messages I've
> seen are covered, so why have an extra python-compilation-mode (which woud be
> the modern alternative to compile-internal)?

I don't know what that means.  I used it like in the Warsaw version
(in a compatible command?), but I was also thinking of stuff isn't in
what I already posted.  If you load into a REPL and get errors, you
want to be able to jump to the source.  This isn't specific to Python,
though Python makes it harder than it might be.

[The Warsaw python-mode.el has a number of Emacs-specific issues for
which I've posted patches, but I don't think any of them ware relevant
in this context.]

> What's that?

<URL:http://www.erlang.org/>, but I don't think it matters; the issues
are similar for any system with a REPL.  [More Emacs-relevant
in Erlang are Distel and shbuf at <URL:http://www.bluetail.com/~luke/>.]

> I can find Erlang all over etags.c and as a symbol in
> simula-mode, but nothing else.  Again, if it's a compiler or interpreter, we
> should just add Erlang's messages to
> compilation-error-regexp-alist-alist.

I believe they're already matched by current patterns, but presumably
not in other (X)Emacs.  That's not the point, though (except insofar
as you have to be able to coexist with other versions of compile.el in
a clean manner in a portable package).  I'm not concerned with the
batch compiler here, just compilations from the REPL -- or evaluations
in the case of Python.

> OK, so how precisely can I help you to help?

Perhaps understand that there are real issues with these changes and
their documentation and that if I don't understand something about
them, I doubt most users will.

Erlang is one of those rare languages -- like Lisp, APL, Snobol,
Prolog, ML -- that is worth looking at for its excellent ideas.
   -- Scott McKay

reply via email to

[Prev in Thread] Current Thread [Next in Thread]