GNU bug report logs - #10613
24.0.92; Odd behavior of kill interspersed with suspend: document or change?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10613 in the body.
You can then email your comments to 10613 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.92;
	Odd behavior of kill interspersed with suspend: document or change?
Date: Thu, 26 Jan 2012 15:21:15 +0000

If a sequence of kill commands is interspersed with a suspend
(suspend-emacs or suspend-frame, for example), then the kills are not
treated as a contiguous sequence, and a following yank does not yank all
the text killed.

This feels a bit odd, as “suspend” is not a normal command: rather like
suspending a computer, I expect that after resuming Emacs, it will be in
the same state as when suspended. But this is not the case: if one
suspends Emacs after a kill command, then on resumption a further kill
will start a new kill-ring entry.

Is this behavior worth reconsidering? If not, is it worth documenting?
(Presumably under suspend, rather than under killing, as I imagine this
behavior changing has implications for things beyond the kill-ring.)


In GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.6)
 of 2011-12-23 on skwd
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_GB.UTF-8
  value of $LC_CTYPE: en_GB.UTF-8
  value of $LC_MESSAGES: en_GB.UTF-8
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Help

Minor modes in effect:
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  recentf-mode: t
  show-paren-mode: t
  server-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  iswitchb-mode: t
  icomplete-mode: t
  global-whitespace-mode: t
  global-auto-revert-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<left> <left> <left> <M-backspace> <M-backspace> <M-backspace> 
s SPC <right> <right> <right> <right> <right> M-d M-d 
M-d s C-x C-s C-x b <return> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> SPC C-x C-s <down-mouse-1> 
<mouse-1> C-x b t e <backspace> <backspace> t e s <return> 
C-x k <return> C-x b s w i <return> C-x b <return> 
` C-e SPC . . <backspace> <backspace> <backspace> <left> 
SPC . . SPC " ' " C-x C-s C-x C-g M-< C-s i o . s t 
d e r r C-s C-s C-s C-a C-x b C-s <return> C-a <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> ` <right> <right> 
<right> <right> <right> <right> SPC . . SPC ' ' ' <backspace> 
<backspace> <backspace> @ ' ' <backspace> <backspace> 
<backspace> " ' " C-x C-s <down-mouse-1> <mouse-1> 
<up> C-h w y a n k <return> C-h f y a n k <return> 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-h k k i l l = - C-_ C-h f k i l l - l i n e <return> 
C-s a p p e n d C-s C-s C-s C-s C-s C-s C-s C-a M-x 
r e p o r t - b u <backspace> <backspace> e m a c s 
- b u g <return>

Recent messages:
Mark saved where search started
Saving file /home/rrt/Software/zile-lua/src/buffer.lua...
Wrote /home/rrt/Software/zile-lua/src/buffer.lua
yank is on C-y, <S-insertchar>, <S-insert>, <menu-bar> <edit> <paste>
Type "q" to restore previous buffer.
byte-code: Beginning of buffer [5 times]
k is undefined
Buffer is read-only: #<buffer *Help*>

Mark saved where search started

Load-path shadows:
/home/rrt/.emacs.d/elpa/dictionary-1.8.7/dictionary-init hides /usr/local/share/emacs/24.0.92/site-lisp/dictionary-el/dictionary-init
/home/rrt/.emacs.d/elpa/dictionary-1.8.7/dictionary hides /usr/local/share/emacs/24.0.92/site-lisp/dictionary-el/dictionary
/home/rrt/.emacs.d/elpa/dictionary-1.8.7/link hides /usr/local/share/emacs/24.0.92/site-lisp/dictionary-el/link
/home/rrt/.emacs.d/elpa/dictionary-1.8.7/connection hides /usr/local/share/emacs/24.0.92/site-lisp/dictionary-el/connection
/home/rrt/local/share/emacs/site-lisp/dict hides /usr/local/share/emacs/24.0.92/site-lisp/emacs-goodies-el/dict
/home/rrt/local/share/emacs/site-lisp/gforth hides /usr/local/share/emacs/24.0.92/site-lisp/gforth/gforth
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-style hides /usr/share/emacs/site-lisp/auctex/tex-style
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-mik hides /usr/share/emacs/site-lisp/auctex/tex-mik
/usr/local/share/emacs/24.0.92/site-lisp/auctex/multi-prompt hides /usr/share/emacs/site-lisp/auctex/multi-prompt
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-jp hides /usr/share/emacs/site-lisp/auctex/tex-jp
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-info hides /usr/share/emacs/site-lisp/auctex/tex-info
/usr/local/share/emacs/24.0.92/site-lisp/auctex/latex hides /usr/share/emacs/site-lisp/auctex/latex
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex hides /usr/share/emacs/site-lisp/auctex/tex
/usr/local/share/emacs/24.0.92/site-lisp/auctex/texmathp hides /usr/share/emacs/site-lisp/auctex/texmathp
/usr/local/share/emacs/24.0.92/site-lisp/auctex/context-nl hides /usr/share/emacs/site-lisp/auctex/context-nl
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-font hides /usr/share/emacs/site-lisp/auctex/tex-font
/usr/local/share/emacs/24.0.92/site-lisp/auctex/toolbar-x hides /usr/share/emacs/site-lisp/auctex/toolbar-x
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-buf hides /usr/share/emacs/site-lisp/auctex/tex-buf
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-fptex hides /usr/share/emacs/site-lisp/auctex/tex-fptex
/usr/local/share/emacs/24.0.92/site-lisp/auctex/bib-cite hides /usr/share/emacs/site-lisp/auctex/bib-cite
/usr/local/share/emacs/24.0.92/site-lisp/auctex/context-en hides /usr/share/emacs/site-lisp/auctex/context-en
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-fold hides /usr/share/emacs/site-lisp/auctex/tex-fold
/usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-bar hides /usr/share/emacs/site-lisp/auctex/tex-bar
/usr/local/share/emacs/24.0.92/site-lisp/auctex/context hides /usr/share/emacs/site-lisp/auctex/context
/usr/local/share/emacs/24.0.92/site-lisp/auctex/font-latex hides /usr/share/emacs/site-lisp/auctex/font-latex

