help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: In emacs 23 compile-mode doesn't recognize (c)perl error messages


From: Joseph Brenner
Subject: Re: In emacs 23 compile-mode doesn't recognize (c)perl error messages
Date: Thu, 29 Oct 2009 20:51:56 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

LanX <address@hidden> writes:

>> The main problem is of course how to handle this. What about using
>> unit tests? When I take time to write them for nXhtml I think they
>> helps a lot. (But I am mostly not fighting problems with getting it to
>> fit with changes in Emacs. I am fighting my own mistakes. And mistakes
>> in external libraries.)
>
> Sure testing is crucial!

[...]

> But with a test-set for compile.el I would have been in a position to
> either prove the problem very fast  or I would at least have a
> starting point to add new tests, improving the test coverage.
>
> I have to say that even today after using emacs for more than 15 years
> now my knowledge of elisp is quite reduced, so I can't even tell what
> kind of testing is realistically possible.

As it happens, I'm also enamored of suites of automated tests.
Oh wait, I'm a perl programmer.

There are something like a dozen elisp test frameworks at this point.
None of them have been endorsed by the emacs-devel team.  Anyone
interested in this approach would have to evaluate the existing test
packages, or write yet-another-one... and I'm afraid someone coming
out of the perl culture is not likely to be impressed by any of them
(e.g. to my knowledge, none of them respect the TAP standard).

I have a vague impression that ert.el may have a little more momentum
than the rest.  But then, the only way to get a copy of it is as a
side-effect of installing the nxhtml packages.

I gather that the reason we're stuck with this state of affairs is that
the emacs-devel team (including rms) isn't really interested.  They like
the idea of having a tool to do higher level testing of the entire
interface, but don't see the point of lower level tests... which is to
say they'd like to solve the hardest problem first, and aren't too
likely to do this soon.

> From a perlish point of view (excuse me ;-) someting like
> www::mechanize or selenium used to test web-apps would be nice.

Sure, but it might be a good idea to think about an analog of
Test::More first.



reply via email to

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