Re: Compile issues

[Dave Love]

address@hidden (Daniel Pfeiffer) writes:

>> ??
>
> What "??"?

Because it doesn't appear to be true.

>> > 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).
>
> "Function foo is not referenced." is debatable.  Could be it's new,
> intended for a library or in a module bound to various executables.
> Could be dead code of course.  There is no way a simple parser can
> be more intelligent about messages than the emitter.  If they say
> it's only info, I have to believe them.

It is a message from the compiler which would correspond to a gcc
-Wall warning as far as I know.  As I said, it doesn't correspond to
the explanation above of what an `info' message is.  Please document
clearly what the criteria are.

> Thanks for the tip, I'll add this.  Do you have a convrete example?

Not off hand.

> Ok, first thing:  when Python is used non interactively, e.g. from within
> make,
> its messages are covered Afaict.

Ones like

  File "foo.py", line 10

aren't, and ones with `files' like `<string>' shouldn't be.

As far as I know, there isn't a distinction between command-line and
REPL messages, but I'm not an expert.

>> If you load into a REPL and get errors, you
>> want to be able to jump to the source.
>
> The optional "comint" arg to compile essentially already does this.

Not as I read its doc.  It appears to start a new process, not send to
an existing one.

>> This isn't specific to Python,
>> though Python makes it harder than it might be.
>
> What's so hard about the Python messages?

It's not the messages per se, it's input to the REPL that's
non-trivial.  However, that means that file names and line numbers in
tracebacks need transforming to find the source, and that no longer
seems to be possible unless I edit the comint output directly.

> Definitely an issue.  I had looked at their many changes to this mode, and
> copied some, e.g. symbolic names for the regexps.  I copied them in when I
> published this, but they never reacted.

I didn't mean Emacs should follow XEmacs or waste time trying to
cooperate with XEmacs maintainers.  I was commenting on what people
supporting external code are faced with, even for different versions
of Emacs 21.