unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#7842: 23.2; call-process should be able to send stderr to buffer object
@ 2011-01-14  2:56 ` Jameson Rollins
  2011-01-14  3:56   ` Glenn Morris
       [not found]   ` <handler.7842.C.136026813810926.notifdonectrl.0@debbugs.gnu.org>
  0 siblings, 2 replies; 18+ messages in thread
From: Jameson Rollins @ 2011-01-14  2:56 UTC (permalink / raw)
  To: 7842

Currently the call-process function lets one send stderr to a file by
providing a list as the BUFFER argument which includes the name of a
STDERR-FILE:

(call-process "ls" nil (list t "/path/to/stderr/file") nil "/does-not-exist")

It would be nice if one could instead send stderr directly to a distinct
buffer, i.e.:

(call-process "ls" nil (list t (get-buffer "*scratch*")) nil "/does-not-exist")

If I try that now I get:

Debugger entered--Lisp error: (wrong-type-argument stringp #<buffer *scratch*>)
  call-process("ls" nil (t #<buffer *scratch*>) nil "/does-not-exist")
  eval((call-process "ls" nil (list t (get-buffer "*scratch*")) nil "/does-not-exist"))
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)

Thanks!

In GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2010-11-03 on potassium, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
configured using `configure  '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.2/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

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_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  iswitchb-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<tab> <tab> C-g M-x w r i <tab> t o <tab> <tab> M-b 
C-g M-x i n s <tab> <tab> C-g C-x C-s M-f <right> M-d 
g e t - b u f f e r M-b M-b ( M-f M-f SPC m e s s a 
g e s SPC ) <left> <left> <left> <left> <left> <right> 
<right> <right> <right> M-b C-x b m e s s C-g " * M 
<right> <right> <left> <backspace> M-f * " <right> 
<backspace> <down> <up> C-x C-s <down> <up> M-b M-b 
M-b <left> <left> <left> l i s t SPC M-b <left> <backspace> 
C-x C-s M-f <right> <right> <right> M-d M-d C-d C-x 
C-s M-f <right> <right> C-d C-x C-s <down> <down> <up> 
<up> <up> <down> <down> <up> M-b <left> <left> M-d 
C-d C-d n i l C-x C-s C-x b <return> M-< C-u C-SPC 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> M-x e m <tab> a <tab> b u <tab> <tab> M-b C-k 
f i <tab> <tab> <backspace> <backspace> M-b C-k r e 
<tab> p <tab> o r <tab> M-b <C-tab> C-e <tab> e m <tab> 
<return>

Recent messages:
Saving file /home/jrollins/src/notmuch/git/emacs/notmuch-query.el...
Wrote /home/jrollins/src/notmuch/git/emacs/notmuch-query.el
Saving file /home/jrollins/src/notmuch/git/emacs/notmuch-query.el...
Wrote /home/jrollins/src/notmuch/git/emacs/notmuch-query.el
Saving file /home/jrollins/src/notmuch/git/emacs/notmuch-query.el...
Wrote /home/jrollins/src/notmuch/git/emacs/notmuch-query.el
Saving file /home/jrollins/src/notmuch/git/emacs/notmuch-query.el...
Wrote /home/jrollins/src/notmuch/git/emacs/notmuch-query.el
Mark set
Making completion list... [5 times]

