Re: Compile issues

[Dave Love]

Stefan Monnier <address@hidden> writes:

> OK, well I missed it, then.  I think that if you want it included in Emacs,
> it's best to send it to emacs-devel.

etc/MAILINGLISTS:

This list/newsgroup will be for the posting, by their authors, of Emacs
Lisp and C sources and patches that improve GNU Emacs.  Its contents
will be reviewed by the FSF for inclusion in future releases of GNU
Emacs.

[I suspect MAILINGLISTS needs a complete re-work if it's to be kept,
but I've always understood that was the purpose of g.e.s., and I've
also assumed it's OK to post things that might be useful to users but
which won't go into Emacs for one reason or another.  Is that really
no longer the case?]

> Things I see on gnu.emacs.sources I generally assume that the author
> does not (yet) intend to include it in Emacs

rms led me to believe it would be included, and I don't know why it
wasn't.  (I must say I don't understand the criteria for including
that and not other things I posted, one of which addressed a TODO.)

> In the case of python-mode, I seem to remember that the mode by Barry was
> deemed "best left with the Python package",

There is no assignment for it an it appears not to have Emacs support
as a priority, shall we say.

> so I tend to not consider these things to be directly relevant to
> Emacs).

I don't understand.  Shouldn't Emacs have a Python mode, especially
one that's potentially better than the XEmacs one?

> But I thought there was more to it.

There is, but I obviously haven't got to the bottom of it yet.

>> I do understand the i18n and compiler issues.  Was that unclear?
>
> I can't remember what you're referring to.

Various of the patterns presumably won't work with internationalized
applications in locale fr_CH, for instance (I assume that `file'
becomes `fichier', for instance) and it doesn't look as though they
all work with non-ASCII commands and/or filenames.  I also commented
on the classification and apparent redundancy of he patterns.

> Again, I have no idea what you're talking about.
> Or are you talking about situations like the one of tex-mode where
> each compilation is done in the same comint buffer?

Probably more or less; I don't know exactly what either TeX mode does.
Since it's a module compiler, I guess it's pretty much the same as an
inferior SML REPL, but it's along time since I used one.  I assumed
that sort of thing would be generally familiar.

>> What it does in the released version is broken in Emacs 21.2 anyhow.
>
> Once more, I have no idea what you're referring to.

You don't need to -- I mentioned the context in case anyone tried to
look at the published code and say why I changed it.

> If you tell us what the user does,

Types C-c C-k and then C-x `.

> how Emacs-21.2 behaved,

Found the error location.

> how the new compile.el behaves,

Says `No more errors yet' (with M-x first-error).

> and how Emacs should behave instead,

Find the error location.

I doubt that helps.

> Support for compilation-parsing-end is in my local tree, but since its
> semantics was unclear, I'd need to know how it's used

It's used to avoid processing errors before that point in the buffer,
reset at each compilation and possibly by the next comint input of any
sort.

> Support for copmpilation-error-list (via compilation-parse-errors-function)
> is also upcoming, but I need more precision to know whether that
> backward-compatibility stuff is good enough for Erlang.

I think it's just used to clear out the errors from previous
compilations.  I don't think there's anything Erlang-specific about
this, and it would apply just the same to what cmuscheme should do,
for instance.