From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: Some testing issues Date: Fri, 14 Jul 2017 11:55:13 +0200 Message-ID: <87pod3gx6m.fsf@rosalinde> References: <8737a8j61r.fsf@rosalinde> <87zicfnft7.fsf@rosalinde> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1500026248 20041 195.159.176.226 (14 Jul 2017 09:57:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Jul 2017 09:57:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: Emacs developers To: Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 14 11:57:24 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dVxLc-0004iT-VO for ged-emacs-devel@m.gmane.org; Fri, 14 Jul 2017 11:57:21 +0200 Original-Received: from localhost ([::1]:36621 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVxLg-0003E7-Pr for ged-emacs-devel@m.gmane.org; Fri, 14 Jul 2017 05:57:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVxJp-0002X8-0O for emacs-devel@gnu.org; Fri, 14 Jul 2017 05:55:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVxJl-0006qq-RE for emacs-devel@gnu.org; Fri, 14 Jul 2017 05:55:29 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:56611) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dVxJl-0006p3-H9 for emacs-devel@gnu.org; Fri, 14 Jul 2017 05:55:25 -0400 Original-Received: from rosalinde ([83.135.15.98]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M70HF-1dtErn2PMj-00wn2s; Fri, 14 Jul 2017 11:55:14 +0200 In-Reply-To: (Noam Postavsky's message of "Sat, 8 Jul 2017 18:01:12 -0400") X-Provags-ID: V03:K0:yqKYFLCaclwqvGUi9biuP3VDghgVuQMCk2WJVwzBOTMmVBHn4Kz bFxd0y+vxbbE+vVQPCne9bEW6wiuoNWS7OLxY56k4Bq6v8eI56uVgBceDV3XqgAyQehxPxS AbbCXpsVIJ9hGb4YpTD5AZz1TqOGz6CNGhdI0OjI0SWBzYn5GRPWUaqkVemYUKEq9fgtIyg qMDwimjSVFQ2huEVcDPMg== X-UI-Out-Filterresults: notjunk:1;V01:K0:iBZeRvmW+Ns=:ZKK8qdcQPPtNshPsG7gTbr 3Izudrt1wlt6hVpzxoQENqVdUU3ik3Defsfx1LD4Z1PTAPswLQqWB3XuhrDSMADvfc4LGqemm zUgddNAaj4o9l8uq6psEhsdq291+j2MeqiZ37hEdMVtGDCtdCWRpU3EWuvf/RsoY4rdCq4VNC 3jGwDpf/PNx9C2ZeOfD+mUBMVxUo3Pt6e5bSHfsexPqkZ9/8gEHVxZKi6MOt1fSYCly8PXOO0 I+KrgovyZXYExvG5cbxDC5+AJl5hvUUIlRUNECGKemqqfmm6wgTVwTKrWJD6KTeV7jTjS1vkI jjhrrNiUO8xtEeJN8yMxzL1FAWYhX78CBusi4iTYZIfI24u4vILYWXcKWVJLyUQtSnWUp6LMu WHFlgPEO3MbZiLWhR9fXaiCZqcWZTdl8Lo+s781EA6k5wyemu53bKGxlxRvGKHRiuH15bQ8iW 0U27A7QnEs6gb7YboYrIhpI58aeQUmEpCcnw1AyHzBc3HFO4C7NeITCjOklMSXqjW97kzuStQ w2va1FgIPi+QQRkxgtzvlqpEL67emvFqb3VPPK485Az0Ox/dEaDLA4Vo2XJs0hGkBEXcHh+Iw XTWUdjBdeSSdiByDbZawc8kkjWzhVFqyiZI2JwoXoc6+DsAjOFJ+3SAMNdE0sq33eUe5Fwy+/ C9WRsnJ6VUSUJHkD5veMg0VXwP/Omxj74tMS6uolk3nZLL3r8LWKDIuxvWVsvJ2JWoH8FyRO1 c/0APdK6ohX1v91K4fgM9aY/BHC0G56o8ADhb3xxnaI8ZmS3hFQr6Br4VIwCIZkf07MDIKYD X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.18 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:216642 Archived-At: On Sat, 8 Jul 2017 18:01:12 -0400 Noam Postavsky wrote: > On Sat, Jul 8, 2017 at 10:50 AM, Stephen Berman wrote: >>> `(let* ((todo-test-home (make-temp-file "todo-test-home-" t)) >>> + (abbreviated-home-dir nil) >>> (process-environment (cons (format "HOME=%s" todo-test-home) >>> process-environment)) >> >> The only test file that sets abbreviated-home-dir is package-test.el, in >> the macro with-package-test, which was indeed the inspiration for >> with-todo-test. I assume this would only effect cases like yours, and >> hence make the test environment more robust, or are possible problems >> that setting it to nil could raise? > > abbreviated-home-dir is essentially a cache used by > abbreviate-file-name, and when the value of HOME is changed the cached > value is wrong, hence why setting it to nil is the right thing. > Possibly we should record the value of HOME we cached and clear it > automatically when a new one is used so that this kind of thing is not > needed. In the mean time, it sounds like setting it to nil is appropriate. >>> >>> I think it succeeds the second time because the *ert* buffer is in a >>> different state. >> >> What state is that? In Edebug it appears to be the same as on the first >> test run: current-buffer is todo-test-1.todo and selected-window is the >> one showing the *ert* buffer, yet now (pos-visible-in-window-p shown) is >> non-nil, while on the first run it is nil. I don't see what makes the >> difference -- certainly not the value of the variable `shown', which is >> 226 and that position in window displaying *ert* is visible in both runs. > > Maybe the set-window-buffer from the other tests leaks in? For some > reason I can't reproduce this today, every time I run with the > set-window-buffer commented out it consistently fails. I'm sure > yesterday I saw it succeeding after the first time. There should be no leakage, because the state is cleared after each individual test run (at least, that's what with-todo-test is supposed to do). >>> todo-test-toggle-item-header04? I added a `message' call, and it seems >>> that in batch mode the selected window shows *scratch* whereas in >>> interactive mode it shows *ert*. I would say the success in >>> interactive mode is just a coincidence. >> >> Well, it's a reliably reproducible coincidence, which seems like a >> contradiction in terms. > > I mean "coincidence" in the same way that the 5th digit of pi being 5 > is a "coincidence" (slightly less reliable than that though, > presumably if we made `initial-scratch-message' long enough the batch > mode behaviour would change). Ah, ok. Steve Berman