Load-path shadows:
~/.emacs.d/tabbar hides /usr/share/emacs23/site-lisp/emacs-goodies-el/tabbar
~/.emacs.d/matlab hides /usr/share/emacs23/site-lisp/emacs-goodies-el/matlab
/usr/share/emacs23/site-lisp/css-mode/css-mode hides /usr/share/emacs/site-lisp/css-mode/css-mode
/usr/share/emacs/23.2/site-lisp/auctex/toolbar-x hides /usr/share/emacs/site-lisp/auctex/toolbar-x
/usr/share/emacs/23.2/site-lisp/auctex/texmathp hides /usr/share/emacs/site-lisp/auctex/texmathp
/usr/share/emacs/23.2/site-lisp/auctex/tex hides /usr/share/emacs/site-lisp/auctex/tex
/usr/share/emacs/23.2/site-lisp/auctex/tex-style hides /usr/share/emacs/site-lisp/auctex/tex-style
/usr/share/emacs/23.2/site-lisp/auctex/tex-mik hides /usr/share/emacs/site-lisp/auctex/tex-mik
/usr/share/emacs/23.2/site-lisp/auctex/tex-jp hides /usr/share/emacs/site-lisp/auctex/tex-jp
/usr/share/emacs/23.2/site-lisp/auctex/tex-info hides /usr/share/emacs/site-lisp/auctex/tex-info
/usr/share/emacs/23.2/site-lisp/auctex/tex-fptex hides /usr/share/emacs/site-lisp/auctex/tex-fptex
/usr/share/emacs/23.2/site-lisp/auctex/tex-font hides /usr/share/emacs/site-lisp/auctex/tex-font
/usr/share/emacs/23.2/site-lisp/auctex/tex-fold hides /usr/share/emacs/site-lisp/auctex/tex-fold
/usr/share/emacs/23.2/site-lisp/auctex/tex-buf hides /usr/share/emacs/site-lisp/auctex/tex-buf
/usr/share/emacs/23.2/site-lisp/auctex/tex-bar hides /usr/share/emacs/site-lisp/auctex/tex-bar
/usr/share/emacs/23.2/site-lisp/auctex/multi-prompt hides /usr/share/emacs/site-lisp/auctex/multi-prompt
/usr/share/emacs/23.2/site-lisp/auctex/latex hides /usr/share/emacs/site-lisp/auctex/latex
/usr/share/emacs/23.2/site-lisp/auctex/font-latex hides /usr/share/emacs/site-lisp/auctex/font-latex
/usr/share/emacs/23.2/site-lisp/auctex/context hides /usr/share/emacs/site-lisp/auctex/context
/usr/share/emacs/23.2/site-lisp/auctex/context-nl hides /usr/share/emacs/site-lisp/auctex/context-nl
/usr/share/emacs/23.2/site-lisp/auctex/context-en hides /usr/share/emacs/site-lisp/auctex/context-en
/usr/share/emacs/23.2/site-lisp/auctex/bib-cite hides /usr/share/emacs/site-lisp/auctex/bib-cite
/usr/share/emacs23/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/site-lisp/html-helper-mode/tempo
/usr/share/emacs23/site-lisp/html-helper-mode/visual-basic-mode hides /usr/share/emacs/site-lisp/html-helper-mode/visual-basic-mode
/usr/share/emacs23/site-lisp/html-helper-mode/hhm-config hides /usr/share/emacs/site-lisp/html-helper-mode/hhm-config
/usr/share/emacs23/site-lisp/html-helper-mode/html-helper-mode hides /usr/share/emacs/site-lisp/html-helper-mode/html-helper-mode
/usr/share/emacs/site-lisp/haskell-mode/haskell-site-file hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-site-file
/usr/share/emacs/site-lisp/haskell-mode/haskell-simple-indent hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-simple-indent
/usr/share/emacs/site-lisp/haskell-mode/inf-haskell hides /usr/share/emacs/23.2/site-lisp/haskell-mode/inf-haskell
/usr/share/emacs/site-lisp/haskell-mode/haskell-indentation hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-indentation
/usr/share/emacs/site-lisp/haskell-mode/haskell-mode hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-mode
/usr/share/emacs/site-lisp/haskell-mode/haskell-indent hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-indent
/usr/share/emacs/site-lisp/haskell-mode/haskell-hugs hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-hugs
/usr/share/emacs/site-lisp/haskell-mode/haskell-font-lock hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-font-lock
/usr/share/emacs/site-lisp/haskell-mode/haskell-decl-scan hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-decl-scan
/usr/share/emacs/site-lisp/haskell-mode/haskell-ghci hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-ghci
/usr/share/emacs/site-lisp/haskell-mode/haskell-cabal hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-cabal
/usr/share/emacs/site-lisp/haskell-mode/haskell-c hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-c
/usr/share/emacs/site-lisp/haskell-mode/haskell-doc hides /usr/share/emacs/23.2/site-lisp/haskell-mode/haskell-doc
/usr/share/emacs/23.2/site-lisp/magit hides /usr/share/emacs/site-lisp/magit
~/.emacs.d/ipython hides /usr/share/emacs/site-lisp/ipython
/usr/share/emacs/23.2/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs23/site-lisp/semi/pgg-pgp5 hides /usr/share/emacs/23.2/lisp/pgg-pgp5
/usr/share/emacs23/site-lisp/flim/hex-util hides /usr/share/emacs/23.2/lisp/hex-util
/usr/share/emacs23/site-lisp/semi/pgg-parse hides /usr/share/emacs/23.2/lisp/pgg-parse
~/.emacs.d/savehist hides /usr/share/emacs/23.2/lisp/savehist
/usr/share/emacs23/site-lisp/semi/pgg hides /usr/share/emacs/23.2/lisp/pgg
/usr/share/emacs23/site-lisp/flim/md4 hides /usr/share/emacs/23.2/lisp/md4
/usr/share/emacs23/site-lisp/semi/pgg-pgp hides /usr/share/emacs/23.2/lisp/pgg-pgp
/usr/share/emacs23/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/23.2/lisp/tempo
/usr/share/emacs23/site-lisp/semi/pgg-gpg hides /usr/share/emacs/23.2/lisp/pgg-gpg
/usr/share/emacs23/site-lisp/semi/pgg-def hides /usr/share/emacs/23.2/lisp/pgg-def
/usr/share/emacs23/site-lisp/flim/sha1 hides /usr/share/emacs/23.2/lisp/sha1
/usr/share/emacs23/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/23.2/lisp/textmodes/flyspell
/usr/share/emacs23/site-lisp/css-mode/css-mode hides /usr/share/emacs/23.2/lisp/textmodes/css-mode
/usr/share/emacs23/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/23.2/lisp/textmodes/ispell
/usr/share/emacs/23.2/site-lisp/octave3.2-emacsen/octave-mod hides /usr/share/emacs/23.2/lisp/progmodes/octave-mod
/usr/share/emacs/23.2/site-lisp/octave3.2-emacsen/octave-inf hides /usr/share/emacs/23.2/lisp/progmodes/octave-inf
/usr/share/emacs23/site-lisp/org-mode/org-archive hides /usr/share/emacs/23.2/lisp/org/org-archive
/usr/share/emacs23/site-lisp/org-mode/org-clock hides /usr/share/emacs/23.2/lisp/org/org-clock
/usr/share/emacs23/site-lisp/org-mode/org-jsinfo hides /usr/share/emacs/23.2/lisp/org/org-jsinfo
/usr/share/emacs23/site-lisp/org-mode/org-vm hides /usr/share/emacs/23.2/lisp/org/org-vm
/usr/share/emacs23/site-lisp/org-mode/org-feed hides /usr/share/emacs/23.2/lisp/org/org-feed
/usr/share/emacs23/site-lisp/org-mode/org-publish hides /usr/share/emacs/23.2/lisp/org/org-publish
/usr/share/emacs23/site-lisp/org-mode/org-xoxo hides /usr/share/emacs/23.2/lisp/org/org-xoxo
/usr/share/emacs23/site-lisp/org-mode/org-protocol hides /usr/share/emacs/23.2/lisp/org/org-protocol
/usr/share/emacs23/site-lisp/org-mode/org-bbdb hides /usr/share/emacs/23.2/lisp/org/org-bbdb
/usr/share/emacs23/site-lisp/org-mode/org-timer hides /usr/share/emacs/23.2/lisp/org/org-timer
/usr/share/emacs23/site-lisp/org-mode/org-gnus hides /usr/share/emacs/23.2/lisp/org/org-gnus
/usr/share/emacs23/site-lisp/org-mode/org-bibtex hides /usr/share/emacs/23.2/lisp/org/org-bibtex
/usr/share/emacs23/site-lisp/org-mode/org-remember hides /usr/share/emacs/23.2/lisp/org/org-remember
/usr/share/emacs23/site-lisp/org-mode/org-html hides /usr/share/emacs/23.2/lisp/org/org-html
/usr/share/emacs23/site-lisp/org-mode/org-indent hides /usr/share/emacs/23.2/lisp/org/org-indent
/usr/share/emacs23/site-lisp/org-mode/org-habit hides /usr/share/emacs/23.2/lisp/org/org-habit
/usr/share/emacs23/site-lisp/org-mode/org-exp-blocks hides /usr/share/emacs/23.2/lisp/org/org-exp-blocks
/usr/share/emacs23/site-lisp/org-mode/org-install hides /usr/share/emacs/23.2/lisp/org/org-install
/usr/share/emacs23/site-lisp/org-mode/org-mew hides /usr/share/emacs/23.2/lisp/org/org-mew
/usr/share/emacs23/site-lisp/org-mode/org-mouse hides /usr/share/emacs/23.2/lisp/org/org-mouse
/usr/share/emacs23/site-lisp/org-mode/org-mobile hides /usr/share/emacs/23.2/lisp/org/org-mobile
/usr/share/emacs23/site-lisp/org-mode/org-agenda hides /usr/share/emacs/23.2/lisp/org/org-agenda
/usr/share/emacs23/site-lisp/org-mode/org-ascii hides /usr/share/emacs/23.2/lisp/org/org-ascii
/usr/share/emacs23/site-lisp/org-mode/org-freemind hides /usr/share/emacs/23.2/lisp/org/org-freemind
/usr/share/emacs23/site-lisp/org-mode/org-info hides /usr/share/emacs/23.2/lisp/org/org-info
/usr/share/emacs23/site-lisp/org-mode/org-inlinetask hides /usr/share/emacs/23.2/lisp/org/org-inlinetask
/usr/share/emacs23/site-lisp/org-mode/org-latex hides /usr/share/emacs/23.2/lisp/org/org-latex
/usr/share/emacs23/site-lisp/org-mode/org-datetree hides /usr/share/emacs/23.2/lisp/org/org-datetree
/usr/share/emacs23/site-lisp/org-mode/org-attach hides /usr/share/emacs/23.2/lisp/org/org-attach
/usr/share/emacs23/site-lisp/org-mode/org-crypt hides /usr/share/emacs/23.2/lisp/org/org-crypt
/usr/share/emacs23/site-lisp/org-mode/org-macs hides /usr/share/emacs/23.2/lisp/org/org-macs
/usr/share/emacs23/site-lisp/org-mode/org-mhe hides /usr/share/emacs/23.2/lisp/org/org-mhe
/usr/share/emacs23/site-lisp/org-mode/org hides /usr/share/emacs/23.2/lisp/org/org
/usr/share/emacs23/site-lisp/org-mode/org-docbook hides /usr/share/emacs/23.2/lisp/org/org-docbook
/usr/share/emacs23/site-lisp/org-mode/org-colview hides /usr/share/emacs/23.2/lisp/org/org-colview
/usr/share/emacs23/site-lisp/org-mode/org-exp hides /usr/share/emacs/23.2/lisp/org/org-exp
/usr/share/emacs23/site-lisp/org-mode/org-icalendar hides /usr/share/emacs/23.2/lisp/org/org-icalendar
/usr/share/emacs23/site-lisp/org-mode/org-rmail hides /usr/share/emacs/23.2/lisp/org/org-rmail
/usr/share/emacs23/site-lisp/org-mode/org-footnote hides /usr/share/emacs/23.2/lisp/org/org-footnote
/usr/share/emacs23/site-lisp/org-mode/org-list hides /usr/share/emacs/23.2/lisp/org/org-list
/usr/share/emacs23/site-lisp/org-mode/org-plot hides /usr/share/emacs/23.2/lisp/org/org-plot
/usr/share/emacs23/site-lisp/org-mode/org-id hides /usr/share/emacs/23.2/lisp/org/org-id
/usr/share/emacs23/site-lisp/org-mode/org-src hides /usr/share/emacs/23.2/lisp/org/org-src
/usr/share/emacs23/site-lisp/org-mode/org-irc hides /usr/share/emacs/23.2/lisp/org/org-irc
/usr/share/emacs23/site-lisp/org-mode/org-compat hides /usr/share/emacs/23.2/lisp/org/org-compat
/usr/share/emacs23/site-lisp/org-mode/org-faces hides /usr/share/emacs/23.2/lisp/org/org-faces
/usr/share/emacs23/site-lisp/org-mode/org-mac-message hides /usr/share/emacs/23.2/lisp/org/org-mac-message
/usr/share/emacs23/site-lisp/org-mode/org-wl hides /usr/share/emacs/23.2/lisp/org/org-wl
/usr/share/emacs23/site-lisp/org-mode/org-table hides /usr/share/emacs/23.2/lisp/org/org-table
/usr/share/emacs23/site-lisp/org-mode/org-w3m hides /usr/share/emacs/23.2/lisp/org/org-w3m
/usr/share/emacs23/site-lisp/flim/ntlm hides /usr/share/emacs/23.2/lisp/net/ntlm
/usr/share/emacs23/site-lisp/flim/sasl hides /usr/share/emacs/23.2/lisp/net/sasl
/usr/share/emacs23/site-lisp/flim/sasl-cram hides /usr/share/emacs/23.2/lisp/net/sasl-cram
/usr/share/emacs23/site-lisp/flim/sasl-digest hides /usr/share/emacs/23.2/lisp/net/sasl-digest
/usr/share/emacs23/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/23.2/lisp/net/sasl-ntlm
/usr/share/emacs23/site-lisp/flim/hmac-def hides /usr/share/emacs/23.2/lisp/net/hmac-def
/usr/share/emacs23/site-lisp/flim/hmac-md5 hides /usr/share/emacs/23.2/lisp/net/hmac-md5
/usr/share/emacs23/site-lisp/wl/rfc2368 hides /usr/share/emacs/23.2/lisp/mail/rfc2368

