Re: current compile.el issues

[Dave Love]

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.

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

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

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

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

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

> 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.  Previously you implied that informational wasn't
meant to cover compiler messages.  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.

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