From unknown Fri Aug 15 21:23:08 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10613: 24.0.92; Odd behavior of kill interspersed with suspend: document or change? Resent-From: Reuben Thomas Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jan 2012 15:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 10613 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 10613@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.132759134613001 (code B ref -1); Thu, 26 Jan 2012 15:23:01 +0000 Received: (at submit) by debbugs.gnu.org; 26 Jan 2012 15:22:26 +0000 Received: from localhost ([127.0.0.1]:45689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RqR9d-0003Nd-PX for submit@debbugs.gnu.org; Thu, 26 Jan 2012 10:22:26 -0500 Received: from eggs.gnu.org ([140.186.70.92]:59413) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RqR9a-0003NP-SO for submit@debbugs.gnu.org; Thu, 26 Jan 2012 10:22:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqR8s-0001pe-L0 for submit@debbugs.gnu.org; Thu, 26 Jan 2012 10:21:44 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:48334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqR8s-0001pa-JD for submit@debbugs.gnu.org; Thu, 26 Jan 2012 10:21:38 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqR8j-0001dy-3L for bug-gnu-emacs@gnu.org; Thu, 26 Jan 2012 10:21:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqR8Y-0001me-Uh for bug-gnu-emacs@gnu.org; Thu, 26 Jan 2012 10:21:29 -0500 Received: from exprod7og119.obsmtp.com ([64.18.2.16]:34640) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RqR8Y-0001mJ-J1 for bug-gnu-emacs@gnu.org; Thu, 26 Jan 2012 10:21:18 -0500 Received: from mail-we0-f169.google.com ([74.125.82.169]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTyFvbMR/2xvH35ao5G3IFHRCkR2hU0WW@postini.com; Thu, 26 Jan 2012 07:21:18 PST Received: by mail-we0-f169.google.com with SMTP id a13so537646wer.28 for ; Thu, 26 Jan 2012 07:21:16 -0800 (PST) Received: by 10.216.138.220 with SMTP id a70mr1549494wej.24.1327591276179; Thu, 26 Jan 2012 07:21:16 -0800 (PST) Received: from skwd (87-194-87-241.bethere.co.uk. [87.194.87.241]) by mx.google.com with ESMTPS id fr8sm13518270wib.10.2012.01.26.07.21.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 07:21:15 -0800 (PST) From: Reuben Thomas Date: Thu, 26 Jan 2012 15:21:15 +0000 Message-ID: <87ehum32xg.fsf@sc3d.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) 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 =E2=80=9Csuspend=E2=80=9D 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=3Dnone 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: =20 s SPC M-d M-d=20 M-d s C-x C-s C-x b =20 =20 =20 =20 =20 =20 SPC C-x C-s =20 C-x b t e t e s =20 C-x k C-x b s w i C-x b =20 ` C-e SPC . . =20 SPC . . SPC " ' " C-x C-s C-x C-g M-< C-s i o . s t=20 d e r r C-s C-s C-s C-a C-x b C-s C-a =20 =20 =20 =20 ` =20 SPC . . SPC ' ' ' =20 @ ' ' =20 " ' " C-x C-s =20 C-h w y a n k C-h f y a n k =20 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=20 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=20 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=20 C-n C-h k k i l l =3D - C-_ C-h f k i l l - l i n e =20 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=20 r e p o r t - b u e m a c s=20 - b u g 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, , , Type "q" to restore previous buffer. byte-code: Beginning of buffer [5 times] k is undefined Buffer is read-only: # Mark saved where search started Load-path shadows: /home/rrt/.emacs.d/elpa/dictionary-1.8.7/dictionary-init hides /usr/local/s= hare/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/2= 4.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/em= acs/site-lisp/auctex/tex-mik /usr/local/share/emacs/24.0.92/site-lisp/auctex/multi-prompt hides /usr/sha= re/emacs/site-lisp/auctex/multi-prompt /usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-jp hides /usr/share/ema= cs/site-lisp/auctex/tex-jp /usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-info hides /usr/share/e= macs/site-lisp/auctex/tex-info /usr/local/share/emacs/24.0.92/site-lisp/auctex/latex hides /usr/share/emac= s/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/e= macs/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/e= macs/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/em= acs/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/e= macs/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/e= macs/site-lisp/auctex/tex-fold /usr/local/share/emacs/24.0.92/site-lisp/auctex/tex-bar hides /usr/share/em= acs/site-lisp/auctex/tex-bar /usr/local/share/emacs/24.0.92/site-lisp/auctex/context hides /usr/share/em= acs/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) --=20 http://rrt.sc3d.org/ From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 26 14:33:43 2012 Received: (at control) by debbugs.gnu.org; 26 Jan 2012 19:33:43 +0000 Received: from localhost ([127.0.0.1]:45863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RqV4o-0005ci-UP for submit@debbugs.gnu.org; Thu, 26 Jan 2012 14:33:43 -0500 Received: from [140.186.70.10] (port=54274 helo=fencepost.gnu.org ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RqV4n-0005bs-0G for control@debbugs.gnu.org; Thu, 26 Jan 2012 14:33:42 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RqV3d-0001ES-8z for control@debbugs.gnu.org; Thu, 26 Jan 2012 14:32:29 -0500 Date: Thu, 26 Jan 2012 14:32:29 -0500 Message-Id: Subject: control message for bug 10615 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) forcemerge 10613 10615 From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 26 14:35:32 2012 Received: (at control) by debbugs.gnu.org; 26 Jan 2012 19:35:32 +0000 Received: from localhost ([127.0.0.1]:45867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RqV6Z-0005g0-10 for submit@debbugs.gnu.org; Thu, 26 Jan 2012 14:35:31 -0500 Received: from [140.186.70.10] (port=54309 helo=fencepost.gnu.org ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RqV6W-0005ef-MT for control@debbugs.gnu.org; Thu, 26 Jan 2012 14:35:29 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RqV5N-0001Jz-BJ for control@debbugs.gnu.org; Thu, 26 Jan 2012 14:34:17 -0500 Date: Thu, 26 Jan 2012 14:34:17 -0500 Message-Id: Subject: control message for bug 10613 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) unmerge 10613 From unknown Fri Aug 15 21:23:08 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10613: 24.0.92; Odd behavior of kill interspersed with suspend: document or change? Resent-From: Kevin Rodgers Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Feb 2012 08:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10613 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 10613@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.132817026512959 (code B ref -1); Thu, 02 Feb 2012 08:12:01 +0000 Received: (at submit) by debbugs.gnu.org; 2 Feb 2012 08:11:05 +0000 Received: from localhost ([127.0.0.1]:49923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rsrl2-0003Mx-Bh for submit@debbugs.gnu.org; Thu, 02 Feb 2012 03:11:05 -0500 Received: from eggs.gnu.org ([140.186.70.92]:54324) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rsrkw-0003MQ-OA for submit@debbugs.gnu.org; Thu, 02 Feb 2012 03:11:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsrkM-000274-1t for submit@debbugs.gnu.org; Thu, 02 Feb 2012 03:10:27 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:41634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsrkM-000270-0P for submit@debbugs.gnu.org; Thu, 02 Feb 2012 03:10:22 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsrkH-000106-U8 for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2012 03:10:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsrkD-00026R-Ow for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2012 03:10:17 -0500 Received: from plane.gmane.org ([80.91.229.3]:52579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsrkD-00026F-Jv for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2012 03:10:13 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Rsrk7-000512-Pz for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2012 09:10:07 +0100 Received: from c-71-237-25-24.hsd1.co.comcast.net ([71.237.25.24]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Feb 2012 09:10:07 +0100 Received: from kevin.d.rodgers by c-71-237-25-24.hsd1.co.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Feb 2012 09:10:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ From: Kevin Rodgers Date: Thu, 02 Feb 2012 01:10:53 -0700 Lines: 22 Message-ID: References: <87ehum32xg.fsf@sc3d.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: c-71-237-25-24.hsd1.co.comcast.net User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 In-Reply-To: <87ehum32xg.fsf@sc3d.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) 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 From unknown Fri Aug 15 21:23:08 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10613: 24.0.92; Odd behavior of kill interspersed with suspend: document or change? Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Feb 2018 00:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10613 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Kevin Rodgers Cc: 10613@debbugs.gnu.org Received: via spool by 10613-submit@debbugs.gnu.org id=B10613.15184819793385 (code B ref 10613); Tue, 13 Feb 2018 00:33:01 +0000 Received: (at 10613) by debbugs.gnu.org; 13 Feb 2018 00:32:59 +0000 Received: from localhost ([127.0.0.1]:40234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elOWp-0000sR-7D for submit@debbugs.gnu.org; Mon, 12 Feb 2018 19:32:59 -0500 Received: from mail-io0-f182.google.com ([209.85.223.182]:35604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elOWo-0000sC-83; Mon, 12 Feb 2018 19:32:58 -0500 Received: by mail-io0-f182.google.com with SMTP id m11so19384242iob.2; Mon, 12 Feb 2018 16:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Fd+KKtAsFXKbh67wr1Pd1yh5nTNeGwWTdcBXN67OMdc=; b=fMhGeHHSiB/k+GJbrXhZoh2PeV/ompOScbV4foVizaE9Ef8BwfNyXzdNN2TfT97gdc 9Ffcf/2yBnJx8z0P9oHuMp9pYufNNZh1JCLniQsPhJPyU71qyg7IUhhCgw8NNuAfHPo5 M4gfiLUltzWRzWxN85xg6bqeQvlwA0ZU25pFPlO/DSEmZteQ/g+vbQGER1AdkaF78c0d NmLQk0LsJu/iMzXUN+BP/u4a+/OxDpQIfxUeffokj0hmPjHJoyoXS4IWFW8jhJdBhcHW PYqxzbMS/Dv97ZlQCyaJMpBD/JL+nOPlagsl926Q9AdJrb7J6DaEFcDUGbLOQ2XQFRh3 xrEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding; bh=Fd+KKtAsFXKbh67wr1Pd1yh5nTNeGwWTdcBXN67OMdc=; b=Tmd+0SA2HwYpm/mBEA8Id6cmWF65bwcWMlN2nAKezaJrjt2Qo+hvhBPL4J0JLnRJYK wyF58gDLY/fWPyrmzp/YwcHSUkLwqW43dq6XIF6wtoXlilry53EJVCz6Wu/78aLFvwiS PJ8m5Y5FXR1O3FC4sRqkQfjPKM6aMzQ5DK8SopY/KbYPXNi7S6+tmOeZmBqnWxIt6pIr GMBEuBtWVXYVUcA4zc/PU57APOg2qA3/26Wz1yvbZA89a8W3/yO6dBv3Nwq1/mnBug6y LaPLWKxaIYPcuLzUtAIl/d28oX/UTHtndtbhia0Vqgf1kFfKLNNyqeYBJiEbnri7m71x 90Wg== X-Gm-Message-State: APf1xPDqovAE3bzY5UakqMggI7TzAOJviWxtdfyT0MHNsIqe3xH53ktP TNADx6GujNw8oYmACI3HZDMPLQ== X-Google-Smtp-Source: AH8x224ZoawQda2NTgN1ANHtXHidUwDWy1wDzAbE6Z7pP6e5INQXQWnxZFPBrqkgQVdR+EvG/yAEGQ== X-Received: by 10.107.112.15 with SMTP id l15mr15875723ioc.68.1518481972413; Mon, 12 Feb 2018 16:32:52 -0800 (PST) Received: from zebian (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.googlemail.com with ESMTPSA id s32sm5690377ite.1.2018.02.12.16.32.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 12 Feb 2018 16:32:51 -0800 (PST) From: Noam Postavsky References: <87ehum32xg.fsf@sc3d.org> Date: Mon, 12 Feb 2018 19:32:50 -0500 In-Reply-To: (Kevin Rodgers's message of "Thu, 02 Feb 2012 01:10:53 -0700") Message-ID: <87po59afv1.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.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: 0.3 (/) tags 10613 notabug close 10613 quit Kevin Rodgers writes: > On 1/26/12 8:21 AM, Reuben Thomas wrote: >> This feels a bit odd, as =E2=80=9Csuspend=E2=80=9D is not a normal comma= nd: 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. From unknown Fri Aug 15 21:23:08 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10613: Please consider this report again References: <87ehum32xg.fsf@sc3d.org> In-Reply-To: <87ehum32xg.fsf@sc3d.org> Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Feb 2018 09:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10613 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: 10613@debbugs.gnu.org Received: via spool by 10613-submit@debbugs.gnu.org id=B10613.15185135531347 (code B ref 10613); Tue, 13 Feb 2018 09:20:02 +0000 Received: (at 10613) by debbugs.gnu.org; 13 Feb 2018 09:19:13 +0000 Received: from localhost ([127.0.0.1]:40409 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elWk4-0000Lf-V8 for submit@debbugs.gnu.org; Tue, 13 Feb 2018 04:19:13 -0500 Received: from mail-ot0-f172.google.com ([74.125.82.172]:39585) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elWk3-0000LR-5Q for 10613@debbugs.gnu.org; Tue, 13 Feb 2018 04:19:11 -0500 Received: by mail-ot0-f172.google.com with SMTP id f18so16699485otf.6 for <10613@debbugs.gnu.org>; Tue, 13 Feb 2018 01:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=e2w4+7qPjJEVswqTXio+24Bn6lGVY33xIYw8OnLdQn8=; b=DwAy3AbYnFADhuSMppCTGG7j8/jOFTnJv4pDBdIps0haOP9w3xTBvbsyg1qviTCUMe 7txUiFShZWXSXE6BsW9FJKMxpy54XdTCabuBhnWnVUmPQQGPOIO5mq6jXzaDB7Fvqp3p uA0yhZpU94CCchgIFsdBAEoaEoXml8d439Kqo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e2w4+7qPjJEVswqTXio+24Bn6lGVY33xIYw8OnLdQn8=; b=s0eRwJG6YaBYrxK4sf/V0Dcw3ArsH1jKV2+Ek6092YlMOeZHxkCONYnFHOblXAj/l5 VgVQRQz06DlY/yhTNBvOjIvlcuKIxNrULCi45ErrffVTKN4+/ygtpP9gnOIQjb8DAvtR lgupoivMjxz92wioqe+YXRXSgE5jZ9q2R3iCE3YnI/IZf93cNvYkF3Es1LHKXvJOwmoF M6DuL1ztzMFkkaN8V9veUdn3ZA2RKzQlZrOH5DHetTmpy9IxRnq+oZ2dFaxdke2tAMSz a19U1XnlIYmtSOOzsqUYNnw6dxbqz3ZLKA0xQ+Qpk73nlPdZEY+XmtFxxzncgIxdK9Qm R/ug== X-Gm-Message-State: APf1xPAR377Tz3pi/WkUxufmtKq54i77CS9qXThFhczUXRGWdoF/bwOR 0W8UH65yV+HK19uVVgAxDYe4lsNQvFAAfiT229e8AqBo X-Google-Smtp-Source: AH8x224LNAjNyiGvDjY/Mh4UF/uYuN48PH4cijreWsOaKh/Y/acRQvBWj0qEBSSYYs8OReqRS/HsQK8ELzGtACbEQ5Q= X-Received: by 10.157.47.200 with SMTP id b8mr402696otd.194.1518513544893; Tue, 13 Feb 2018 01:19:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.12.180 with HTTP; Tue, 13 Feb 2018 01:19:04 -0800 (PST) From: Reuben Thomas Date: Tue, 13 Feb 2018 09:19:04 +0000 Message-ID: Content-Type: multipart/alternative; boundary="001a113e4cf26e2ce80565147c6c" 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: -0.0 (/) --001a113e4cf26e2ce80565147c6c Content-Type: text/plain; charset="UTF-8" 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 --001a113e4cf26e2ce80565147c6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unfortunately the two responses to my= report seem to have focussed on just one word, which I probably chose badl= y. Sorry about that.

But I think the repo= rt remains valid: suspending Emacs is not a movement, not an editing comman= d, 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 shoul= dn't!). When I resume, Emacs will behave exactly as if nothing had happ= ened in the interim (other than time having passed).

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

--
=
--001a113e4cf26e2ce80565147c6c-- From unknown Fri Aug 15 21:23:08 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10613: Please consider this report again Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Feb 2018 17:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10613 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Reuben Thomas Cc: 10613@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 10613-submit@debbugs.gnu.org id=B10613.15186279257888 (code B ref 10613); Wed, 14 Feb 2018 17:06:02 +0000 Received: (at 10613) by debbugs.gnu.org; 14 Feb 2018 17:05:25 +0000 Received: from localhost ([127.0.0.1]:43084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em0Um-00023A-Rf for submit@debbugs.gnu.org; Wed, 14 Feb 2018 12:05:25 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em0Ul-00022x-7A for 10613@debbugs.gnu.org; Wed, 14 Feb 2018 12:05:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1em0Ub-0004u9-1v for 10613@debbugs.gnu.org; Wed, 14 Feb 2018 12:05:17 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1em0Ua-0004tr-U5; Wed, 14 Feb 2018 12:05:12 -0500 Received: from [176.228.60.248] (port=1234 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1em0Ua-0007hs-7Y; Wed, 14 Feb 2018 12:05:12 -0500 Date: Wed, 14 Feb 2018 19:05:06 +0200 Message-Id: <83606zy01q.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Reuben Thomas on Tue, 13 Feb 2018 09:19:04 +0000) References: <87ehum32xg.fsf@sc3d.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.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: -5.0 (-----) > From: Reuben Thomas > 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. From unknown Fri Aug 15 21:23:08 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10613: Please consider this report again Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Feb 2018 01:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10613 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Eli Zaretskii Cc: 10613@debbugs.gnu.org, Reuben Thomas Received: via spool by 10613-submit@debbugs.gnu.org id=B10613.1518659527625 (code B ref 10613); Thu, 15 Feb 2018 01:53:01 +0000 Received: (at 10613) by debbugs.gnu.org; 15 Feb 2018 01:52:07 +0000 Received: from localhost ([127.0.0.1]:43496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em8iV-0000A0-FS for submit@debbugs.gnu.org; Wed, 14 Feb 2018 20:52:07 -0500 Received: from mail-io0-f172.google.com ([209.85.223.172]:36684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em8iT-00009W-Fa for 10613@debbugs.gnu.org; Wed, 14 Feb 2018 20:52:05 -0500 Received: by mail-io0-f172.google.com with SMTP id t22so7318756iob.3 for <10613@debbugs.gnu.org>; Wed, 14 Feb 2018 17:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=cWbmgp+2eoLaBuEFWqq5RAJ1frHtcnx0RX2W8yWH4x4=; b=ob5mi8sWB9qikNnn2a2rmhQkwfDQw7WAcniP7jnhNx1Jcp01unXlDPQQ8hvc1FUONn 0Zcbpp9sP+4qigLXkX2tl2aT4UgywxZSnP813h0KesHscq72z/ucOw8YXuu3qtmzHXRw huZMYc36QraWA7HxsSj/FdmGJPENhp2ebjLIiWLnE7RdMj3m+/mfaf13A+41AHZVivjT iBTJ/IbEvpnIn9+IVxOhjYCODkFuuW9pOVIa7+o2m18L0z6QndjmD3d+8SxhTHJz8odu LGNl8RUgmQ6SRf2YZFZrYkJj61XpDKxpoPnHlTilJsV03qaPxUulU8eyhst9Z0hUyCJp KqPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=cWbmgp+2eoLaBuEFWqq5RAJ1frHtcnx0RX2W8yWH4x4=; b=bx7H7cnXAP3LO4l52gbdLxKYc2qc+22zDMiSc0Y1yr75MXd/pp5NoFbShB9eKL75au s/Cyk/wiwthW5JSXv0GckcKjn6OPvY12WlJeESiO761ry/VR1N1EcOvjDpWEMbStbOeK PUk5PGp+G/2Wph6jxj+kETuI81sk/1S2yl1PwqFyAICxdDSiI1o8vQpmQ3Z3WeKGewfx HGfK4Ztzg8JL8igk2APgzhfo/POYA4VWLPyLPavUrNr1z6lZJrY0hJ5tXEYb+N8h/Gb1 tFxW5li/04JbHZkb5XeyRXF/0zxkDPC9Phq4zdXBmc42/lMF4U5/Y17A5d5nGaN5UDe+ vwSg== X-Gm-Message-State: APf1xPDDnDhxf758NPqqyxW/WdAeD3B7ffd5rXIRZmo6SB2ixSxgtYYE z4bPLfDI087qg0nlUYOCm7Zaxw== X-Google-Smtp-Source: AH8x225EtOZz4ns+VTh1X8l5Vd/VcWmUOrsC8XDdMq2IRCDljn08l6NOSX0J5wcyH6eY2Tz1SalWlA== X-Received: by 10.107.79.2 with SMTP id d2mr1615393iob.21.1518659519794; Wed, 14 Feb 2018 17:51:59 -0800 (PST) Received: from zebian (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.googlemail.com with ESMTPSA id v99sm8792517iov.24.2018.02.14.17.51.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Feb 2018 17:51:58 -0800 (PST) From: Noam Postavsky References: <87ehum32xg.fsf@sc3d.org> <83606zy01q.fsf@gnu.org> Date: Wed, 14 Feb 2018 20:51:57 -0500 In-Reply-To: <83606zy01q.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 14 Feb 2018 19:05:06 +0200") Message-ID: <877erf81fm.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 0.0 (/) Eli Zaretskii writes: >> From: Reuben Thomas >> 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. From unknown Fri Aug 15 21:23:08 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10613: Please consider this report again Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Feb 2018 02:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10613 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Reuben Thomas , 10613@debbugs.gnu.org Received: via spool by 10613-submit@debbugs.gnu.org id=B10613.15186600291455 (code B ref 10613); Thu, 15 Feb 2018 02:01:01 +0000 Received: (at 10613) by debbugs.gnu.org; 15 Feb 2018 02:00:29 +0000 Received: from localhost ([127.0.0.1]:43500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em8qa-0000NO-Ae for submit@debbugs.gnu.org; Wed, 14 Feb 2018 21:00:28 -0500 Received: from dancol.org ([96.126.100.184]:53420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1em8qX-0000NF-US for 10613@debbugs.gnu.org; Wed, 14 Feb 2018 21:00:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=ndKKa6FX1SoILUWgth9FAsgsx3A22ar38Irs0j7XRNc=; b=HgmAfhN8UtHq6anwRAwtCwy4qugAeVjHFtdIUUXGOm25BusviBEdd6v+/0JLKazAPE6+oIdka+FBvGiF655CzKorjQxhloy7K7Rbur9MFL8i5su8U5r5ZzqwumF2yE8+3osHEWiPGMg/acoImANU2t1US3MwUHisnRzIDuk0tsGtrkO/6n1KWqfcbVgt54NvwU0S6hF3uataSWo7x9sOdovFLgBhks5RcuRzzKhukR/CPefnYGRIKEJpfuLaujz921pFKuKPwsnsPkZDRLT5OFC+wo9fMQtrevyhv42ndN9f4tAAIcK/mHlH0fIoEdzn0TLlOca7mcNxPUFVYo+26w==; Received: from [2604:4080:1321:8ab0:61ba:edb0:2809:b86b] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1em8qW-0004t1-64; Wed, 14 Feb 2018 18:00:24 -0800 References: <87ehum32xg.fsf@sc3d.org> From: Daniel Colascione Message-ID: <33f5af87-b578-a6fc-22a2-55188734e3ba@dancol.org> Date: Wed, 14 Feb 2018 18:00:18 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: -0.0 (/) 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.