Features:
(shadow sort mail-extr message sendmail ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
mailabbrev nnheader gnus-util netrc gmm-utils wid-edit mailheader
canlock sha1 sha1-el hex-util hashcash mail-utils emacsbug reftex-sel
bibtex reftex-ref css-mode apropos dired js json thingatpt etags vc
vc-dispatcher js2-mode js2-indent js2-parse js2-browse js2-highlight
js2-ast js2-messages js2-scan js2-util js2-vars cc-langs js2-externs
nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc
rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok
filecache tabify man assoc rect cperl-mode markdown-mode skeleton debug
perl-mode grep cc-mode cc-fonts cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs python-mode info-look info ansi-color cl cl-19
sh-script executable debian-control-mode imenu debian-bug rfc2047
rfc2045 ietf-drums time-date qp mm-util mail-prsvr debian-changelog-mode
add-log help-mode view make-mode multi-isearch compile comint ring
newcomment reftex-cite reftex-parse texmathp vc-git preview prv-emacs
byte-opt tex-buf reftex-vcr reftex-dcr reftex-auc reftex reftex-vars
flyspell ispell noutline outline font-latex bytecomp byte-compile latex
tex-style tex easymenu regexp-opt latexenc server uniquify shebang
iswitchb edmacro kmacro debian-el debian-el-loaddefs w3m-load
org-install emacs-goodies-el emacs-goodies-custom emacs-goodies-loaddefs
easy-mmode dpkg-dev-el dpkg-dev-el-loaddefs develock advice help-fns
advice-preload bbdb-autoloads preview-latex tex-site auto-loads tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag 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 loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind system-font-setting
font-render-setting gtk x-toolkit x multi-tty emacs)





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: 23.2; call-process should be able to send stderr to buffer object
  2011-01-14  2:56 ` bug#7842: 23.2; call-process should be able to send stderr to buffer object Jameson Rollins
@ 2011-01-14  3:56   ` Glenn Morris
       [not found]   ` <handler.7842.C.136026813810926.notifdonectrl.0@debbugs.gnu.org>
  1 sibling, 0 replies; 18+ messages in thread
From: Glenn Morris @ 2011-01-14  3:56 UTC (permalink / raw)
  To: Jameson Rollins; +Cc: 7842

Jameson Rollins wrote:

> Currently the call-process function lets one send stderr to a file by
> providing a list as the BUFFER argument which includes the name of a
> STDERR-FILE:
>
> (call-process "ls" nil (list t "/path/to/stderr/file") nil "/does-not-exist")
>
> It would be nice if one could instead send stderr directly to a distinct
> buffer, i.e.:

Quoth the elisp manual:

   "Creating a Synchronous Process"

    You can't directly specify a buffer to put the error output
    in; that is too difficult to implement.  But you can achieve
    this result by sending the error output to a temporary file
    and then inserting the file into a buffer.





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
       [not found]   ` <handler.7842.C.136026813810926.notifdonectrl.0@debbugs.gnu.org>
