From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21318 invoked by alias); 27 Nov 2012 18:48:08 -0000 Received: (qmail 21297 invoked by uid 22791); 27 Nov 2012 18:48:06 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Nov 2012 18:48:02 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARIm1pl008967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Nov 2012 13:48:01 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARIm0uR002551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 Nov 2012 13:48:01 -0500 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/4] Suppress repeated annotations until GDB is ready to accept input. References: <20121121201416.1015.36832.stgit@brno.lan> <20121121201429.1015.6037.stgit@brno.lan> <87vccsics1.fsf@fleche.redhat.com> <50B3B4BC.2010108@redhat.com> Date: Tue, 27 Nov 2012 18:48:00 -0000 In-Reply-To: <50B3B4BC.2010108@redhat.com> (Pedro Alves's message of "Mon, 26 Nov 2012 18:28:12 +0000") Message-ID: <87sj7udgrj.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00770.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> Hmm. There's potential for making it worse. The patch Pedro> suppresses duplicate annotations until the next prompt is Pedro> displayed. With background commands, events can be reported Pedro> without re-displaying a prompt [*]. In that case, emacs might Pedro> miss annotations. FWIW, I am not sure this is so very bad. Async is still an advanced user thing. And, if Emacs gets out of sync it is simple to do "up;down" or the like to get back in sync. Pedro> With this version, we don't do annotation suppression if a background Pedro> command is in progress. This means that Pedro> define twobreaks Pedro> b foo Pedro> b bar Pedro> end Pedro> twobreaks Pedro> triggers two annotations in async mode if the target is not Pedro> running, or isn't running the foreground, while always just one Pedro> in sync mode. I don't think that's a real problem. Me neither. It isn't even clear Emacs does anything with those annotations at all. Pedro> [*] - though that could itself be considered a bug, the CLI Pedro> output is less than ideal here. We should be able to keep the Pedro> bottom line reserved for the prompt, and scroll the rest of the Pedro> output without visually interfering with the prompt line. E.g., Pedro> we could be able to unwind the cursor to column 0, print whatever Pedro> while handling the event, and then redisplay the prompt as it Pedro> was, without the user noticing. Or perhaps there's cleaner ways Pedro> even. Do you mean, do this in Emacs or for the CLI itself? Either way I think it would be nice. I've often wished we could replace the "Reading..." messages, which are often illegible, with some kind of nicer hash progress meter thing ... Pedro> Is there any way to force emacs 24 to do full annotations? It actually Pedro> hadn't realized that "--fullname" was annotate=1, not 2, so my previous Pedro> emacs testing was useless, as these notifications only happen with Pedro> annotate=2... I don't think there is. When I tried just editing the gdb command line I ended up with a lot of "^Z^Z" in the gud buffer. I guess you could dig up Emacs 23 (still in F16...) or try to downgrade the gud code. Tom