From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Peter Dyballa Newsgroups: gmane.emacs.bugs Subject: bug#52435: 29.0.50; C-y seems to contain an old contents Date: Tue, 14 Dec 2021 10:31:56 +0100 Message-ID: References: <46037FBE-8DAB-4913-850C-96F4F78622E2@Web.DE> <877dcafk78.fsf@gnus.org> <8A9C7C2F-642A-454D-A99B-0945A1E2D5F7@Web.DE> <87fsqxjkx5.fsf@web.de> <0B5129BE-27A6-460A-ABE7-85A3504C55DE@Web.DE> <87tufb1shx.fsf@web.de> Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37681"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 52435@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 14 10:33:20 2021 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 1mx4BR-0009d4-Lt for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Dec 2021 10:33:17 +0100 Original-Received: from localhost ([::1]:40724 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mx4BP-00034b-N6 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Dec 2021 04:33:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60138) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mx4BC-00034O-E0 for bug-gnu-emacs@gnu.org; Tue, 14 Dec 2021 04:33:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46041) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mx4BC-0004FV-4J for bug-gnu-emacs@gnu.org; Tue, 14 Dec 2021 04:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mx4BB-0002ql-VS for bug-gnu-emacs@gnu.org; Tue, 14 Dec 2021 04:33:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Peter Dyballa Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Dec 2021 09:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52435 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 52435-submit@debbugs.gnu.org id=B52435.163947432610890 (code B ref 52435); Tue, 14 Dec 2021 09:33:01 +0000 Original-Received: (at 52435) by debbugs.gnu.org; 14 Dec 2021 09:32:06 +0000 Original-Received: from localhost ([127.0.0.1]:57587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mx4AH-0002pZ-O1 for submit@debbugs.gnu.org; Tue, 14 Dec 2021 04:32:05 -0500 Original-Received: from mout.web.de ([212.227.17.12]:38543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mx4AF-0002p5-U1 for 52435@debbugs.gnu.org; Tue, 14 Dec 2021 04:32:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1639474317; bh=7KXVnWU83mMo1O8ZQKLrjx20UaVl8ExxUt+dOCROhqk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=c+UN/E9NvsZ1dwQCDUf+tA/TEIPkOgvmGV/frSkPW2xir0ZOQLtZAXXQVW0XLil99 3ClBRKKG1Pw5423pcssIPHzUEn3b0pIECfTOawME4n5HR/9DbDv4372GsY84PbHuKX 6/1wpjhbTfPPfk25lJSnnGM/34FFLfUoHNBZzUgg= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from smtpclient.apple ([176.199.137.124]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1M2Phc-1mwWSh0VIs-0041cd; Tue, 14 Dec 2021 10:31:57 +0100 In-Reply-To: <87tufb1shx.fsf@web.de> X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Provags-ID: V03:K1:dMRkwm97xQL/5jA7TRqsvGblJi7fBSmqVw9yBCR2GKMi7bVYYAd nZUcKAM5UmOQFIBMIzvh/nz3Y/Mzz45eFt6XfPeYYJlWhBsyt9ZcgOP9knyFFOPCmtyJeaV c/rz3ShLAXPBL7AlIHFM9ZpqbrbD389LCuzBseex8EHvTO1rP5uF1FEKc3BirQh5FIqEyRV ItRD0BF+i9f8jnc59JmrA== X-UI-Out-Filterresults: notjunk:1;V03:K0:0+RQjWT9+C4=:vNBvM4UuvAAtIosJsRZaEf W714016t+B+Y2VP/PGzo0A6I9dbMQeBjSZ3bJJ45q5IoWwfhdUoLMTN91Vwm3rnvu4JlLi2hQ ax6OOR3oajhe+DmzwDy8my51gt+iH6ugzIut9KFnkZF9HW0j8psbETjzB3L4DaXgpzXkSkeVO vMce7NYGkOD8K7ukIOjYwLRF7z1b/BPYCQoMduOLykHFaLbtcZoQFVDzMKxegxbZ5EpR7q1XV bDAgX9jJ9rZaGs79F695bHWN/14bygem1RI/eN7pXKqlovWmeS/7ay2+rPMFPxeq3VYJWh3o3 /RlWTfnX5r+LOsQDsziYnUgVPhC+6VTr6K5MPYse8MsnyZkdVmrCYq+5QY0ENd5KhDbQ5aFjt Nj5kQ3h1y99vrMdFyt+bIqVIO+YBFejh+Vstm185YglM0WYfH3qO87Eqq7gRZVAYFG7fCMCZL oRvHwNmN5ufEF2uUDfBvcJKerq2gaXkQG/TlZHiNJKCEGhQ3FcMnK83VxrOGiuqxN05j99BFe NCeyEnNDEQp0kfRHYXGF91fLFtJw6X23jgxIi4eLA5RmJonxTs93ij6X4tCucVwdaJPX94dnx feBLtw1JHv2u8qZOKu++2DgSQ2mGk9hck8WwbeIAXmrsSWaFqM/GFeBAJ1osQZ27SFHw1/7nR PaCRrQPtJAtDTK6bYoX/09p3F0gIrIBvxUTO490/kVXsMmh0tMjpf1NeuvQUdrxwk7MRrr8qI lqJHtJWsGGW4IDnZGbR+FihfLgrou5mPEXtJ6Q52Bkr6M7Ooec8YUOZkeOxFQwpT8CrMcrku 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" Xref: news.gmane.io gmane.emacs.bugs:222361 Archived-At: > Am 14.12.2021 um 09:48 schrieb Michael Heerdegen = : >=20 > Peter Dyballa writes: >=20 >>> Do I understand correctly: you expect that C-x o deactivates the = mark, >>> but it doesn't? >>=20 >> It's exactly this for me surprising behaviour. >=20 > And you are sure that this was different in older emacs versions, and > not just something in your config? If you are, do we know when this > changed? No, I am not sure. IMO the documentation states that the mark will be = cleared when I leave the buffer. (Or use M-< or M->.) My usual behaviour is that I mark a region in *shell* buffer and apply = shell-command-on-region. Then I move into another buffer in the same = frame, mostly *compilation*. I perform a few edits on *Shell Command = Output*, kill the remaining line and the buffer, and am back in = *compilation* where I can use the edited output from *Shell Command = Output*. Because a compilation was going on, I chose to use *shell* = buffer to change from it to *Shell Command Output* and fell back to it. = The region was still marked and so the contents of last kill-line in = *Shell Command Output* was overwritten with the contents of the marked = region. After C-y, seeing the wrong contents, I could Esc-y to bring = back the killed line. So GNU Emacs worked transparently, only I was = surprised about the unexpected contents. I don't think that I have a particular configuration, except = (transient-mark-mode t). As I wrote on Sunday, a few older versions of = GNU Emacs show the same behaviour. On a decades old PowerBook I could = check the behaviour of much older Emacsen and report here. (There I too = work with MacPorts to keep some utilities and OpenSSL up-to-date and = have to use the described procedure much more often, since some open = software ports do not support the old OS and hardware and have to be = excluded from upgrading at least initially.) If you can give me some = variable names I can check whether I reset the original setting. One fact should be stated: using a mouse click to change into another = buffer clears the mark. -- Mit friedvollen Gr=C3=BC=C3=9Fen Pete Math illiteracy affects 7 out of every 5 Americans.