@ 2013-02-07 22:38     ` Jameson Graef Rollins
  2013-02-07 22:41       ` Glenn Morris
  0 siblings, 1 reply; 18+ messages in thread
From: Jameson Graef Rollins @ 2013-02-07 22:38 UTC (permalink / raw)
  To: 7842

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

On Thu, Feb 07 2013, GNU bug Tracking System <help-debbugs@gnu.org> wrote:
> This is an automatic notification regarding your bug report
> #7842: 23.2; call-process should be able to send stderr to buffer object,
> which was filed against the emacs package.
>
> Thank you for your report, which has now been closed.
> You can view the full report at
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7842

Hi.  Can you please explain why this is being closed "won't fix"?  Is
there good reason for that?

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-07 22:38     ` bug#7842: acknowledged by developer (control message for bug 7842) Jameson Graef Rollins
@ 2013-02-07 22:41       ` Glenn Morris
  2013-02-07 22:47         ` Jameson Graef Rollins
  0 siblings, 1 reply; 18+ messages in thread
From: Glenn Morris @ 2013-02-07 22:41 UTC (permalink / raw)
  To: Jameson Graef Rollins; +Cc: 7842

Jameson Graef Rollins wrote:

> Hi.  Can you please explain why this is being closed "won't fix"?  Is
> there good reason for that?

For the documented reason I gave in

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7842#8

There are very few things that the Elisp manual explicitly says are too
difficult to implement. 






^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-07 22:41       ` Glenn Morris
@ 2013-02-07 22:47         ` Jameson Graef Rollins
  2013-02-08  8:40           ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: Jameson Graef Rollins @ 2013-02-07 22:47 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 7842

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

On Thu, Feb 07 2013, Glenn Morris <rgm@gnu.org> wrote:
> Jameson Graef Rollins wrote:
>
>> Hi.  Can you please explain why this is being closed "won't fix"?  Is
>> there good reason for that?
>
> For the documented reason I gave in
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7842#8
>
> There are very few things that the Elisp manual explicitly says are too
> difficult to implement. 

Yes, but that requires writing to a temporary file.  Avoiding that was
the entire point of my feature request.  Is there some technical reason
that it's impossible to just capture the stderr to a separate buffer?

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-07 22:47         ` Jameson Graef Rollins
@ 2013-02-08  8:40           ` Eli Zaretskii
  2013-02-13 18:51             ` Jameson Graef Rollins
  0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2013-02-08  8:40 UTC (permalink / raw)
  To: Jameson Graef Rollins; +Cc: 7842

