unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Peter Dyballa <Peter_Dyballa@Web.DE>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 52435@debbugs.gnu.org
Subject: bug#52435: 29.0.50; C-y seems to contain an old contents
Date: Sun, 12 Dec 2021 12:18:37 +0100	[thread overview]
Message-ID: <8A9C7C2F-642A-454D-A99B-0945A1E2D5F7@Web.DE> (raw)
In-Reply-To: <877dcafk78.fsf@gnus.org>

Yes, I can reproduce it with -Q.

Launch: /opt/local/bin/emacs-29.0.50 -Q. Or equivalent.

Inside GNU Emacs 29.0.50: M-x shell RET.

In *shell* buffer just invoke ls -l RET for some contents. Or cat something with a few lines contents. Move the mouse cursor and point somewhere into this output, press C-SPACE to start marking a region. Move the mouse cursor some lines away (above or below the start of region). M-| or M-x shell-command-on-region RET. I chose to use "awk '{print $NF}'".

Now change to buffer *Shell Command Output* with C-x o. I think this is decisive. Just clicking into *Shell Command Output* buffer seems to do the right things. You are at the beginning of buffer and can immediately replace-string ^J against SPACE CHARACTER, go to beginning of line (C-a) and kill it with C-k. Now return to *shell* buffer with C-x o again. The region is still marked, gets high-lighted again. With Esc-> go to the command line prompt and C-y to insert the line you killed in *Shell Command Output* buffer – but something else (not from The Move) is inserted.


But: This is also the behaviour in GNU Emacsen 26.1, 27.1, 28.0.50 – I just used C-x o for the first time in this everyday procedure? transient-mark-mode is t, assuming it would clear the marked region when leaving it or the buffer.

The documentation in GNU Emacs 29.0.50 has become vague (on function transient-mark-mode):

	The mark is "deactivated" after certain non-motion
	commands, including those that change the text in the buffer, and
	during shift or mouse selection by any unshifted cursor motion
	command (see Info node ‘Shift Selection’ for more details).

The documentation in GNU Emacs 26.1 seems to be clearer:

	The mark is "deactivated" by changing the buffer,
	and after certain other operations that set the mark but whose
	main purpose is something else--for example, incremental search,
	M-<, and M->.

And it states that the region is cleared when changing to another buffer.

But OK, maybe I have to learn this different behaviour…


(After marking and applying shell-command-on-region I go to *compilation* buffer and then exchange it with *Shell Command Output* so that I am immediately at compilation again. Then I kill the now useless *Shell Command Output* buffer. During this period with new GNU Emacs 29.0.50 I exchanged *shell* with *Shell Command Output* and fell back into it afterwards, and the mark was still active and became high-lighted again – which puzzled me. When I then invoked compile again, the yank contents was a different one than killed. The first time this happened I quit Emacs, assuming it or I would have a problem with the new macOS version Monterey. The next time in new instance I just started my procedure again, and now for the third occurrence I tested Esc-y and more.)

--
Greetings

  Pete

With Capitalism man exploits man. With communism it's the exact opposite.






  reply	other threads:[~2021-12-12 11:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-11 14:58 bug#52435: 29.0.50; C-y seems to contain an old contents Peter Dyballa
2021-12-12  5:47 ` Lars Ingebrigtsen
2021-12-12 11:18   ` Peter Dyballa [this message]
2021-12-13  2:30     ` Michael Heerdegen
2021-12-13  9:07       ` Peter Dyballa
2021-12-14  8:48         ` Michael Heerdegen
2021-12-14  9:31           ` Peter Dyballa
2021-12-14 10:59             ` Michael Heerdegen
2021-12-14 11:15               ` Peter Dyballa
2021-12-14 12:13                 ` Phil Sainty
2021-12-14 14:02               ` Peter Dyballa
2021-12-15  4:23                 ` Michael Heerdegen
2022-01-14  9:34                   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8A9C7C2F-642A-454D-A99B-0945A1E2D5F7@Web.DE \
    --to=peter_dyballa@web.de \
    --cc=52435@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).