From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)] Date: Tue, 12 Sep 2023 17:09:52 +0300 Message-ID: <835y4fpjnz.fsf@gnu.org> References: <87il8pao4l.fsf@whxvd.name> <87tts8vrpb.fsf@localhost> <83h6o84yz1.fsf@gnu.org> <875y4oaban.fsf@whxvd.name> <83bkeg4o1u.fsf@gnu.org> <87o7ifu2v8.fsf@localhost> <838r9j339x.fsf@gnu.org> <87tts78lve.fsf@whxvd.name> <87zg1u0yrp.fsf@whxvd.name> <8334zmrmnu.fsf@gnu.org> <87il8fbj8q.fsf@whxvd.name> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3869"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, 65734@debbugs.gnu.org To: Sebastian Miele Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 12 16:11:02 2023 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 1qg46Y-0000oJ-20 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Sep 2023 16:11:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qg46U-0005TO-BQ; Tue, 12 Sep 2023 10:10:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qg46T-0005TE-ON for bug-gnu-emacs@gnu.org; Tue, 12 Sep 2023 10:10:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qg46T-0000AY-Fw for bug-gnu-emacs@gnu.org; Tue, 12 Sep 2023 10:10:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qg46X-0006z3-VY for bug-gnu-emacs@gnu.org; Tue, 12 Sep 2023 10:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Sep 2023 14:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65734 X-GNU-PR-Package: emacs Original-Received: via spool by 65734-submit@debbugs.gnu.org id=B65734.169452782126796 (code B ref 65734); Tue, 12 Sep 2023 14:11:01 +0000 Original-Received: (at 65734) by debbugs.gnu.org; 12 Sep 2023 14:10:21 +0000 Original-Received: from localhost ([127.0.0.1]:59671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qg45s-0006y8-SU for submit@debbugs.gnu.org; Tue, 12 Sep 2023 10:10:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qg45q-0006xo-NN for 65734@debbugs.gnu.org; Tue, 12 Sep 2023 10:10:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qg45f-0008PV-EE; Tue, 12 Sep 2023 10:10:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=P+zKmfNNkRF9OMmHBh+ngeSSp3ox4hsQIQZ4pQ/Ngns=; b=DoYHCn3gBfI6 kL5DXrS5EECZVhPJffaDOOm/zS1dpvXws1Pi4wFzd57SIi8FnA2eLMquRfwNEQrp1/KYDKtXuttmT xUCw3+8K6U6jKFliBVEW83ZskWSSDXPMSlUq5Ksd7ydWGK8EPkpkueAwX11HNk3anVPTuLYNQ6qKP JIQEaeKTZyEl0eQH67UmLf9RzjCqI89d4DkvELMD8dB6hKMTY1LPYRJi0QDMxPmpPu4H6ePELC1bc 3c5mBxrfEYtaUkV+mkWlj9+qls8G3W8VdSuFddJkdX9dDE78D1P3XmFoSm75HMeRRUs3iq0iEXG3L LrgoFSOsi0zfHt+QU2yp4w==; In-Reply-To: <87il8fbj8q.fsf@whxvd.name> (message from Sebastian Miele on Tue, 12 Sep 2023 15:04:41 +0200) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:270176 Archived-At: > From: Sebastian Miele > Cc: 65734@debbugs.gnu.org, yantar92@posteo.net > Date: Tue, 12 Sep 2023 15:04:41 +0200 > > > Looks reasonable, but I'm not sure I understand what will the test > > show if one of the tests fails: will the information shown then tell > > enough to understand which of the sub-tests failed and why? > > That almost certainly would not be immediately obvious in the current > state. I have next to no experience in working with testing frameworks. > But I assumed that regressions do not happen that often, and that it > would be good enough if the code of the test can be grasped quickly. > Then, in case of a regression, the test code can be temporarily > sprinkled with some printf-like debugging to find out the exact location > in the test. > > However, enough of that printf-like debugging could also be hard-coded, > like in the following definition (see the line ending in the comment > "Provide some context"): It should be enough to have an indication of what sub-test failed. Finding that out in a series of tests one of which fails is frequently a very frustrating experience, especially if the test is written with heavy use of macros, or generates testing code on the fly (or both). > With the always succeeding > > (should `(subtest ,kill-whole-line-arg)) ; Provide some context > > at the beginning of ervery subtest, the context would be clear after > pressing l in a buffer showing the ERT test results (but never on the > console). I mostly run tests in batch mode, so my preference is to see some telltale indication of the failed code when ERT reports the failure. > An alternative would be to use `message'. That would also provide the > context on the console. However, that also may be a bit noisy. The "noise" is required only when there's a failure. One idea is to include the test ID in the string(s) you test for equality, such that the diagnostics printed by ERT will inherently include the test ID, and will allow finding the problematic code easily. For example, instead of "AB" you could use "TEST#1" or something along those lines. Thanks.