> From: Jameson Graef Rollins <jrollins@finestructure.net>
> Date: Thu, 07 Feb 2013 14:47:40 -0800
> Cc: 7842@debbugs.gnu.org
> 
> Yes, but that requires writing to a temporary file.  Avoiding that was
> the entire point of my feature request.

Why do you want to avoid it?  What is the problem with using this
method?

> Is there some technical reason that it's impossible to just capture
> the stderr to a separate buffer?

It's possible, but it will complicate the API which is already quite
complicated and hard to maintain for every platform Emacs supports.





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-08  8:40           ` Eli Zaretskii
@ 2013-02-13 18:51             ` Jameson Graef Rollins
  2013-02-13 21:50               ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: Jameson Graef Rollins @ 2013-02-13 18:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7842

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

On Fri, Feb 08 2013, Eli Zaretskii <eliz@gnu.org> wrote:
>> Yes, but that requires writing to a temporary file.  Avoiding that was
>> the entire point of my feature request.
>
> Why do you want to avoid it?  What is the problem with using this
> method?

For the exact same reasons you don't just send stdout to a temporary
file.  It is exactly the same issue.  Pretty much the whole point of
call-process is that it captures stdout to a buffer.  But somehow the
logic that applies to stdout does not apply to stderr?  That makes no
sense.  If we feel it's important that users be able to capture stdout
into a buffer, then we should be able to capture stderr into a buffer
for exactly the same reasons.

>> Is there some technical reason that it's impossible to just capture
>> the stderr to a separate buffer?
>
> It's possible, but it will complicate the API which is already quite
> complicated and hard to maintain for every platform Emacs supports.

