unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Kevin Rodgers <kevin.d.rodgers@gmail.com>
To: bug-gnu-emacs@gnu.org
Subject: bug#1973: Bug in simple.el (Emacs version 22.2.1)
Date: Tue, 20 Jan 2009 21:59:58 -0700	[thread overview]
Message-ID: <gl6a2s$vkp$1@ger.gmane.org> (raw)
In-Reply-To: <63k9n3fx.fsf@vps203.linuxvps.org>

Sebastian Tennant wrote:
> Hello all,
> 
> Asynchronous commands called via shell-command, for example:
> 
>  (shell-command "apt-get update &")
> 
> fill the buffer *Async Shell Command Output* with Ctrl-Ms, which I'm
> sure is not what's intended.
> 
> My patch (attached) fixes this by using make-comint-in-buffer, rather
> than start-process, to call the asynchronous process.

I don't experience that with emacs -Q on:

GNU Emacs 22.3.1 (i386-apple-darwin8.11.1, Carbon Version 1.6.0)

What does `C-h C RET' in the *Async Shell Command Output* show?  Mine
says:

Coding system for saving this buffer:
   Not set locally, use the default.
Default coding system (for new files):
   1 -- iso-latin-1 (alias: iso-8859-1 latin-1)

Coding system for keyboard input:
   nil
Coding system for terminal output:
   1 -- iso-8859-1 (alias of iso-latin-1)

Defaults for subprocess I/O:
   decoding: 1 -- iso-latin-1 (alias: iso-8859-1 latin-1)

   encoding: 1 -- iso-latin-1 (alias: iso-8859-1 latin-1)


Priority order for recognizing coding systems when reading files:
   1. iso-latin-1 (alias: iso-8859-1 latin-1)
   2. mule-utf-8 (alias: utf-8)
   3. mule-utf-16be-with-signature (alias: utf-16be-with-signature 
mule-utf-16-be utf-16-be)
   4. mule-utf-16le-with-signature (alias: utf-16le-with-signature 
mule-utf-16-le utf-16-le)
   5. iso-2022-jp (alias: junet)
   6. iso-2022-7bit
   7. iso-2022-7bit-lock (alias: iso-2022-int-1)
   8. iso-2022-8bit-ss2
   9. emacs-mule
   10. raw-text
   11. japanese-shift-jis (alias: shift_jis sjis cp932)
   12. chinese-big5 (alias: big5 cn-big5 cp950)
   13. no-conversion

   Other coding systems cannot be distinguished automatically
   from these, and therefore cannot be recognized automatically
   with the present coding system priorities.

   The following are decoded correctly but recognized as iso-2022-7bit-lock:
     iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext
     iso-2022-jp-2 iso-2022-kr

Particular coding systems specified for certain file names:

   OPERATION	TARGET PATTERN		CODING SYSTEM(s)
   ---------	--------------		----------------
   File I/O	"\\.dz\\'"		(no-conversion . no-conversion)
		"\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'"
					(no-conversion . no-conversion)
		"\\.tgz\\'"		(no-conversion . no-conversion)
		"\\.tbz\\'"		(no-conversion . no-conversion)
		"\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'"
					(no-conversion . no-conversion)
		"\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'"
					(no-conversion . no-conversion)
		"\\.elc\\'"		(emacs-mule . emacs-mule)
		"\\.utf\\(-8\\)?\\'"	utf-8
		"\\(\\`\\|/\\)loaddefs.el\\'"
					(raw-text . raw-text-unix)
		"\\.tar\\'"		(no-conversion . no-conversion)
		"\\.po[tx]?\\'\\|\\.po\\."
					po-find-file-coding-system
		"\\.\\(tex\\|ltx\\|dtx\\|drv\\)\\'"
					latexenc-find-file-coding-system
		""			(undecided)
   Process I/O	nothing specified
   Network I/O	nothing specified

-- 
Kevin Rodgers
Denver, Colorado, USA








  reply	other threads:[~2009-01-21  4:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87ocqnneu3.fsf@cyd.mit.edu>
2009-01-20 20:10 ` bug#1973: Bug in simple.el (Emacs version 22.2.1) Sebastian Tennant
2009-01-21  4:59   ` Kevin Rodgers [this message]
2009-01-21 10:34     ` Sebastian Tennant
2009-01-21 22:04   ` Stefan Monnier
2009-01-22  8:45     ` Sebastian Tennant
2009-01-22 15:09       ` Stefan Monnier
2009-01-22 18:07         ` Sebastian Tennant
2009-01-22 21:30           ` Stefan Monnier
2009-01-22 23:15             ` Sebastian Tennant
2009-01-23  7:53               ` Stefan Monnier
2009-01-23 10:46                 ` Sebastian Tennant
2009-01-23 18:01                   ` Sebastian Tennant
2009-01-25 17:58                     ` Sebastian Tennant
2009-01-22 14:00   ` Sebastian Tennant
2009-01-22 18:27     ` Sebastian Tennant
2009-08-11  4:45   ` bug#1973: marked as done (Bug in simple.el (Emacs version 22.2.1)) Emacs bug Tracking System
2009-01-24 21:14 bug#1973: Bug in simple.el (Emacs version 22.2.1) Stefan Monnier
2009-02-04  9:47 ` Sebastian Tennant
     [not found] <63k0dk26.fsf@vps203.linuxvps.org>
     [not found] ` <jwveiyno719.fsf-monnier+emacs@gnu.org>
2009-01-29  7:06   ` bug#2103: Bug in simple.el Sebastian Tennant
2009-08-11  4:45     ` bug#2103: marked as done (Bug in simple.el) Emacs bug Tracking System

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='gl6a2s$vkp$1@ger.gmane.org' \
    --to=kevin.d.rodgers@gmail.com \
    --cc=1973@emacsbugs.donarmstrong.com \
    --cc=bug-gnu-emacs@gnu.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).