From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rocky Bernstein Newsgroups: gmane.emacs.devel Subject: Grand Unified Debugger Rewrite's process buffer: comint, eterm or eshell? Date: Fri, 30 Oct 2009 11:48:20 -0400 Message-ID: <6cd6de210910300848g69755d4bx98366d5f4ed90705@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001636ed6a18089762047728f573 X-Trace: ger.gmane.org 1256917782 25452 80.91.229.12 (30 Oct 2009 15:49:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Oct 2009 15:49:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 30 16:49:35 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 1N3tjE-0004ON-9V for ged-emacs-devel@m.gmane.org; Fri, 30 Oct 2009 16:49:28 +0100 Original-Received: from localhost ([127.0.0.1]:38038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3tjD-0003df-KO for ged-emacs-devel@m.gmane.org; Fri, 30 Oct 2009 11:49:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3tiI-0002mn-1H for emacs-devel@gnu.org; Fri, 30 Oct 2009 11:48:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3tiA-0002gR-Jp for emacs-devel@gnu.org; Fri, 30 Oct 2009 11:48:27 -0400 Original-Received: from [199.232.76.173] (port=50695 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3tiA-0002gF-FF for emacs-devel@gnu.org; Fri, 30 Oct 2009 11:48:22 -0400 Original-Received: from mail-pw0-f47.google.com ([209.85.160.47]:39845) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3ti9-0007xQ-N8 for emacs-devel@gnu.org; Fri, 30 Oct 2009 11:48:22 -0400 Original-Received: by pwj10 with SMTP id 10so748521pwj.26 for ; Fri, 30 Oct 2009 08:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=IBNgbBbMi1dsbAY7R0dHgVoq/bXP9nLtWVTdtN78qWM=; b=E9Fct/Nvfoa1UW23Go76cyur6CPQ1NEaAFfKEDuHd6o4V0gmDDDKiCaqQ2a4o+mHq3 h8+8rqmiwSqJue+CO/DNGfB7ntdUMHF4ZEgsYW5TZO0p5m0/wNetzG/mrtsStruGXmJd HNjny2g0v+tz7udGHYkQF3XxvY7Vsohp/DM7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=YtUd/zx2H/BgCBTbdtpCmKkHXetgp7D0WUut9VqmBnjuYoVSiqK7CBqf8Gxg1Kl6LO ywzcyAeu+XXTlVgF6CCjrYah6E0a6v+g49QoG2Gl5GDCPhQgWA7x17yKWv05k+sQWyr5 mubrkwjfLbfqbqwQsw31nGgWnAd1OOokRAkOk= Original-Received: by 10.142.249.39 with SMTP id w39mr188176wfh.278.1256917700220; Fri, 30 Oct 2009 08:48:20 -0700 (PDT) X-Google-Sender-Auth: f2c21bceee907352 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:116469 Archived-At: --001636ed6a18089762047728f573 Content-Type: text/plain; charset=ISO-8859-1 (Cross posted to comp.emacs.help, before I realized this may really be of a more specialized topic). I have started to rewrite gud from the ground up. For the process buffer I have 3 choices. 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 output is produced and this is something I need. I use it both in comint.el and eshell.el in "shell tracker" (think pdb-track) mode. So this leads to the last choice ... 3. eshell.el. It also seems pretty cool too. However its focus seems to be more as a command shell rather than a process buffer manager interacting via elisp to a debugger front-end. This mismatch in goals manifests itself in little things like the ability to set the name of the buffer initially, starting the shell with a specific debugger invocation, customizing the banner shown on entry, avoiding the myriad of key bindings that are not applicable here. Although little things each easly addressed, I think they are manifestations of the larger issue may keep cropping up if I go down this path. So right now, my take is to add a output filter hook to term.el. But I'd be interested and grateful in thoughts and suggestions. --001636ed6a18089762047728f573 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (Cross posted to comp.emacs.help, before I realized this may really be of a= more specialized topic).

I have started to rewrite gud from the gro= und up.

For the process buffer I have 3 choices.

1. I c= an 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
output is produced and this is something I need. I use it both i= n
comint.el and eshell.el in "shell tracker" (think pdb-trac= k) mode. So
this leads to the last choice ...

3. eshell.el. It also seems = pretty cool too. However its focus seems
to be more as a command shell= rather than a process buffer manager
interacting via elisp to a debug= ger front-end. This mismatch in goals
manifests itself in little things like the ability to set the name of
= the buffer initially, starting the shell with a specific debugger
inv= ocation, customizing the banner shown on entry, avoiding the myriad
of key bindings that are not applicable here. Although little things
= each easly addressed, I think they are manifestations of the larger
is= sue may keep cropping up if I go down this path.

So right now, = my take is to add a output filter hook to term.el. But
I'd be interested and grateful in thoughts and suggestions.

--001636ed6a18089762047728f573--