This also seems like a really bad justification for closing this as
"won't fix".  It may be difficult, but it's still a legitimate feature
request.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-13 18:51             ` Jameson Graef Rollins
@ 2013-02-13 21:50               ` Eli Zaretskii
  2013-02-22  1:50                 ` Jameson Graef Rollins
  0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2013-02-13 21:50 UTC (permalink / raw)
  To: Jameson Graef Rollins; +Cc: 7842

> From: Jameson Graef Rollins <jrollins@finestructure.net>
> Cc: rgm@gnu.org, 7842@debbugs.gnu.org
> Date: Wed, 13 Feb 2013 10:51:41 -0800
> 
> > Why do you want to avoid it?  What is the problem with using this
> > method?
> 
> For the exact same reasons you don't just send stdout to a temporary
> file.  It is exactly the same issue.  Pretty much the whole point of
> call-process is that it captures stdout to a buffer.  But somehow the
> logic that applies to stdout does not apply to stderr?  That makes no
> sense.  If we feel it's important that users be able to capture stdout
> into a buffer, then we should be able to capture stderr into a buffer
> for exactly the same reasons.

You _can_ capture stderr in a buffer, if you insert the file into a
buffer.  Why is it important how the stuff got into a buffer?

> >> Is there some technical reason that it's impossible to just capture
> >> the stderr to a separate buffer?
> >
> > It's possible, but it will complicate the API which is already quite
> > complicated and hard to maintain for every platform Emacs supports.
> 
> This also seems like a really bad justification for closing this as
> "won't fix".  It may be difficult, but it's still a legitimate feature
> request.

I didn't close it, but I can understand why it was closed: the reason
for the feature is not important enough, as there's already a simple
way of getting what you want.





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-13 21:50               ` Eli Zaretskii
@ 2013-02-22  1:50                 ` Jameson Graef Rollins
  2013-02-22  8:46                   ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: Jameson Graef Rollins @ 2013-02-22  1:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7842

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

On Wed, Feb 13 2013, Eli Zaretskii <eliz@gnu.org> wrote:
> You _can_ capture stderr in a buffer, if you insert the file into a
> buffer.  Why is it important how the stuff got into a buffer?

I am really confused why you guys keep responding with points like this.
I've responded to this exact point twice now and you guys keep coming
back with the same completely illogical and unthought-through dismissal.
Do I really have to explain why redirecting to a file is not the same
thing as a pipe?  I would have assumed that emacs developers would be
familiar with pipes.  And the entire point of the command in question
(call-process) is to capture stdout to a buffer, so at least the
original author understood.  So maybe it's somehow hard to understand
that the same considerations for stdout would apply to stderr?  Somehow
I doubt that as well.  Something else is going on.

But just in case you *really* don't understand what I'm talking about,
let me try a simple example that might help you understand.  Are these
two commands equivalent?:

$ ps > tempfile; grep bash tempfile; rm tempfile
$ ps | grep bash

No, obviously they're not:

* The first touches the disk, the second does not.

* The first requires me to pick a temporary file name that does not
  collide with an existing file on disk, the second does not.

* The first requires me to cleanup a temporary file, the second does
  not.

* The first is 45 characters long, the second is 13.

This is first year programmer stuff.

I think what's really going on here is that you're trying to dismiss
this request because it's hard to implement and you for some reason feel
you need to close out wishlist reports (why?).  I guess I'm willing to
accept that.  But please don't keep feeding me bullshit.  It's childish.
Just be an adult and explain what the issue is without trying to blow
smoke up my ass.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-22  1:50                 ` Jameson Graef Rollins
@ 2013-02-22  8:46                   ` Eli Zaretskii
  2013-02-22 14:17                     ` Stefan Monnier
  2013-02-22 17:04                     ` Jameson Graef Rollins
  0 siblings, 2 replies; 18+ messages in thread
From: Eli Zaretskii @ 2013-02-22  8:46 UTC (permalink / raw)
  To: Jameson Graef Rollins; +Cc: 7842

> From: Jameson Graef Rollins <jrollins@finestructure.net>
> Cc: rgm@gnu.org, 7842@debbugs.gnu.org
> Date: Thu, 21 Feb 2013 17:50:34 -0800
> 
> But just in case you *really* don't understand what I'm talking about,
> let me try a simple example that might help you understand.  Are these
> two commands equivalent?:
> 
> $ ps > tempfile; grep bash tempfile; rm tempfile
> $ ps | grep bash
> 
> No, obviously they're not:
> 
> * The first touches the disk, the second does not.
> 
> * The first requires me to pick a temporary file name that does not
>   collide with an existing file on disk, the second does not.
> 
> * The first requires me to cleanup a temporary file, the second does
>   not.

Emacs already does all that in a number of commands, such as
call-process-region.  How is this situation different?

> This is first year programmer stuff.

That was a nasty thing to say.  It is uncalled for, because none of
the responses so far was either ad-hominem or disrespectful.

> I think what's really going on here is that you're trying to dismiss
> this request because it's hard to implement and you for some reason feel
> you need to close out wishlist reports (why?).  I guess I'm willing to
> accept that.  But please don't keep feeding me bullshit.  It's childish.
> Just be an adult and explain what the issue is without trying to blow
> smoke up my ass.

Please drop the attitude and the profanities, or you won't hear from
me anymore.

The real reason is explained in the ELisp manual:

     It is impossible to separate the standard output and standard error
  streams of the subprocess, because Emacs normally spawns the subprocess
  inside a pseudo-TTY, and a pseudo-TTY has only one output channel.  If
  you want to keep the output to those streams separate, you should
  redirect one of them to a file--for example, by using an appropriate
  shell command.





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-22  8:46                   ` Eli Zaretskii
@ 2013-02-22 14:17                     ` Stefan Monnier
  2013-02-22 14:55                       ` Eli Zaretskii
  2013-02-22 17:08                       ` Jameson Graef Rollins
  2013-02-22 17:04                     ` Jameson Graef Rollins
  1 sibling, 2 replies; 18+ messages in thread
From: Stefan Monnier @ 2013-02-22 14:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7842, Jameson Graef Rollins

>      It is impossible to separate the standard output and standard error
>   streams of the subprocess, because Emacs normally spawns the subprocess
>   inside a pseudo-TTY, and a pseudo-TTY has only one output channel.

Eli, you're confusing things.  We're talking about call-process here,
which uses no tty and already separates stdout from stderr.

