From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Grand Unified Debugger Rewrite's process buffer: comint, eterm or eshell? Date: Sat, 31 Oct 2009 14:51:58 +0900 Message-ID: <87skd0m7pd.fsf@catnip.gol.com> References: <6cd6de210910300848g69755d4bx98366d5f4ed90705@mail.gmail.com> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1256968350 27981 80.91.229.12 (31 Oct 2009 05:52:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 Oct 2009 05:52:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rocky Bernstein Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 31 06:52:23 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N46sw-00007X-O5 for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2009 06:52:23 +0100 Original-Received: from localhost ([127.0.0.1]:40744 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N46sw-0001DB-7D for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2009 01:52:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N46sm-0001Cx-Jb for emacs-devel@gnu.org; Sat, 31 Oct 2009 01:52:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N46sg-0001CN-8M for emacs-devel@gnu.org; Sat, 31 Oct 2009 01:52:10 -0400 Original-Received: from [199.232.76.173] (port=57636 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N46sf-0001CK-KN for emacs-devel@gnu.org; Sat, 31 Oct 2009 01:52:05 -0400 Original-Received: from smtp12.dentaku.gol.com ([203.216.5.74]:50635) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N46sb-00014H-SR; Sat, 31 Oct 2009 01:52:02 -0400 Original-Received: from 218.231.174.22.eo.eaccess.ne.jp ([218.231.174.22] helo=catnip.gol.com) by smtp12.dentaku.gol.com with esmtpa (Dentaku) id 1N46sZ-0008SF-Hk; Sat, 31 Oct 2009 14:51:59 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id CD558DF90; Sat, 31 Oct 2009 14:51:58 +0900 (JST) System-Type: x86_64-unknown-linux-gnu In-Reply-To: <6cd6de210910300848g69755d4bx98366d5f4ed90705@mail.gmail.com> (Rocky Bernstein's message of "Fri, 30 Oct 2009 11:48:20 -0400") Original-Lines: 37 X-Virus-Scanned: ClamAV GOL (outbound) X-Abuse-Complaints: abuse@gol.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116495 Archived-At: Rocky Bernstein writes: > 1. I can stick with comint.el. It seems the most creaky. > 2. term.el is pretty cool, but it doesn't provide a hook to run when > 3. eshell.el. It also seems pretty cool too. However its focus seems One thing is that people are used to using comint, and are used to using its features (both interactive and customization) with both shells and sub-modes such as gud-mode. While both term.el and eshell are well-intentioned, they both started development a long time ago when comint was less capable, and have in general not picked up new features added to comint. So... you can't really think of them as being strict functional supersets of comint, they're more like... different branches in the same tree. E.g., one thing I've worked on a lot in comint has been prompt handling, and as a result, comint handles prompts nicely (with highlighting and "prompt avoidance" etc), whereas term.el doesn't (and eshell kinda does, but not so well, and only in some cases). Eshell seems a very different thing than either comint or term.el. The latter two essentially talk to an I/O stream attached to a subprocess, and work by interpreting the output. Eshell, on the other hand, issues individual commands separately, and so can maintain far finer control _between_ subcommands, but as a result tends to be not so good as long as the subprocess itself still has control. [As an example, start eshell, and then type "/bin/sh" to start a subshell. Note that although you get shell prompts etc, everything suddenly seems "dumb" -- whereas if you start a subshell in a comint shell, it basically seems exactly the same as the parent shell.] I think that eshell probably isn't appropriate for gdb for that reason. -Miles -- Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven lies about us.' The world begins lying about us pretty soon afterward.