From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15177 invoked by alias); 27 Apr 2010 17:16:18 -0000 Received: (qmail 14893 invoked by uid 22791); 27 Apr 2010 17:16:13 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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 Apr 2010 17:16:08 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3RHFhDo018311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Apr 2010 13:15:46 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o3RGZQeX030181; Tue, 27 Apr 2010 12:35:26 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o3RGZOKN008656; Tue, 27 Apr 2010 12:35:25 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 86BF9379787; Tue, 27 Apr 2010 10:35:24 -0600 (MDT) From: Tom Tromey To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [vxworks 02/14] New command_post observer. References: <1272210447-13895-1-git-send-email-brobecker@adacore.com> <1272210447-13895-3-git-send-email-brobecker@adacore.com> <20100427142208.GC2951@adacore.com> Reply-To: tromey@redhat.com Date: Tue, 27 Apr 2010 17:16:00 -0000 In-Reply-To: <20100427142208.GC2951@adacore.com> (Joel Brobecker's message of "Tue, 27 Apr 2010 07:22:08 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2010-04/txt/msg00912.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: >> There are a lot of calls to execute_command that occur in batch-like >> places. For example, this is called from Python, I think it is called >> from "commands" scripts and "define" scripts, etc. >> >> So if your goal is to have it just emit info at some stopping point, it >> seems to me that it would be better to have an observer just before a >> prompt is emitted. Joel> Either way would work, as far as I am concerned. The purpose is to Joel> inform the user that the context (partition) has changed. I have Joel> a tiny preference towards having consistent output, if we can, with Joel> commands executed from the prompt and commands executed from elsewhere Joel> such as user-defined commands for instance. But that preference really Joel> has no additional technical merit that I can think of, so I'm happy to Joel> change the observer to use something triggered just before printing Joel> the command prompt (btw: it does not matter in this case, but I believe Joel> that the prompt also gets printed as "> " while entering a canned Joel> sequence of command). I think the ">" thing indicates a misunderstanding. I was talking about when various command scripts are executed, not when they are entered. E.g., suppose there are commands in a "define" that change the partition, do some work, and then change it back. With the observer as it now stands, the user will see multiple notifications. If the observer were just before the prompt, only one notification would be emitted. Maybe there's no way for user commands to change the partition. That would render this consideration irrelevant. Also, if this doesn't matter to you, then it is also fine by me. Tom