There's nothing unreasonable in requesting the ability to put
call-process's stderr output inside a buffer.  We could easily do that
with a simple Elisp wrapper (which uses a make-temp-file internally).
I don't know how hard it would be to do it right, OTOH, but I think it
would be good to do it.


        Stefan





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-22 14:17                     ` Stefan Monnier
@ 2013-02-22 14:55                       ` Eli Zaretskii
  2013-02-22 17:25                         ` Stefan Monnier
  2013-02-22 17:08                       ` Jameson Graef Rollins
  1 sibling, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2013-02-22 14:55 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 7842, jrollins

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Jameson Graef Rollins <jrollins@finestructure.net>,  7842@debbugs.gnu.org
> Date: Fri, 22 Feb 2013 09:17:49 -0500
> 
> >      It is impossible to separate the standard output and standard error
> >   streams of the subprocess, because Emacs normally spawns the subprocess
> >   inside a pseudo-TTY, and a pseudo-TTY has only one output channel.
> 
> Eli, you're confusing things.  We're talking about call-process here,
> which uses no tty

It doesn't?  I see a call to 'pipe' on all systems but MSDOS.  But
hey, what do I understand, right?

> and already separates stdout from stderr.

stderr is put on a file when separated.

> There's nothing unreasonable in requesting the ability to put
> call-process's stderr output inside a buffer.  We could easily do that
> with a simple Elisp wrapper (which uses a make-temp-file internally).

The OP seems to object to a solution that would use files, or else he
would have used make-temp-file himself.





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-22  8:46                   ` Eli Zaretskii
  2013-02-22 14:17                     ` Stefan Monnier
@ 2013-02-22 17:04                     ` Jameson Graef Rollins
  2013-02-22 18:23                       ` Eli Zaretskii
  1 sibling, 1 reply; 18+ messages in thread
From: Jameson Graef Rollins @ 2013-02-22 17:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7842

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

On Fri, Feb 22 2013, Eli Zaretskii <eliz@gnu.org> wrote:
>> This is first year programmer stuff.
>
> That was a nasty thing to say.  It is uncalled for, because none of
> the responses so far was either ad-hominem or disrespectful.

Eli, I'm sorry I got frustrated, but really, your responses have been
dismissive and unthoughtful.  Instead of explaining or discussing the
technical issues, you keep questioning why I would want to do this.
I've explained three times now, very clearly.  Please don't ask why I
would care about doing this again.

> The real reason is explained in the ELisp manual:
>
>      It is impossible to separate the standard output and standard error
>   streams of the subprocess, because Emacs normally spawns the subprocess
>   inside a pseudo-TTY, and a pseudo-TTY has only one output channel.  If
>   you want to keep the output to those streams separate, you should
>   redirect one of them to a file--for example, by using an appropriate
>   shell command.

I don't believe this at all.  Obviously the command can separate stdout
From stderr or it wouldn't be able to capture stdout to a buffer and
separately redirect stderr to a file.

Come on, guys.  Let's have a serious discussion here.  No more smoke
blowing.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-22 14:17                     ` Stefan Monnier
  2013-02-22 14:55                       ` Eli Zaretskii
@ 2013-02-22 17:08                       ` Jameson Graef Rollins
  1 sibling, 0 replies; 18+ messages in thread
From: Jameson Graef Rollins @ 2013-02-22 17:08 UTC (permalink / raw)
  To: Stefan Monnier, Eli Zaretskii; +Cc: 7842

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

On Fri, Feb 22 2013, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>      It is impossible to separate the standard output and standard error
>>   streams of the subprocess, because Emacs normally spawns the subprocess
>>   inside a pseudo-TTY, and a pseudo-TTY has only one output channel.
>
> Eli, you're confusing things.  We're talking about call-process here,
> which uses no tty and already separates stdout from stderr.
>
> There's nothing unreasonable in requesting the ability to put
> call-process's stderr output inside a buffer.  We could easily do that
> with a simple Elisp wrapper (which uses a make-temp-file internally).
> I don't know how hard it would be to do it right, OTOH, but I think it
> would be good to do it.

Thanks so much for the clarification and response, Stefan.  I would like
to have a real discussion of the technical issues.

If we can also at the very least remove the "wontfix" tag, so that we
have a clear record of the request, I would be very grateful.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-22 14:55                       ` Eli Zaretskii
@ 2013-02-22 17:25                         ` Stefan Monnier
  2013-02-22 18:21                           ` Eli Zaretskii
  2013-02-22 18:44                           ` Jameson Graef Rollins
  0 siblings, 2 replies; 18+ messages in thread
From: Stefan Monnier @ 2013-02-22 17:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 7842, jrollins

>> and already separates stdout from stderr.
> stderr is put on a file when separated.

Still, it disproves the statement that "It is impossible to separate the
standard output and standard error streams of the subprocess".

>> There's nothing unreasonable in requesting the ability to put
>> call-process's stderr output inside a buffer.  We could easily do that
>> with a simple Elisp wrapper (which uses a make-temp-file internally).
> The OP seems to object to a solution that would use files, or else he
> would have used make-temp-file himself.

He mentions 4 problems with the current situation:

> * The first touches the disk, the second does not.

Providing a wrapper that does make-temp-file doesn't solve this point,
indeed.

> * The first requires me to pick a temporary file name that does not
>   collide with an existing file on disk, the second does not.
> * The first requires me to cleanup a temporary file, the second does
>   not.
> * The first is 45 characters long, the second is 13.

But the wrapper would solve all those 3 remaining points (because the
wrapper would pay this cost, not Jameson).


        Stefan





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-22 17:25                         ` Stefan Monnier
@ 2013-02-22 18:21                           ` Eli Zaretskii
  2013-02-22 18:44                           ` Jameson Graef Rollins
  1 sibling, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2013-02-22 18:21 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 7842, jrollins

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jrollins@finestructure.net,  7842@debbugs.gnu.org
> Date: Fri, 22 Feb 2013 12:25:22 -0500
> 
> >> and already separates stdout from stderr.
> > stderr is put on a file when separated.
> 
> Still, it disproves the statement that "It is impossible to separate the
> standard output and standard error streams of the subprocess".

