Creating a new buffer with text using EmacsClient

I have a program that can send text to any other program for further analysis (eg sed, grep, etc). I woul开发者_运维问答d like it to send the data to Emacs and do analysis there. How would I do that? EmacsClient takes a filename by default, this is a data string not a file and I really don't want to create and delete files just to send data to Emacs.

EmacsClient has an "eval" command-line option that let's you execute lisp code instead of open files. Is there a simple lisp function that will open a new buffer with the given text?

Edit: I'm looking for something like:

emacsclientw.exe -eval (open-new-buffer 'hello world')

And a new buffer would automatically appear with the word "hello world". I'm not sure how the name of the buffer would be set. Hopefully something auto-numbered.

---

This does what you ask for:

emacsclient -e '(open-buffer-with "some\nstuff\nhere")'

(defun open-buffer-with (txt)
  "create a new buffer, insert txt"
  (pop-to-buffer (get-buffer-create (generate-new-buffer-name "something")))
  (insert txt))

Obviously you can customize open-buffer-with to do what you want.

There's a similar question you might want to look at: How do I get basic App<->Emacs integration?.

---

How about this approach?

emacsclient -e '
  (progn
    (pop-to-buffer (generate-new-buffer "Piped")) 
    (insert (decode-hex-string "
    '$(perl -e 'print unpack "H*", qq("Hello, World!")'
    )'")))
'

I've inserted newlines to break up this very long line for display purposes.

When I run this from a terminal window, a new buffer named Piped opens in my Emacs window, containing the text "Hello, World!" (complete with quotes). When I run it again, another buffer named Piped<2> opens, with the same text.

The hex-escaping (which can probably be just as easily accomplished with any other high-level language, not just Perl) is for escaping quotes that would otherwise terminate the string constant being fed to (insert).

This approach feeds text to Emacs via Emacsclient on the command line, so very long input text might give it a problem. A more general solution might be able to break up long input data and feed it to Emacs across several Emacsclient invocations.