From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#1973: Bug in simple.el (Emacs version 22.2.1) Date: Sat, 24 Jan 2009 16:14:23 -0500 Message-ID: Reply-To: Stefan Monnier , 1973@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1233599064 8950 80.91.229.12 (2 Feb 2009 18:24:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Feb 2009 18:24:24 +0000 (UTC) Cc: 1973@emacsbugs.donarmstrong.com To: Sebastian Tennant Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 02 19:25:38 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LU3UA-0006LP-Ta for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Feb 2009 19:25:31 +0100 Original-Received: from localhost ([127.0.0.1]:41915 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LU3Ss-0000eQ-4q for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Feb 2009 13:24:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LU3SK-0000Hy-CD for bug-gnu-emacs@gnu.org; Mon, 02 Feb 2009 13:23:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LU3SI-0000GM-Rx for bug-gnu-emacs@gnu.org; Mon, 02 Feb 2009 13:23:36 -0500 Original-Received: from [199.232.76.173] (port=34777 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LU3SI-0000G5-Cd for bug-gnu-emacs@gnu.org; Mon, 02 Feb 2009 13:23:34 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:51178) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LU3SH-0004aT-Ta for bug-gnu-emacs@gnu.org; Mon, 02 Feb 2009 13:23:34 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n12INVXC020778; Mon, 2 Feb 2009 10:23:31 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n12IA3cD017291; Mon, 2 Feb 2009 10:10:03 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Stefan Monnier Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 02 Feb 2009 18:10:03 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 1973 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1973-submit@emacsbugs.donarmstrong.com id=B1973.123359764715259 (code B ref 1973); Mon, 02 Feb 2009 18:10:03 +0000 Original-Received: (at 1973) by emacsbugs.donarmstrong.com; 2 Feb 2009 18:00:47 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n12I0hHR015253 for <1973@emacsbugs.donarmstrong.com>; Mon, 2 Feb 2009 10:00:45 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEAPfChknO+IQk/2dsb2JhbACBbsoohBQGgmw X-IronPort-AV: E=Sophos;i="4.37,366,1231131600"; d="scan'208";a="33211581" Original-Received: from 206-248-132-36.dsl.teksavvy.com (HELO pastel.home) ([206.248.132.36]) by ironport2-out.teksavvy.com with ESMTP; 02 Feb 2009 13:00:38 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 10CBA8229; Mon, 2 Feb 2009 13:00:38 -0500 (EST) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Mon, 02 Feb 2009 13:23:36 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:24842 Archived-At: > > I guess it's using shell-mode, but somehow fails to setup the process's > > output filter? > Now you're making it sound like a bug, just as I'm starting to accept > that it's a misfeature :) One part is whether it should use shell-mode or not. Another is whether, when using shell-mode, it should behave like M-x shell. The second part is clearly a bug. If we decide it shouldn't use shell-mode, then the bug needn't be fixed. But given that it currently uses shell-mode, it seems that (contrary to what I thought) the current intention is for it to behave like shell-mode, in which case it should be fixed. > And I've found a solution, but it's ugly: > (add-hook 'shell-mode-hook > (lambda () > (set-process-filter proc 'comint-output-filter))) > No one likes to see the guts of a function (local variable 'proc') in > their mode hooks. Yes, that's not a good option. Better use neither shell-mode-hook, nor some magic variable name. I think that all that's needed is a good (set-process-filter (get-buffer-process ) 'comint-output-filter) at the right place. Tho, maybe a better option is to change the way the process is started along the lines of what you originally proposed. > We have two buffers (*shell* and *Async Command Output*) that both claim > to be in Shell mode, yet process output is handled completely > differently in each case. Indeed, that's a bug. > Why is *Async Command Output* in Shell mode at all if we're not to > assume it will only be used for shell commands (that require ^M > character handling)? It's probably historical: shell mode hasn't always processed those chars, so in the past the lack of comint-output-filter was simply not noticed. > Even replacing the call to shell-mode with a call to comint-mode makes > no difference to the way ^M characters are handled. In either case the > process filter must be explicitly set to 'comint-ouput-filter. I'd > expect something as visually arresting as mangled output to be handled > by a mode setting, but hey ho. This is a more difficult decision: should calling a major-mode affect the filter of a process that happens to be running in this buffer? Usually, the expectation is that shell-mode (or comint-mode) is not called directly, so the process filter is set by the calling code. > If it were up to me, I'd rewrite the asynchronous part of shell-command > so that make-comint-in-buffer is used to create a Comint mode buffer > called *Async Shell Command Output* and leave it at that. I'm beginning to agree. Stefan