Re: current compile.el issues

[Daniel Pfeiffer]

Saluton, Moin,

Dave Love <address@hidden> skribis:

> address@hidden (Daniel Pfeiffer) writes:
> 
> > I don't understand how you get to that.  How can you not build where the
> > source is?
> 
> I'm surprised.  See INSTALL if you don't understand the Emacs build
> process.  It's normal, I think, and actually required for some
> packages, even if you're not building for multiple targets at the same
> time.

Emacs build is one big hack.  I don't understand why I can't just cvs up &&
make.  So I really don't want to get into it...

> > Anyways, I don't think people need to load this file frequently.
> > So those few who know how to set up such disparate directory structures,
> > will be capable of typing the right file name at find-file.
> 
> Using `doc-directory' instead of `data-directory' is simply a bug.  I
> don't understand refusing to fix things like that.

The file doesn't contain data but documents compile.  So it uses the "right"
variable.  If using the "wrong" variable solves this without creating new
problems for other kinds of builds, feel free to change it.

> >> I don't find the fringe arrow very helpful, especially if there's no
> >> fringe!  It's also not the behaviour I've been used to for many years.
> >
> > Well I guess, I'll revert the fringe arrow and do an overlay
> > instead.
> 
> The arrow does no harm when it can be displayed.  The behaviour I'm
> used to is putting the error at the top of the window.  (I'm also used
> to tty mode for various reasons.)

RMS and Stef Monnier seem to favour 0 lines and no overlay, so I'll leave this
as it is now.  Anybody with energy to add an overlay that won't get in the way
visually, can take a go.

> > When building a huge project, it shows you at a glance what make is doing
> > at that point.  I find this very useful when scrolling through the
> > buffer,
> 
> But I don't, which is a reason to allow it to be customized unless I'm
> quite unusual.

The problem is a general one about customizing font-lock-keywords.  Just
defcustoming a list that requires lisp knowledge won't help anybody.  Those
who
know what to do with it, can easily setq in .emacs.

For the others someone will have to think up a clever way of making this
simple and generalize it for all kinds of font-lock-keywords.  Maybe the way I
did this for compiler messages could be an inspiration.

> >> I don't know when that's an issue.  Not, as far as I know, with the
> >> systems I use.  Unfortunately it seems only Stefan and I understand
> >> this mode of working.
> >
> > Tha Ada compiler and makepp example show several messages on a line.  Why
> > wouldn't other people understand that?
> 
> I don't understand what that has to do with compilation-minor-mode for
> inferior REPLs.  I certainly don't understand anything about running
> Ada like that, and I'm surprised it's possible.  I don't know what to
> make of those compilation.txt examples anyway, actually.

Well I don't know what your point is.  Your answer about Stef and you replied
to my comment about multiple messages on a line.  You had crippled this
comment of mine in your reply (Wed, 28 Apr 2004 15:13:44 +0100) so I restated
it, to know what we were on about.  Apparently you meant to answer something
else.  Could you please restate the problem?

As for the examples, they have built up over the years, and I simply inherited
80% of the from the old compile.  At least now Joe User can visually match
them to what he's seeing from his compiler and choose the right ones.

> > I don't understand why this was introduced either.  But if you define your
> > own, replacing the one the (minor) mode installs, you'd better know what
> > you're doing ;-)
> 
> I'm not, but the doc seems to be saying I should.

I had suggested compilation-(shell-)minor-mode should, because you said, you
only wanted something solved for comint + compilation.  But I think Stef is
more aware of the comint things than I am.

> > Sure the world will never agree on the precise meaning of words.  Nor will
> > constantly shifting C++ standards.  There's no way I can put semantics
> > into a regexp.  I just believe the compiler.  But at least I give you a
> > chance to tune it to your understanding of your compilers.
> 
> You must have some idea what it means which can be written down, or
> the concept is quite useless and should be avoided.  You obviously do
> give semantics to regexps in the regexp alist, and those are even
> fuzzy, as in the case of `file' fields which don't correspond to files
> but to streams.

If a compiler chooses to use some special notation (e.g. STDIN:8:9:) exactly
like it does filenames, this gets very specialized.  This might be a strange
filename...  The whole thing is only heuristic, and I don't think you can get
100% of the messages parsed the right way.  It'll ask you where to find STDIN,
and you can just C-g C-x `.

> Previously you implied that informational wasn't
> meant to cover compiler messages.

No, you must have misunderstood me.  I only say that if a compiler labels a
message as informational, it's likely not something you need to visit, at
least not every time.  But, so you can visit it if you want to, it is of
course parsed.

> If it does apply simply to compiler
> messages, then distinction between warn and info doesn't appear to be
> helpful, per my example.  It definitely isn't helpful if no-one knows
> what the distinction is meant to be.

The same thing applies to error vs. warning.  Many developers are simply
annoyed by warnings, some of which can't even be remedied.  Then you pass the
code to a different architecture, and the compiler sees the same thing as an
error...

What's the good of picking on compile, just because every compiler has a
different view of the world?  If the compiler builder labels something as
info, he's telling me "this is your least worry".  So I'll gladly not worry
about it, except when I have time to spare.  Whereas a warning _should_ be
telling me (alas it often doesn't) "this might get you into trouble".

> So much for dismissing my comment about developers' opinions...

So much for dismissing this tiring "informational"-discussion unless you have
something new to say.

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

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/