The statement is that it is impossible to do that without involving
files.

> > The OP seems to object to a solution that would use files, or else he
> > would have used make-temp-file himself.
> 
> He mentions 4 problems with the current situation:
> 
> > * The first touches the disk, the second does not.
> 
> Providing a wrapper that does make-temp-file doesn't solve this point,
> indeed.
> 
> > * The first requires me to pick a temporary file name that does not
> >   collide with an existing file on disk, the second does not.
> > * The first requires me to cleanup a temporary file, the second does
> >   not.
> > * The first is 45 characters long, the second is 13.
> 
> But the wrapper would solve all those 3 remaining points (because the
> wrapper would pay this cost, not Jameson).

Again, the example in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7842#33 explicitly
rejects use of any temporary files altogether.

If the Jameson would like to rephrase his position, I'm all ears.





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-22 17:04                     ` Jameson Graef Rollins
@ 2013-02-22 18:23                       ` Eli Zaretskii
  0 siblings, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2013-02-22 18:23 UTC (permalink / raw)
  To: Jameson Graef Rollins; +Cc: 7842

> From: Jameson Graef Rollins <jrollins@finestructure.net>
> Cc: rgm@gnu.org, 7842@debbugs.gnu.org
> Date: Fri, 22 Feb 2013 09:04:23 -0800
> 
> >      It is impossible to separate the standard output and standard error
> >   streams of the subprocess, because Emacs normally spawns the subprocess
> >   inside a pseudo-TTY, and a pseudo-TTY has only one output channel.  If
> >   you want to keep the output to those streams separate, you should
> >   redirect one of them to a file--for example, by using an appropriate
> >   shell command.
> 
> I don't believe this at all.

Which part?

> Obviously the command can separate stdout From stderr or it wouldn't
> be able to capture stdout to a buffer and separately redirect stderr
> to a file.

The text above says that it is impossible to separate them without
going through files.  In a pipe, there's only one channel, so you can
either have stderr redirected to the same place as stdout (in which
case they are not separated), or put one of them on a file.  And you
clearly said you don;t want any files.

> Come on, guys.  Let's have a serious discussion here.  No more smoke
> blowing.

I don't know whether anybody is blowing smoke here, but I'm certainly
not doing that.





^ permalink raw reply	[flat|nested] 18+ messages in thread

* bug#7842: acknowledged by developer (control message for bug 7842)
  2013-02-22 17:25                         ` Stefan Monnier
  2013-02-22 18:21                           ` Eli Zaretskii
@ 2013-02-22 18:44                           ` Jameson Graef Rollins
  1 sibling, 0 replies; 18+ messages in thread
From: Jameson Graef Rollins @ 2013-02-22 18:44 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 7842

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

On Fri, Feb 22 2013, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> He mentions 4 problems with the current situation:
>
>> * The first touches the disk, the second does not.
>
> Providing a wrapper that does make-temp-file doesn't solve this point,
> indeed.
>
>> * The first requires me to pick a temporary file name that does not
>>   collide with an existing file on disk, the second does not.
>> * The first requires me to cleanup a temporary file, the second does
>>   not.
>> * The first is 45 characters long, the second is 13.
>
> But the wrapper would solve all those 3 remaining points (because the
> wrapper would pay this cost, not Jameson).

Thanks again, Stefan.  This is a good analysis of the situation.
Solving these latter three issues is really the crux of things from my
perspective.  The main problem is all the book keeping and extra coding
that is currently required to get stderr into a separate buffer.  It
would obviously better if we didn't have to resort to temporary files,
but if that's the only way to get these last three issues covered then
I'm completely fine with it.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2013-02-22 18:44 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <E1U3Xsb-00055Y-Le@fencepost.gnu.org>
2011-01-14  2:56 ` bug#7842: 23.2; call-process should be able to send stderr to buffer object Jameson Rollins
2011-01-14  3:56   ` Glenn Morris
     [not found]   ` <handler.7842.C.136026813810926.notifdonectrl.0@debbugs.gnu.org>
2013-02-07 22:38     ` bug#7842: acknowledged by developer (control message for bug 7842) Jameson Graef Rollins
2013-02-07 22:41       ` Glenn Morris
2013-02-07 22:47         ` Jameson Graef Rollins
2013-02-08  8:40           ` Eli Zaretskii
2013-02-13 18:51             ` Jameson Graef Rollins
2013-02-13 21:50               ` Eli Zaretskii
2013-02-22  1:50                 ` Jameson Graef Rollins
2013-02-22  8:46                   ` Eli Zaretskii
2013-02-22 14:17                     ` Stefan Monnier
2013-02-22 14:55                       ` Eli Zaretskii
2013-02-22 17:25                         ` Stefan Monnier
2013-02-22 18:21                           ` Eli Zaretskii
2013-02-22 18:44                           ` Jameson Graef Rollins
2013-02-22 17:08                       ` Jameson Graef Rollins
2013-02-22 17:04                     ` Jameson Graef Rollins
2013-02-22 18:23                       ` Eli Zaretskii

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).