From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#69914: comint-strip-ctrl-m doesn't function as documentation states Date: Sat, 23 Mar 2024 09:30:16 +0200 Message-ID: <86il1dz9pz.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17671"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69914@debbugs.gnu.org To: Jonathan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 23 09:10:44 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rnwSh-0004MP-EN for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Mar 2024 09:10:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rnwSN-00074b-TO; Sat, 23 Mar 2024 04:10:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rnwSM-00074T-8N for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2024 04:10:22 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rnwSL-0001HX-6R for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2024 04:10:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rnwSz-0004eJ-Rf for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2024 04:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Mar 2024 08:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69914 X-GNU-PR-Package: emacs Original-Received: via spool by 69914-submit@debbugs.gnu.org id=B69914.171118142417762 (code B ref 69914); Sat, 23 Mar 2024 08:11:01 +0000 Original-Received: (at 69914) by debbugs.gnu.org; 23 Mar 2024 08:10:24 +0000 Original-Received: from localhost ([127.0.0.1]:35100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rnwSN-0004cO-Ka for submit@debbugs.gnu.org; Sat, 23 Mar 2024 04:10:24 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rnw5C-0003Oq-U5 for 69914@debbugs.gnu.org; Sat, 23 Mar 2024 03:46:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rnvpZ-0003On-1V; Sat, 23 Mar 2024 03:30:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ui/KA+vl200APlzNiWDagp4WJeEXwbprAg2XvWoLd7Q=; b=kM/+XnBMhVBb qBFIMvDbtGQpF9M0YE8TzLUyoWS6G8goF29mM055LeGYUVjxf27ZvzMDWLh/D1RFTt1GmNzOot74O 4cP3UiKQp1y/LmbaK9vWopDEOnqFT+npUogd67K64+C10pOwHkfz/6y+fGR42ywcJztONKidW3eE2 xkXOrVjoo6sBCb2zoGzJcuVR4dAatIXr5QQgADsQpELj6jiedTYoN4S1hTEGpix2Ud18WrYTzGlQ4 Kwcdp1aeTYthpHNaEChQRZEVhSB0jdBYRxjnjf2E9Ou52ze6CD6x9tn/0aVScnQWtv4x8miudozix N4CA2RtGkY5lx+dzCiUt3g==; In-Reply-To: (bug-gnu-emacs@gnu.org) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:281973 Archived-At: > Date: Wed, 20 Mar 2024 14:15:39 +0000 > From: Jonathan via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > There appears to either be a bug or just inaccurate documentation of =comint-strip-ctrl-m=. At the very bottom, I've included some context about my use case by which I discovered this bug that may or may not be relevant to you. The documentation for that function states: > > #+begin_quote > Strip trailing ^M characters from the current output group. > > This function could be on comint-output-filter-functions or bound to a key. > #+end_quote > > =comint-output-filter-functions= states the following: > > #+begin_quote > ...These functions get one argument, a string containing the text as originally > inserted. Note that this might not be the same as the buffer contents between > comint-last-output-start and the buffer's process-mark, if other filter > functions have already modified the buffer. > #+end_quote > > Looking at the implementation of =comint-strip-ctrl-m= it appears that it completely ignores the =string= argument and instead uses =(get-buffer-process (current-buffer))= in direct contradiction to the documentation. Actually, AFAICT, almost all of the filtering functions intended for comint-output-filter-functions ignore its string argument. Isn't that so? > #+begin_src emacs-lisp > (defun comint-strip-ctrl-m (&optional _string interactive) > "Strip trailing `^M' characters from the current output group. > This function could be on `comint-output-filter-functions' or bound to a key." > (interactive (list nil t)) > (let ((process (get-buffer-process (current-buffer)))) > (if (not process) > ;; This function may be used in > ;; `comint-output-filter-functions', and in that case, if > ;; there's no process, then we should do nothing. If > ;; interactive, report an error. > (when interactive > (error "No process in the current buffer")) > ;;; rest omitted for brevity > ))) > #+end_src > > This represents unexpected and undocumented behavior, as you anticipate =comint-strip-ctrl-m= to behave like any other comint output filter functions. I'd like to propose 3 different possible solutions for a patch and would like input on which is preferred as this code was originally introduced in 1994. I can submit a patch once a solution has been determined. Given that almost all the filter functions behave the same (unless you disagree), it sounds like ignoring the string is a de-facto standard behavior. So we should document that, and I guess adding a new function, without deprecating the existing one, is the most reasonable way ahead?