From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14696 invoked by alias); 13 Dec 2002 20:47:49 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14686 invoked from network); 13 Dec 2002 20:47:48 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 209.249.29.67 with SMTP; 13 Dec 2002 20:47:48 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id gBDKkj531634; Fri, 13 Dec 2002 12:46:45 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Per Bothner Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: gdb patch to suppress empty lines, re-visited References: <3DF6CDC2.5050105@bothner.com> <3DF7C9FF.63429C4D@redhat.com> <3DFA356F.6000405@bothner.com> From: David Carlton Date: Fri, 13 Dec 2002 12:53:00 -0000 In-Reply-To: <3DFA356F.6000405@bothner.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00432.txt.bz2 On Fri, 13 Dec 2002 11:30:55 -0800, Per Bothner said: > A few people have expresses themselves in favor, and none > have been opposed. I don't know if that counts as a consensus ... I don't know if I like it or not, and I don't think I'll know until I've actually tried it. My first reaction is slightly negative, and I'm not at all sure how well it will work with XEmacs's GDB mode: if I do a bunch of steps through a function, I get output like this: (gdb) s (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) because the mode isn't showing me the source code information in that buffer (since it's available in another buffer), and I can't imagine your patch doing anything good to that output. (I have no idea what GNU Emacs's GDB mode looks like: for some reason, XEmacs uses a different (older?) one.) So if your patch would change the output in this situation, I'm dubious. But maybe it wouldn't; I'm not sure if the ISATTY (instream) guard would protect against this situation. I guess if it doesn't affect the output under (X)Emacs then I don't care one way or another because I'll never see its results. David Carlton carlton@math.stanford.edu