From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Newsgroups: gmane.emacs.bugs Subject: bug#51132: Make sure user is doubly aware of finished complilations Date: Tue, 12 Oct 2021 20:24:22 +0200 Message-ID: <874k9m85k9.fsf@gmail.com> References: <87zgrg9hs0.5.fsf@jidanni.org> <83czobrc2a.fsf@gnu.org> <87fst6u0sr.5.fsf@jidanni.org> <838ryyqr60.fsf@gnu.org> <87v922b7ds.fsf@gmail.com> <83sfx6p6iu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16543"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 51132@debbugs.gnu.org, jidanni@jidanni.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 12 20:27:17 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 1maMUf-00046a-6a for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Oct 2021 20:27:17 +0200 Original-Received: from localhost ([::1]:38584 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1maMUe-0001U1-9y for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Oct 2021 14:27:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1maMSU-00083c-BU for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2021 14:25:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1maMSU-0001FM-35 for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2021 14:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1maMST-0004xx-W8 for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2021 14:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Oct 2021 18:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51132 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 51132-submit@debbugs.gnu.org id=B51132.163406307219042 (code B ref 51132); Tue, 12 Oct 2021 18:25:01 +0000 Original-Received: (at 51132) by debbugs.gnu.org; 12 Oct 2021 18:24:32 +0000 Original-Received: from localhost ([127.0.0.1]:53234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1maMRz-0004x3-T0 for submit@debbugs.gnu.org; Tue, 12 Oct 2021 14:24:32 -0400 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:36387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1maMRy-0004wc-UN for 51132@debbugs.gnu.org; Tue, 12 Oct 2021 14:24:31 -0400 Original-Received: by mail-wr1-f51.google.com with SMTP id o20so215871wro.3 for <51132@debbugs.gnu.org>; Tue, 12 Oct 2021 11:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=4Mf1IESFxJ8pYVykB3hb0QiY4C8kNF00wi/dn3actUw=; b=QfM3EeBrSidQDfft3Bq+SoNhjGVksvST0k2/9F58cx2KL1fWVq14fKji2DTlTSl5S3 EGlan/bzSYapyYingYh7vDR/ZEynTzDIVATMDcYUYPTWR0WpFwhVhlCsPztSQRloWvLV Atd35pVNZVQSoSbLe81sNqvtBTZgGzcTH9K/pCuEd3wiUAMl8XroktqPt8jkW1MPZZ3I gk4VN2PCVDyAa19JnewMaJ0F4Feh92A8BAKYxi6iS7tZAye3VonPzNQbny3BzaWp0u2U oTjnKKiEZ0SG8RL7HDXOB0XphjK0hu0F3vs0Efs6lnFMjcGW8x/3rdj/uW2aZgWD3A92 Ip4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=4Mf1IESFxJ8pYVykB3hb0QiY4C8kNF00wi/dn3actUw=; b=M1JXm5HBCM42NXXKpZ2Zg9GuHnEQQf1YzU7+m9eoHR6XBUNcnzC717qwRNez15BQTz h/RViQVSdLQTFnK6usqWORfccCSKjmJiIaIP7AeIlSXonQdbDAJlpxBHU0f2EyPTze5i SHZEhdQtzunPbRbyGbL3CiGdlwTbnHnLUudGOD1f7Cq0Q+/TnpVaU6ZODXn+5T8of9AU TtNYahh0XIeJ1gblRv3b2LK1PGX2JNvooXbanTknZmE8eZrYFKs5KyCg7sF032p0zKiJ 4LlrnApvZku6Gm2DTU1BzmYrtipE+y7psJ55wYiGt3EzLW49xQS23bkPDUhUwO1XE6z7 XGsw== X-Gm-Message-State: AOAM532FtgNAkKO6ZeuVzrQgFDoEutY8qETPs7Gkua6aO0aIIqk7WnWo S11fPCArX00J0qWUjo0k17bXqjjwFGU= X-Google-Smtp-Source: ABdhPJwgcl2wi/13nx7fFnvD1jyqaEAqrWSG9zEUfcwh/m8HmE7D/L+bvh/G91N4FHw2IuU6hlVjcQ== X-Received: by 2002:a5d:4dd1:: with SMTP id f17mr10336712wru.226.1634063064669; Tue, 12 Oct 2021 11:24:24 -0700 (PDT) Original-Received: from amdahl30 ([2a01:e0a:253:fe0:2ef0:5dff:fed2:7b49]) by smtp.gmail.com with ESMTPSA id c204sm3167123wme.11.2021.10.12.11.24.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 11:24:23 -0700 (PDT) In-Reply-To: <83sfx6p6iu.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 12 Oct 2021 19:11:37 +0300") 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:217067 Archived-At: Eli Zaretskii writes: > No, all of the mode lines of the windows that show the *Compilation* > buffer, of course. When you do something that jidanni does: > > C-x 2 C-x 3 C-x 2 C-x 3... > > then you will have many *Compilation* buffers, right? I'm assuming that Dan would keep at most _one_ window displaying the *compilation* buffer. >> - the "Compilation finished/exited" message can be clobbered almost >> immediately by many things (e.g. navigation commands that push the >> mark, digit arguments, C-g). > > (That message gets written into the *Compilation* buffer, not in the > echo-area. So it never gets clobbered by anything, except another > compilation.) Apologies for being unclear; I was referring to the message that is printed in the echo-area by compilation-handle-exit. AFAIK, when the *compilation* buffer is e.g. buried, that is one of the two visible signs that tell the user that the process has finished, the other being the disappearance of "[Compiling]" in the mode-line. > Anyway, we are talking about a user who (mis-)configures his windows > so that nothing useful is visible on the mode line, then buries the > *Compilation* buffer (since the compilation he launches doesn't > interest him at all, right?), and then, when he finally wants to know > what happened there, doesn't even consider to look back in that buried > buffer? Is that the situation? The situation, as it happened to me a couple of times before learning about compilation-finish-functions, was: 1. run some background process in a *compilation* buffer, 2. bury the buffer because I know the result will not be available for a couple of minutes or hours, 3. work on completely unrelated matters in the meantime, in the same Emacs session, 4. miss both hints that the process has finished and the result I want is available (if I spend 5 minutes reading something in a web browser, then I won't notice the _absence_ of "[Compiling]" in the mode-lines when coming back to Emacs; as for the message in the echo-area, see above), 5. consider I have finished working on the unrelated matters, and close Emacs, 6. bang my head on the desk out of frustration and self-loathing. > And we are supposed to tweak Emacs to > cater to such hypothetical users? why? > This request has been considered and denied, both by Lars and myself. > I see no reason to make yet another, 3rd indication, especially since > every indication can be ignored if the user really wants to ignore it, > exactly like the existing 2 indications are ignored. Not say anything > about the bad karma of adding unnecessary stuff to the mode line, > where space is at premium since long ago. Thanks, but no, thanks. That's perfectly fine as far as I am concerned; and that's also why my original contribution to the discussion was pointing Dan to compilation-finish-functions, where he hopefully can design an indication that will be tailored to his needs and not so easily ignored. My second contribution to the discussion was obviously unneeded and I apologize for the time that was wasted.