unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: "João Távora" <joaotavora@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
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	[thread overview]
Message-ID: <20190117164350.GA18314@ACM> (raw)
In-Reply-To: <CALDnm52_uLf+Wi4pfU9MwZrApii2S2Wos7cEimBKt1AqgAM9gA@mail.gmail.com>

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
`electric-pair-whitespace-chomping-2-at-point-4-in-c++-mode-in-strings'",
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	other threads:[~2019-01-17 16:43 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 14:57 Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it João Távora
2019-01-17 16:43 ` Alan Mackenzie [this message]
2019-01-17 17:57   ` João Távora
2019-01-17 18:55     ` João Távora
2019-01-18 17:54     ` Alan Mackenzie
2019-01-18 19:55       ` João Távora
2019-01-18 22:53         ` Alan Mackenzie
2019-01-19  3:18           ` João Távora
2019-01-19 11:07             ` Alan Mackenzie
2019-01-19 13:52               ` João Távora
2019-01-19 17:45                 ` Alan Mackenzie
2019-01-19 19:15                   ` João Távora
2019-01-19 20:58                     ` Alan Mackenzie
2019-01-19 23:18                       ` João Távora
2019-01-21 18:04                       ` Stefan Monnier
2019-01-21 20:45                         ` Alan Mackenzie
2019-01-21 21:46                           ` Stefan Monnier
2019-01-21 22:41                             ` João Távora
2019-01-19 22:37                     ` Drew Adams
2019-01-20 19:05                 ` Richard Stallman
2019-01-20 21:18                   ` João Távora
2019-01-21 20:59                     ` Richard Stallman
2019-01-21 21:49                       ` João Távora
2019-01-18 21:06       ` Stefan Monnier
2019-01-19  3:25         ` João Távora
2019-01-18 22:47       ` Michael Albinus
2019-01-19 20:18       ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190117164350.GA18314@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).