From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Cummings Newsgroups: gmane.emacs.bugs Subject: bug#50630: [PATCH] Add tests for insert-directory Date: Sat, 25 Sep 2021 11:38:08 +0000 Message-ID: References: <83a6k1rxrc.fsf@gnu.org> Reply-To: John Cummings Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35221"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50630@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 25 13:39:19 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mU61X-0008xB-3p for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Sep 2021 13:39:19 +0200 Original-Received: from localhost ([::1]:53598 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mU61V-00031C-3T for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Sep 2021 07:39:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42844) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mU61H-00030q-Dx for bug-gnu-emacs@gnu.org; Sat, 25 Sep 2021 07:39:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48820) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mU61G-0002Ip-Em for bug-gnu-emacs@gnu.org; Sat, 25 Sep 2021 07:39:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mU61G-0001MP-7H for bug-gnu-emacs@gnu.org; Sat, 25 Sep 2021 07:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: John Cummings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Sep 2021 11:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50630 X-GNU-PR-Package: emacs Original-Received: via spool by 50630-submit@debbugs.gnu.org id=B50630.16325699045161 (code B ref 50630); Sat, 25 Sep 2021 11:39:02 +0000 Original-Received: (at 50630) by debbugs.gnu.org; 25 Sep 2021 11:38:24 +0000 Original-Received: from localhost ([127.0.0.1]:60362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mU60d-0001LB-PK for submit@debbugs.gnu.org; Sat, 25 Sep 2021 07:38:24 -0400 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]:35809) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mU60c-0001Kw-7C for 50630@debbugs.gnu.org; Sat, 25 Sep 2021 07:38:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rootabega.net; s=protonmail; t=1632569891; bh=rONtBxdBv8XxJqa6ZMs4pIgJEqOKpr0H52sk7CooZ7o=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=igWgVHy4zLgjCKu8qoyAe1LnqHI6T+UAPErUsjKnkgPEl1j/WGyC3e7crOYqigpSf y7PtcOEWoxRKnwaEDCAzyvFPwYe+LdM/nwpPqRZP8TJpRwGZwLuA5vy9av1ykjWhyz A/as7yPQ/ESzyHuWj6E4oESYLXHcCYUq3G+xhBifZC2lSjGLy8hCgQu7DiUG2q+bXY 2zptlEUjjMuWUhYm60AetB8B17+KqEVZFGqnqnwhVGCbHmTV+93KlUBhZfSIrfMxUq AoH5lO4DjkJ/x+OygdDUUDyKyFDNBto39ekCiib3BVGbOYEawkuwxALVFnSy1TFzEJ MLEaQ7ww3YxSA== In-Reply-To: <83a6k1rxrc.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:215433 Archived-At: Eli Zaretskii wrote: >> Date: Fri, 24 Sep 2021 19:58:25 +0000 >> From: John Cummings >> >> Along those lines, I also attempted to skip the test when ls-lisp >> would be used during files-tests.el, which I predict might happen when >> building on Windows? > > Why did you need to skip those tests? Can you elaborate? ls-lisp has its own implementation of insert-directory, which duplicates the bug, and which will also duplicate the fix when I submit it soon. (Let me know if the recipe to confirm the bug is present in ls-lisp.el attached earlier doesn't work for you.) So if ls-lisp was "active" during this test, it could be a false positive/negative for this test, depending on whether ls-lisp had been fixed yet. (See my reply to your later question in this message for what I mean when I say ls-lisp is "active", because just requiring the library isn't enough.) On my GNU/Linux system, ls-lisp is not active when running this test from the Makefile, but I don't want to assume that that is true of every system. Since Windows GNU Emacs uses ls-lisp.el by default when running, I thought it might be one of those exceptions at build time as well. I confirmed that it's also true if someone runs this test interactively after having activated ls-lisp, regardless of the system. That is, I activated ls-lisp, eval'd files-tests.el, and ran ert for that file, and the test failed because it used the buggy insert-directory from ls-lisp. So even if building a Windows Emacs (or any system) does not use ls-lisp by default, is there any harm in having this skip condition (other than potentially confusing the reader)? I admit I may not correctly or completely understand the way that ls-lisp could relate to a batch ert run at build time, or how that varies between architectures. If it's NOT something to worry about during a 'make', would I still need to worry about someone who ran this test after enabling ls-lisp manually? Perhaps I could fail the test so the user knows what they did didn't make sense? Also, note that this is only true for the 50630 regression test. That may have been the wrong choice. Perhaps it would make sense to run any test of insert-directory's implementation if and only if ls-lisp.el is not active? >> + ;;Try to verify that insert-directory will come from files.el, >> + ;;not ls-lisp.el. Windows builds will probably use ls-lisp.el >> + ;;by default, which will invalidate some tests. >> + (insert-directory-program-used (or (not (featurep 'ls-lisp)) >> + ls-lisp-use-insert-directory-= program))) > I guess this is part of the same question I asked above? Because I > don't think I understand what you are trying to do here and why. Yes, my logic was that this being non-nil means the test will be using the Emacs-default insert-directory implementation from files.el, and not the ls-lisp.el one. In order to use the ls-lisp one (what I've referred to as ls-lisp being "active" previously), the ls-lisp library needs to be loaded, and the variable on the second line needs to be nil, otherwise ls-lisp will just delegate back to files.el for insert-directory. I personally find the variable a little confusing, and think that negating its name and meaning would be more natural, but the documentation does make it clear, even if I have to think about it for a bit every time I set it.