[Top][All Lists]

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

Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests whi

From: Alan Mackenzie
Subject: Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it.
Date: Thu, 17 Jan 2019 16:43:50 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, João.

On Thu, Jan 17, 2019 at 14:57:04 +0000, João Távora wrote:
> Hi Alan,

> Please revert this change ASAP:

> commit 54f297904e0c641fcfd81f16e9a87177124a27be
> Author: Alan Mackenzie
> Date:   Thu Jan 17 12:51:40 2019 +0000

>     Temporarily comment out CC Mode from tests which are incompatible
> with it.

That would leave lots of failed tests in make check.  People have
already remarked on those failures, implicitly asking me to fix them.

> I thought we had agreed that the way to "work around" other people's
> unit tests, even if temporarily, is to work in a separate git branch.

My understanding, from a previous encounter, was that having no failing
unit tests was of a high priority.  I've only commented a little bit
out, I haven't made any permanent, unreverseable changes.

> The other electric-pair-test that I disabled 6 months ago, that was one that
> also temporary, is till there. But now you destroyed even the "expected
> failure" mark.  Why?? Is the test passing unexpectedly?

With that test in, I got the error message: "No test named
and no other tests were performed, leaving an electric-tests.log file 86
bytes long.  That's why I commented it out.  This may be some glitch in
the testing system.

> @@ -396,10 +397,10 @@ whitespace-chomping-2
>  ;; mode will sort this out eventually, using some new e-p-m machinery.
>  ;; See
>  ;; https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00535.html
> -(setf
> - (ert-test-expected-result-type
> -  (ert-get-test
> 'electric-pair-whitespace-chomping-2-at-point-4-in-c++-mode-in-strings))
> - :failed)
> +;; (setf
> +;;  (ert-test-expected-result-type
> +;;   (ert-get-test
> 'electric-pair-whitespace-chomping-2-at-point-4-in-c++-mode-in-strings))
> +;;  :failed)

> But this is much more intrusive.  In particular

> ;; Tests commented out, since C Mode does not use
> ;; electric-layout-mode.  2019-01-17, ACM

> C Mode doesn't use electric-layout mode, but a user can surely
> decide he wants to use it in c-mode, can he not??

No.  Certainly not at the moment.

> These tests pass fine currently.

When I ran them, there were lots of failures, because the tests assumed
electric-layout-mode was active.

> Please revert this fix and lets discuss why you need to disable tests.

It's not a fix, it's a temporary workaround.

Anyhow, surely the implementation of Emacs should not be constrained by
its tests?  Rather the tests should test the chosen implementation.

> If we come to the conclusion that some tests are asserting unreasonable
> expectations about the functionality you develop, we can disable them on a
> case by case basis!

I would have done that, indeed tried to do that, but the lack of
documentation of electric-pair-test-for, electric-pair-define-test-form
and so on, many of them with 8, 9 or more parameters, made that too
difficult, given the urgency I felt to produce a workaround.

> If on the other hand, if you need to do some work "temporarily", then
> the best way to do it without disturbing other people's developments
> is to do it in a separate branch.

I fixed bug #33794[*] on master, as I always do with CC Mode bugs (and most
other sorts of bugs, too).  That fix is, in principle, sound.  I didn't
discover the problems with the unit tests till later (though I admit I
should have done).

[*] That is, Beatrix Klebe's bug about CC Mode's auto-newlines not
working with electric-pair-mode.

Anyhow, apologies, and all that, but I don't want to spend any more time
on this topic today or until tomorrow evening, since I've got an exam
coming up tomorrow.  But I promise I'll get back to you (including
answering your other post) either late tomorrow or on Saturday.

> João

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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