From unknown Sun Jun 22 00:21:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66313: 29.1.50; process-mark sometimes does not yield the expected value Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Oct 2023 19:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 66313 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 66313@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.169627630221147 (code B ref -1); Mon, 02 Oct 2023 19:52:01 +0000 Received: (at submit) by debbugs.gnu.org; 2 Oct 2023 19:51:42 +0000 Received: from localhost ([127.0.0.1]:38115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qnOxC-0005V0-5w for submit@debbugs.gnu.org; Mon, 02 Oct 2023 15:51:42 -0400 Received: from lists.gnu.org ([2001:470:142::17]:58968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qnOx9-0005Ud-9E for submit@debbugs.gnu.org; Mon, 02 Oct 2023 15:51:40 -0400 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 1qnOwm-0003Fb-LY for bug-gnu-emacs@gnu.org; Mon, 02 Oct 2023 15:51:17 -0400 Received: from [78.47.144.35] (helo=metalevel.at) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qnOwk-0002vB-Fk for bug-gnu-emacs@gnu.org; Mon, 02 Oct 2023 15:51:16 -0400 Received: from mts-Mac-mini.localdomain (localhost [127.0.0.1]) by metalevel.at (Postfix) with ESMTP id 67FE79C751 for ; Mon, 2 Oct 2023 21:51:10 +0200 (CEST) Received: by mts-Mac-mini.localdomain (Postfix, from userid 501) id 1AA2929CE571; Mon, 2 Oct 2023 22:00:05 +0200 (CEST) From: Markus Triska Date: Mon, 02 Oct 2023 22:00:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 78.47.144.35 (failed) Received-SPF: none client-ip=78.47.144.35; envelope-from=triska@metalevel.at; helo=metalevel.at X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) To reproduce this issue, please do the following: 1) download ediprolog.el with: $ wget https://www.metalevel.at/ediprolog/ediprolog.el 2) download simulans_a.sh with: $ wget https://www.metalevel.at/ei/process-mark/simulans_a.sh This shell file will illustrate this issue in lieu of Scryer Prolog. 3) make simulans_a.sh executable with: $ chmod +x simulans_a.sh 4) create test1.pl and test2.pl, with the following commands: $ echo "?- X = a." > test1.pl $ echo "?- X = a." > test2.pl 5) launch Emacs with: $ emacs -Q -l ediprolog.el --eval "(add-to-list 'exec-path \".\")" \ --eval '(setq ediprolog-program "simulans_a.sh")' test1.pl test2.pl Emacs now shows two windows, test2.pl in the upper window, and test1.pl in the lower window. Initially, test2.pl is the selected window, and point is on the query "?- X = a.". Now do: M-x ediprolog-dwim RET As expected, the buffer will now consist of the following text: ?- X = a. %@ X = a. Now, switch to the below window (test1.pl) with: C-x o And there, do: M-x ediprolog-dwim RET Unexpectedly, the buffer will consist of the following text: ?- X = a. %@ X = a. The newline after %@ is unexpected! The expected buffer content is: ?- X = a. %@ X = a. This already illustrates a difference compared to Emacs 26.1, 27.1, and other versions, which behave as expected. To see more differences, switch back to the above window (test2.pl): C-x o And move point to the first line (the line of the query) with: C-p And then do: M-x ediprolog-dwim RET Unexpectedly, the buffer will consist of the following text: ?- X = a. %@ %@ X = a. X = a. The expected text (at this state) is: ?- X = a. %@ X = a. %@ X = a. Repeat these steps to see more unexpected behaviour. It seems that process-mark sometimes does not yield the expected position. ediprolog.el goes to the process-mark in line 431, which reads: (goto-char (process-mark ediprolog-process)) In all cases above, the process-mark is expected to yield the value 14 at this point of the program, but it does not always yield this value. If possible, could you please restore the behaviour that earlier Emacs versions exhibit in these examples? Thank you and all the best, Markus In GNU Emacs 29.1.50 (build 1, x86_64-apple-darwin18.2.0, X toolkit, cairo version 1.17.6, Xaw scroll bars) of 2023-09-14 built on mac Repository revision: f0a89fa1d0e5b380ecadb57052c95b31110c0323 Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.11804000 System Description: Mac OS X 10.14.2 Configured using: 'configure --with-x-toolkit=lucid --without-ns CFLAGS=-I/opt/local/include/ LDFLAGS=-L/opt/local/lib --with-xpm=ifavailable' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 LUCID ZLIB From unknown Sun Jun 22 00:21:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66313: Acknowledgement (29.1.50; process-mark sometimes does not yield the expected value) Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Oct 2023 14:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66313 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 66313@debbugs.gnu.org Received: via spool by 66313-submit@debbugs.gnu.org id=B66313.169668816217661 (code B ref 66313); Sat, 07 Oct 2023 14:17:01 +0000 Received: (at 66313) by debbugs.gnu.org; 7 Oct 2023 14:16:02 +0000 Received: from localhost ([127.0.0.1]:55581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp866-0004ab-2N for submit@debbugs.gnu.org; Sat, 07 Oct 2023 10:16:02 -0400 Received: from [78.47.144.35] (port=55504 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp863-0004WL-V6 for 66313@debbugs.gnu.org; Sat, 07 Oct 2023 10:16:01 -0400 Received: by metalevel.at (Postfix, from userid 1000) id E8CA29C762; Sat, 7 Oct 2023 16:15:38 +0200 (CEST) From: Markus Triska References: Date: Sat, 07 Oct 2023 16:15:38 +0200 In-Reply-To: (GNU bug Tracking System's message of "Mon, 02 Oct 2023 19:52:01 +0000") Message-ID: <87jzrytt6d.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I have reduced this to the following problem: set-process-buffer sometimes unexpectedly changes the position of process-mark. For a shorter test case that exhibits the issue, please download process-mark.el from: Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 SPF_NONE SPF: sender does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) I have reduced this to the following problem: set-process-buffer sometimes unexpectedly changes the position of process-mark. For a shorter test case that exhibits the issue, please download process-mark.el from: https://www.metalevel.at/ei/process-mark/process-mark.el Its contents are: (let ((p (start-process "bash" nil "bash"))) (set-marker (process-mark p) (point)) (set-process-buffer p (current-buffer)) (marker-position (process-mark p))) (message "hello there!") Place point after the first form in the file, and evaluate the form with C-x C-e. The expected result is: 165. It is obtained with Emacs 26.1 and several later versions. However, with the Emacs version I used to report this problem, the result I get is unexpectedly: 192. I would greatly appreciate if the previous behaviour could be restored. Thank you and all the best, Markus From unknown Sun Jun 22 00:21:24 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Markus Triska Subject: bug#66313: closed (Re: bug#66313: Acknowledgement (29.1.50; process-mark sometimes does not yield the expected value)) Message-ID: References: <83ttr2zd8g.fsf@gnu.org> X-Gnu-PR-Message: they-closed 66313 X-Gnu-PR-Package: emacs Reply-To: 66313@debbugs.gnu.org Date: Sat, 07 Oct 2023 15:04:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1696691043-24584-1" This is a multi-part message in MIME format... ------------=_1696691043-24584-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #66313: 29.1.50; process-mark sometimes does not yield the expected value which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 66313@debbugs.gnu.org. --=20 66313: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66313 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1696691043-24584-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 66313-done) by debbugs.gnu.org; 7 Oct 2023 15:03:50 +0000 Received: from localhost ([127.0.0.1]:55643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp8qM-0006Nl-2Q for submit@debbugs.gnu.org; Sat, 07 Oct 2023 11:03:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46254) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp8qJ-0006NU-1L for 66313-done@debbugs.gnu.org; Sat, 07 Oct 2023 11:03:48 -0400 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 1qp8ps-0007vA-Sa; Sat, 07 Oct 2023 11:03:21 -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=6n8Puuz1pb3wP+wGNfxIgWakbGxA+rtU3ZAzDe6Ly0c=; b=OZT+ofmcJheo 8RyEYRuJrOnIZdqmb7GWVPz+PLhSelE+pEaF+vPruXK9d1PbhHLawJyP+JmAHISNtHGGazJ85nSNw I1Fgcq6Mz/wL3tru2XRK4fPa8wu+sscFVBvupnXXadN39AVeQjyHQ/LMXjBZCtgwbgiPPktdNJK1i j/mvXmGhZHSeEn6bULjQ30x+bdTrclzx4VCzs2LDe3tl9rNenVh0oPF4omOcojKdUHOfGegKYzCSA /tAtqMZJHUebBV0f3Vlc5bIeVoq3LrlHuAR5fzMCZf3bB76SrTUXFdus7KxkolxvsDMk0+AT+1bpb xJvjOUyLVCyli34jH8e0fQ==; Date: Sat, 07 Oct 2023 18:03:27 +0300 Message-Id: <83ttr2zd8g.fsf@gnu.org> From: Eli Zaretskii To: Markus Triska In-Reply-To: <87jzrytt6d.fsf@metalevel.at> (message from Markus Triska on Sat, 07 Oct 2023 16:15:38 +0200) Subject: Re: bug#66313: Acknowledgement (29.1.50; process-mark sometimes does not yield the expected value) References: <87jzrytt6d.fsf@metalevel.at> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66313-done Cc: 66313-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Markus Triska > Date: Sat, 07 Oct 2023 16:15:38 +0200 > > > I have reduced this to the following problem: set-process-buffer > sometimes unexpectedly changes the position of process-mark. > > For a shorter test case that exhibits the issue, please download > process-mark.el from: > > https://www.metalevel.at/ei/process-mark/process-mark.el > > Its contents are: > > (let ((p (start-process "bash" nil "bash"))) > (set-marker (process-mark p) (point)) > (set-process-buffer p (current-buffer)) > (marker-position (process-mark p))) > > (message "hello there!") > > Place point after the first form in the file, and evaluate the form with > C-x C-e. > > The expected result is: 165. It is obtained with Emacs 26.1 and several > later versions. > > However, with the Emacs version I used to report this problem, the > result I get is unexpectedly: 192. > > I would greatly appreciate if the previous behaviour could be restored. I fixed this on the emacs-29 branch, but please note that your code is quite problematic: the set-marker call associates the process-mark marker with the current buffer, but the process's buffer is still nil. So between the 2nd and the 3rd line of your snippet, you have a window where the process-mark points to a buffer different from the buffer associated with the process. You should do this the other way around: first set the process-buffer, and then update the process-mark position to a position in that buffer. So in a nutshell, your code was hitting "undefined behavior", and expecting it to be bug-for-bug compatible with old versions of Emacs was not really reasonable. ------------=_1696691043-24584-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 2 Oct 2023 19:51:42 +0000 Received: from localhost ([127.0.0.1]:38115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qnOxC-0005V0-5w for submit@debbugs.gnu.org; Mon, 02 Oct 2023 15:51:42 -0400 Received: from lists.gnu.org ([2001:470:142::17]:58968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qnOx9-0005Ud-9E for submit@debbugs.gnu.org; Mon, 02 Oct 2023 15:51:40 -0400 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 1qnOwm-0003Fb-LY for bug-gnu-emacs@gnu.org; Mon, 02 Oct 2023 15:51:17 -0400 Received: from [78.47.144.35] (helo=metalevel.at) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qnOwk-0002vB-Fk for bug-gnu-emacs@gnu.org; Mon, 02 Oct 2023 15:51:16 -0400 Received: from mts-Mac-mini.localdomain (localhost [127.0.0.1]) by metalevel.at (Postfix) with ESMTP id 67FE79C751 for ; Mon, 2 Oct 2023 21:51:10 +0200 (CEST) Received: by mts-Mac-mini.localdomain (Postfix, from userid 501) id 1AA2929CE571; Mon, 2 Oct 2023 22:00:05 +0200 (CEST) From: Markus Triska To: bug-gnu-emacs@gnu.org Subject: 29.1.50; process-mark sometimes does not yield the expected value Date: Mon, 02 Oct 2023 22:00:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 78.47.144.35 (failed) Received-SPF: none client-ip=78.47.144.35; envelope-from=triska@metalevel.at; helo=metalevel.at X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) To reproduce this issue, please do the following: 1) download ediprolog.el with: $ wget https://www.metalevel.at/ediprolog/ediprolog.el 2) download simulans_a.sh with: $ wget https://www.metalevel.at/ei/process-mark/simulans_a.sh This shell file will illustrate this issue in lieu of Scryer Prolog. 3) make simulans_a.sh executable with: $ chmod +x simulans_a.sh 4) create test1.pl and test2.pl, with the following commands: $ echo "?- X = a." > test1.pl $ echo "?- X = a." > test2.pl 5) launch Emacs with: $ emacs -Q -l ediprolog.el --eval "(add-to-list 'exec-path \".\")" \ --eval '(setq ediprolog-program "simulans_a.sh")' test1.pl test2.pl Emacs now shows two windows, test2.pl in the upper window, and test1.pl in the lower window. Initially, test2.pl is the selected window, and point is on the query "?- X = a.". Now do: M-x ediprolog-dwim RET As expected, the buffer will now consist of the following text: ?- X = a. %@ X = a. Now, switch to the below window (test1.pl) with: C-x o And there, do: M-x ediprolog-dwim RET Unexpectedly, the buffer will consist of the following text: ?- X = a. %@ X = a. The newline after %@ is unexpected! The expected buffer content is: ?- X = a. %@ X = a. This already illustrates a difference compared to Emacs 26.1, 27.1, and other versions, which behave as expected. To see more differences, switch back to the above window (test2.pl): C-x o And move point to the first line (the line of the query) with: C-p And then do: M-x ediprolog-dwim RET Unexpectedly, the buffer will consist of the following text: ?- X = a. %@ %@ X = a. X = a. The expected text (at this state) is: ?- X = a. %@ X = a. %@ X = a. Repeat these steps to see more unexpected behaviour. It seems that process-mark sometimes does not yield the expected position. ediprolog.el goes to the process-mark in line 431, which reads: (goto-char (process-mark ediprolog-process)) In all cases above, the process-mark is expected to yield the value 14 at this point of the program, but it does not always yield this value. If possible, could you please restore the behaviour that earlier Emacs versions exhibit in these examples? Thank you and all the best, Markus In GNU Emacs 29.1.50 (build 1, x86_64-apple-darwin18.2.0, X toolkit, cairo version 1.17.6, Xaw scroll bars) of 2023-09-14 built on mac Repository revision: f0a89fa1d0e5b380ecadb57052c95b31110c0323 Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.11804000 System Description: Mac OS X 10.14.2 Configured using: 'configure --with-x-toolkit=lucid --without-ns CFLAGS=-I/opt/local/include/ LDFLAGS=-L/opt/local/lib --with-xpm=ifavailable' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 LUCID ZLIB ------------=_1696691043-24584-1-- From unknown Sun Jun 22 00:21:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66313: Acknowledgement (29.1.50; process-mark sometimes does not yield the expected value) Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Oct 2023 15:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66313 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 66313-done@debbugs.gnu.org Received: via spool by 66313-done@debbugs.gnu.org id=D66313.16966925365567 (code D ref 66313); Sat, 07 Oct 2023 15:29:01 +0000 Received: (at 66313-done) by debbugs.gnu.org; 7 Oct 2023 15:28:56 +0000 Received: from localhost ([127.0.0.1]:55683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp9Ed-0001Rj-NB for submit@debbugs.gnu.org; Sat, 07 Oct 2023 11:28:56 -0400 Received: from [78.47.144.35] (port=56094 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp9Eb-0001RY-Bi for 66313-done@debbugs.gnu.org; Sat, 07 Oct 2023 11:28:54 -0400 Received: by metalevel.at (Postfix, from userid 1000) id BF7899C75D; Sat, 7 Oct 2023 17:28:32 +0200 (CEST) From: Markus Triska References: <87jzrytt6d.fsf@metalevel.at> <83ttr2zd8g.fsf@gnu.org> Date: Sat, 07 Oct 2023 17:28:32 +0200 In-Reply-To: <83ttr2zd8g.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 07 Oct 2023 18:03:27 +0300") Message-ID: <87sf6mv4db.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: > I fixed this on the emacs-29 branch Thank you! I now found the related issue #43573, where Lars states: Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 SPF_NONE SPF: sender does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii writes: > I fixed this on the emacs-29 branch Thank you! I now found the related issue #43573, where Lars states: "If this breaks anything (and that is possible -- somebody could be using `process-mark' as a weird way to keep track of what the previous buffer was -- it should be reverted." Also, I found commit 7b3e94b6648ed00c6948c09267894b548b2868e7, where the following (then) new piece of documentation was added to processes.texi: if non-@code{nil}, the process mark will be set to point to the end of @var{buffer}. When I wrote ediprolog.el, this was not documented as such. Is the behaviour now consistent with the documentation, or must the documentation or behaviour be changed? Should the change introduced in #43573 be reverted as indicated above, because it broke something? Thank you and all the best, Markus From unknown Sun Jun 22 00:21:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66313: Acknowledgement (29.1.50; process-mark sometimes does not yield the expected value) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Oct 2023 15:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66313 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Markus Triska Cc: 66313@debbugs.gnu.org Received: via spool by 66313-submit@debbugs.gnu.org id=B66313.16966941969118 (code B ref 66313); Sat, 07 Oct 2023 15:57:02 +0000 Received: (at 66313) by debbugs.gnu.org; 7 Oct 2023 15:56:36 +0000 Received: from localhost ([127.0.0.1]:55713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp9fP-0002Mz-Pf for submit@debbugs.gnu.org; Sat, 07 Oct 2023 11:56:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42202) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp9fN-0002Ml-T3 for 66313@debbugs.gnu.org; Sat, 07 Oct 2023 11:56:34 -0400 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 1qp9ey-0000J9-Hz; Sat, 07 Oct 2023 11:56:08 -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=rhcgtq7AQ4mgtOQxW4Fpy+obPEt3GRqr0iuC6daTnpI=; b=PRz5zN96sbo3 JsjS1ExB3egp7cuHT0nL5XvK/ObQBhBX4ZQP3LOrFy/lmKB0Xg3qmS/qojDkv4n+8a86uROmYrzSi frkHn1ZILCfyENWOmQfqJqnM8ZeHySCgGCqUxxeCe1Ag6NQcaQNt5mP9W02e5aLi9DNFDMm2tZn13 aUpkHatlwbhQoUlFwIMSIQ7Mn1V1NutjQs6gCk6wYUFm4VxnkwnUTXpRMfmA39UDv/jA38i2U61GS df6PfupBYLWVoilZY8Nfuj7RGxYDnW9EIOXpwPcs4gM/Mi7psf8Ngp/NMnl35YoNPimVO+kWMo07A BMuja7DIdsyVoRGPCDbx1Q==; Date: Sat, 07 Oct 2023 18:56:21 +0300 Message-Id: <83pm1qzasa.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87sf6mv4db.fsf@metalevel.at> (message from Markus Triska on Sat, 07 Oct 2023 17:28:32 +0200) References: <87jzrytt6d.fsf@metalevel.at> <83ttr2zd8g.fsf@gnu.org> <87sf6mv4db.fsf@metalevel.at> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Markus Triska > Cc: 66313-done@debbugs.gnu.org > Date: Sat, 07 Oct 2023 17:28:32 +0200 > > Eli Zaretskii writes: > > > I fixed this on the emacs-29 branch > > Thank you! I now found the related issue #43573, where Lars states: > > "If this breaks anything (and that is possible -- somebody could be > using `process-mark' as a weird way to keep track of what the > previous buffer was -- it should be reverted." > > Also, I found commit 7b3e94b6648ed00c6948c09267894b548b2868e7, where the > following (then) new piece of documentation was added to processes.texi: > > if non-@code{nil}, the process mark will be > set to point to the end of @var{buffer}. > > When I wrote ediprolog.el, this was not documented as such. > > Is the behaviour now consistent with the documentation, or must the > documentation or behaviour be changed? Should the change introduced in > #43573 be reverted as indicated above, because it broke something? I see no need to revert the patch nor update the documentation. You have just bumped into a gray area, where the process mark was not associated with a buffer, but set-marker (which is unrelated to processes) just happened to associate the mark with the same buffer which you later used in set-process-buffer. This is borderline-invalid code, but since it was easy to avoid moving the marker if the marker's buffer is already the same as the one set by set-process-buffer, I preferred to do that, rather than making any disruptive changes so much time after that bug#43573 fix was installed. From unknown Sun Jun 22 00:21:24 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66313: Acknowledgement (29.1.50; process-mark sometimes does not yield the expected value) Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Oct 2023 16:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66313 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 66313@debbugs.gnu.org Received: via spool by 66313-submit@debbugs.gnu.org id=B66313.169669518821264 (code B ref 66313); Sat, 07 Oct 2023 16:14:01 +0000 Received: (at 66313) by debbugs.gnu.org; 7 Oct 2023 16:13:08 +0000 Received: from localhost ([127.0.0.1]:55760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp9vQ-0005Wu-8q for submit@debbugs.gnu.org; Sat, 07 Oct 2023 12:13:08 -0400 Received: from [78.47.144.35] (port=56426 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qp9vN-0005Wj-Id for 66313@debbugs.gnu.org; Sat, 07 Oct 2023 12:13:06 -0400 Received: by metalevel.at (Postfix, from userid 1000) id 933A29C762; Sat, 7 Oct 2023 18:12:44 +0200 (CEST) From: Markus Triska References: <87jzrytt6d.fsf@metalevel.at> <83ttr2zd8g.fsf@gnu.org> <87sf6mv4db.fsf@metalevel.at> <83pm1qzasa.fsf@gnu.org> Date: Sat, 07 Oct 2023 18:12:44 +0200 In-Reply-To: <83pm1qzasa.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 07 Oct 2023 18:56:21 +0300") Message-ID: <875y3iv2bn.fsf@metalevel.at> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: > I see no need to revert the patch nor update the documentation. As I see it, the documentation I cited above no longer matches what Emacs does. This is because the documentation of `set-process-buffer' I cited states with regards to BUFFER: Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 SPF_NONE SPF: sender does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii writes: > I see no need to revert the patch nor update the documentation. As I see it, the documentation I cited above no longer matches what Emacs does. This is because the documentation of `set-process-buffer' I cited states with regards to BUFFER: if non-=E2=80=98nil=E2=80=99, the process mark will be set to point to= the end of BUFFER. This now no longer seems to hold as unconditionally as in the way it is described, because there are now (again) cases where the process mark will not be set to point to the end of buffer when calling `set-process-buffer' with a non-nil BUFFER argument. The snippet I posted earlier shows an example of this situation. I would greatly appreciate if the documentation could be written in such a way that it makes clear what we can rely on when using Emacs Lisp. Thank you and all the best, Markus