* 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
[parent not found: <handler.7842.C.136026813810926.notifdonectrl.0@debbugs.gnu.org>]
* 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 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: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
* 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 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 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
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).