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

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

[Reuben Thomas]

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/

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

[Kevin Rodgers]

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

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

[Noam Postavsky]

tags 10613 notabug
close 10613
quit

Kevin Rodgers <kevin.d.rodgers@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.

bug#10613: Please consider this report again

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1261 bytes --]

bug#10613: Please consider this report again

[Eli Zaretskii]

> From: Reuben Thomas <rrt@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.

bug#10613: Please consider this report again

[Noam Postavsky]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Reuben Thomas <rrt@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.

bug#10613: Please consider this report again

[Daniel Colascione]

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.