[Top][All Lists]

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

Re: Compile issues

From: Daniel Pfeiffer
Subject: Re: Compile issues
Date: Sun, 4 Apr 2004 11:33:57 +0200


Dave Love <address@hidden> skribis:

> 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.
> ??

What "??"?

> > 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

But I'm thinking about a new C-u 1 C-x ` feature, with an additional
"P" arg, which would mean not to skip anything.  Or maybe just use the minimal
threshold, i.e. none.  Maybe the var list for let should be configurable, so
people can make this not skip what they want.  It's a bit awkward to type, but
would save having a non-skipping variant of each moving command (which would
be awkward to remember).

> 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>: ...

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

> > 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?
> 21.4
> > 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.

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

> 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.  I'm
thinking of switching executable-interpret to comint + (a to be defined)
interpretation-minor-mode, similar to compilation-minor-mode.  This might have
a restricted alist, for only interpreter messages, and would not say
-*-compilation-*- when it isn't.   This should work for any REPL.

> This isn't specific to Python,
> though Python makes it harder than it might be.

What's so hard about the Python messages?

> > 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).

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 hope they'll catch up some day...

As for backward compatibility, that's always quite awkward, all the more with
XEmacs.  CPerl-mode is a "nice" example of this.

> > 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.

That must be a new definition of "precise" ;-)  Luckily only power users need
to get into the internals.

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

lerne / learn / apprends / läramå / ucz się    Esperanto:

reply via email to

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