Features:
(shadow sort gnus-util mail-extr message sendmail format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug shell pcomplete grep vc-bzr vc-sccs vc-svn vc-cvs vc-rcs vc-dir
ewoc vc ediff-merg ediff-diff ediff-wind ediff-help ediff-util
ediff-mult ediff-init ediff vc-dispatcher texmathp preview prv-emacs
byte-opt warnings tex-buf noutline outline font-latex bytecomp
byte-compile cconv macroexp latex tex-style latexenc help-mode view
dired etags nroff-mode cperl-mode add-log sh-script executable tex-info
texinfo tex sgml-mode make-mode autoconf autoconf-mode inform-mode
multi-isearch ffap cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs lua-mode flymake compile comint ring
vc-git face-remap regexp-opt flyspell smart-quotes diff-git diff-mode
auto-dictionary-autoloads c-eldoc-autoloads dictionary-autoloads
diff-git-autoloads dired-isearch-autoloads full-ack-autoloads
guess-style-autoloads kill-ring-search-autoloads magit-autoloads
mv-shell-autoloads tumble-autoloads http-post-simple-autoloads package
tabulated-list completing-help recentf tree-widget wid-edit uniquify
paren server savehist minibuf-eldef iswitchb ido icomplete whitespace
autorevert desktop cus-start cus-load ropemacs pymacs go-mode-load
ispell advice advice-preload yasnippet help-fns derived edmacro kmacro
easymenu assoc cl muse-autoloads emacs-goodies-el emacs-goodies-custom
emacs-goodies-loaddefs easy-mmode preview-latex tex-site auto-loads
user-site-loaddefs time-date tooltip ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

-- 
http://rrt.sc3d.org/

Message #12 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#10613: 24.0.92;
	Odd behavior of kill interspersed with suspend: document or change?
Date: Thu, 02 Feb 2012 01:10:53 -0700

On 1/26/12 8:21 AM, Reuben Thomas wrote:
> If a sequence of kill commands is interspersed with a suspend
> (suspend-emacs or suspend-frame, for example), then the kills are not
> treated as a contiguous sequence, and a following yank does not yank all
> the text killed.
>
> This feels a bit odd, as “suspend” is not a normal command: rather like
> suspending a computer, I expect that after resuming Emacs, it will be in
> the same state as when suspended. But this is not the case: if one
> suspends Emacs after a kill command, then on resumption a further kill
> will start a new kill-ring entry.

What is abnormal about the suspend-* commands, from Emacs' perspective?

> Is this behavior worth reconsidering? If not, is it worth documenting?
> (Presumably under suspend, rather than under killing, as I imagine this
> behavior changing has implications for things beyond the kill-ring.)
..

-- 
Kevin Rodgers
Denver, Colorado, USA

Message #15 received at 10613 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
Cc: 10613 <at> debbugs.gnu.org
Subject: Re: bug#10613: 24.0.92;
 Odd behavior of kill interspersed with suspend: document or change?
Date: Mon, 12 Feb 2018 19:32:50 -0500

tags 10613 notabug
close 10613
quit

Kevin Rodgers <kevin.d.rodgers <at> gmail.com> writes:

> On 1/26/12 8:21 AM, Reuben Thomas wrote:

>> This feels a bit odd, as “suspend” is not a normal command: rather like
>> suspending a computer, I expect that after resuming Emacs, it will be in
>> the same state as when suspended. But this is not the case: if one
>> suspends Emacs after a kill command, then on resumption a further kill
>> will start a new kill-ring entry.
>
> What is abnormal about the suspend-* commands, from Emacs' perspective?

Yeah, emacs-suspend is not abnormal, not documented as abnormal, and I
see no reason to make it abnormal.

Message #22 received at 10613 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: 10613 <at> debbugs.gnu.org
Subject: Please consider this report again
Date: Tue, 13 Feb 2018 09:19:04 +0000

[Message part 1 (text/plain, inline)]

Unfortunately the two responses to my report seem to have focussed on just
one word, which I probably chose badly. Sorry about that.

But I think the report remains valid: suspending Emacs is not a movement,
not an editing command, so why should it affect the behaviour of the next
kill?

Consider: if I suspend the computer on which I am running Emacs, then it
does not affect the behaviour of Emacs in any way (or shouldn't!). When I
resume, Emacs will behave exactly as if nothing had happened in the interim
(other than time having passed).

So from Emacs's perspective, why should "suspend-emacs" behave differently?

-- 
https://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #25 received at 10613 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 10613 <at> debbugs.gnu.org
Subject: Re: bug#10613: Please consider this report again
Date: Wed, 14 Feb 2018 19:05:06 +0200

> From: Reuben Thomas <rrt <at> sc3d.org>
> Date: Tue, 13 Feb 2018 09:19:04 +0000
> 
> But I think the report remains valid: suspending Emacs is not a movement, not an editing command, so why
> should it affect the behaviour of the next kill?
> 
> Consider: if I suspend the computer on which I am running Emacs, then it does not affect the behaviour of
> Emacs in any way (or shouldn't!). When I resume, Emacs will behave exactly as if nothing had happened in
> the interim (other than time having passed).
> 
> So from Emacs's perspective, why should "suspend-emacs" behave differently?

There's any number of Emacs commands that are neither movement nor
editing.  For example, iconify-frame.

It might be a useful feature to not interrupt a series of kills across
these commands, but that's not how this feature was programmed: it
specifically looks at the last command, and makes no exceptions.

So this is not a bug, it's a request for a new feature.

Message #28 received at 10613 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10613 <at> debbugs.gnu.org, Reuben Thomas <rrt <at> sc3d.org>
Subject: Re: bug#10613: Please consider this report again
Date: Wed, 14 Feb 2018 20:51:57 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Reuben Thomas <rrt <at> sc3d.org>
>> Date: Tue, 13 Feb 2018 09:19:04 +0000
>> 
>> But I think the report remains valid: suspending Emacs is not a movement, not an editing command, so why
>> should it affect the behaviour of the next kill?
>> 
>> Consider: if I suspend the computer on which I am running Emacs, then it does not affect the behaviour of
>> Emacs in any way (or shouldn't!). When I resume, Emacs will behave exactly as if nothing had happened in
>> the interim (other than time having passed).
>> 
>> So from Emacs's perspective, why should "suspend-emacs" behave differently?
>
> There's any number of Emacs commands that are neither movement nor
> editing.  For example, iconify-frame.
>
> It might be a useful feature to not interrupt a series of kills across
> these commands, but that's not how this feature was programmed: it
> specifically looks at the last command, and makes no exceptions.
>
> So this is not a bug, it's a request for a new feature.

IMO, it's not a useful feature, it sounds like quite a bit more
complexity both in implementation and usage, for very little benefit.

Message #31 received at 10613 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Reuben Thomas <rrt <at> sc3d.org>, 10613 <at> debbugs.gnu.org
Subject: Re: bug#10613: Please consider this report again
Date: Wed, 14 Feb 2018 18:00:18 -0800

On 02/13/2018 01:19 AM, Reuben Thomas wrote:
> Unfortunately the two responses to my report seem to have focussed on 
> just one word, which I probably chose badly. Sorry about that.
> 
> But I think the report remains valid: suspending Emacs is not a 
> movement, not an editing command, so why should it affect the behaviour 
> of the next kill?
> 
> Consider: if I suspend the computer on which I am running Emacs, then it 
> does not affect the behaviour of Emacs in any way (or shouldn't!). When 
> I resume, Emacs will behave exactly as if nothing had happened in the 
> interim (other than time having passed).
> 
> So from Emacs's perspective, why should "suspend-emacs" behave differently?
> 

I'd argue that Emacs should detect computer suspension somehow, treat it 
as a command, and reset any closely-spaced-interaction state it's been 
keeping. I don't think the original report is a bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.