all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: owner@emacsbugs.donarmstrong.com (Emacs bug Tracking System)
To: Chong Yidong <cyd@stupidchicken.com>
Subject: bug#4891: marked as done (23.1; shell-command overwrites whole buffer)
Date: Sat, 14 Nov 2009 16:15:05 +0000	[thread overview]
Message-ID: <handler.4891.D4891.12582149799061.ackdone@emacsbugs.donarmstrong.com> (raw)
In-Reply-To: 20091109111414.B55872414F@arctic.adamspiers.org

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

Your message dated Sat, 14 Nov 2009 11:09:30 -0500
with message-id <871vk1hyv9.fsf@stupidchicken.com>
and subject line Re: 23.1; shell-command overwrites whole buffer
has caused the Emacs bug report #4891,
regarding 23.1; shell-command overwrites whole buffer
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
4891: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4891
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 5159 bytes --]

From: Adam Spiers <bug-gnu-emacs@adamspiers.org>
To: bug-gnu-emacs@gnu.org
Subject: 23.1; shell-command overwrites whole buffer
Date: Mon,  9 Nov 2009 11:14:14 +0000 (UTC)
Message-ID: <20091109111414.B55872414F@arctic.adamspiers.org>

Starting emacs 23.1.1 with the '-q' argument and typing:

  M-: (shell-command "date" (get-buffer "*scratch*"))

results in the prior contents of the *scratch* buffer being
overwritten.  This seems to contradict the last sentence in the
following paragraph of the docstring for shell-command:

    The optional second argument output-buffer, if non-nil, says to
    put the output in some other buffer.  If output-buffer is a buffer
    or buffer name, put the output there.  If output-buffer is not a
    buffer and not nil, insert output in current buffer.  (This cannot
    be done asynchronously.)  In either case, the output is inserted
    after point (leaving mark after it).

In GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.16.6)
 of 2009-09-29 on x86-7.fedora.phx.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.10603901
configured using `configure  '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xft' '--with-xpm' '--with-x-toolkit=gtk' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-bu
 ffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-: ( s h e l l - c o m m a n d SPC " d a t e " S-SPC 
( g e t - b u f f e r SPC " * s c r a t c h * " ) ) 
<return> C-x b <return> M-x r e p o r <tab> 
<return>

Recent messages:
Loading /usr/share/emacs/site-lisp/site-start.d/muse-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/php-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/po-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/rpm-spec-mode-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/rpmdev-init.el (source)...done
Loading /usr/share/emacs/site-lisp/site-start.d/ruby-mode-init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Mon Nov  9 10:38:11 GMT 2009
0 (#o0, #x0)
Making completion list...



[-- Attachment #3: Type: message/rfc822, Size: 2352 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: Adam Spiers <bug-gnu-emacs@adamspiers.org>
Cc: 4891-done@emacsbugs.donarmstrong.com
Subject: Re: 23.1; shell-command overwrites whole buffer
Date: Sat, 14 Nov 2009 11:09:30 -0500
Message-ID: <871vk1hyv9.fsf@stupidchicken.com>

>   M-: (shell-command "date" (get-buffer "*scratch*"))
>
> results in the prior contents of the *scratch* buffer being
> overwritten.  This seems to contradict the last sentence in the
> following paragraph of the docstring for shell-command:
>
>     The optional second argument output-buffer, if non-nil, says to
>     put the output in some other buffer.  If output-buffer is a buffer
>     or buffer name, put the output there.  If output-buffer is not a
>     buffer and not nil, insert output in current buffer.  (This cannot
>     be done asynchronously.)  In either case, the output is inserted
>     after point (leaving mark after it).

Thanks for the bug report.  This is really a documentation bug, because
shell-command has always erased the buffer since the first version of
Emacs, and other code depends on this behavior.  I've amended the
docstring to mention that the buffer is erased.

      parent reply	other threads:[~2009-11-14 16:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <871vk1hyv9.fsf@stupidchicken.com>
2009-11-09 11:14 ` bug#4891: 23.1; shell-command overwrites whole buffer Adam Spiers
2009-11-11 10:47   ` Juri Linkov
2009-11-12  1:15     ` Adam Spiers
2009-11-12  4:23       ` Stefan Monnier
2009-11-12  6:42         ` Kevin Rodgers
2009-11-12  9:33         ` Adam Spiers
2009-11-14 16:15   ` Emacs bug Tracking System [this message]

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

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

  git send-email \
    --in-reply-to=handler.4891.D4891.12582149799061.ackdone@emacsbugs.donarmstrong.com \
    --to=owner@emacsbugs.donarmstrong.com \
    --cc=cyd@stupidchicken.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.