This is a job for emacsclient. You might start with something like this:
use Data::Dumper;
sub emed {
eval eval `emacsclient -e '
(with-temp-buffer
(insert "@{[quotemeta Dumper $_[0]]}")
(pop-to-buffer (current-buffer))
(recursive-edit)
(buffer-substring-no-properties (point-min) (point-max)))'`
}
Use M-: (throw 'exit nil) to leave Emacs. | [reply]
[d/l]
[select] |
I think you want "double piping" (not sure this term is correct), writing to and reading from the same program. One sceario is put the data on temporary file (which doesn't meet your reqs) and feed it the editor. You read the temporary file back after the editor finish its job. And you might want to delete the file as well at the end of your program. I do this with vim to build some semi-automatic cvs commit on many files at once with separate log changes for each file. Although vim is capable of reading from STDIN (no prior filename), I haven't incorporated this.
Another scenario requires that the editor is able to spit out the content it edits so the program can read the editor's output back to its data. I haven't done this before so instead of giving you example I refer you to IPC::Open2 and IPC::Open3 modules. They come with the Perl standard distribution.
Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!
| [reply] |
You probably could, but why the requirement to avoid a temporary file? It feels as if you may be doing some premature optimization. The operating system won't necessarily have to do any physical I/O, as the file would likely reside in RAM for the relatively short duration that it exists. If you're truly concerned about disk I/O, many operating systems provide RAM-based filesystems on which you could place your temp file.
If it's a security concern (i.e., you don't want a temporary file that *might* get written to disk), then you may have to audit emacs as well, as it may use temporary files during the edit process...and we won't even talk about the swap space....
...roboticus | [reply] |
| [reply] |
Are there things you critically need that are available in emacs, but that you would not get from using a Tk::Text widget for editing? Writing a PerlTk app to support editing a text buffer is pretty easy, and the text-editor widget does just about everything a normal user would want to do when editing text.
You can even enhance it to whatever extent you want, by adding extra type-in windows, menus, buttons and whatever the application might need.
The best thing about it for your requirements is that the data being edited never needs to go outside your perl process.
Meanwhile, trying to use emacs this way seems like a non-starter relatively more complicated and difficult. Emacs needs to open a data file, and load it into a buffer, in order to edit text data. If you have figured out a way to have emacs run as an interactive process using stdin and stdout (not a disk file) as the source and destination of text data for an editing buffer, I'd be curious to hear how you do that, because I've never seen it done (in over 15 years of using emacs).
update: Having just seen educated_foo's reply, that looks like a good approach, assuming there really are things in emacs that make it especially good for the task at hand. One thing that wasn't mentioned there (in case you're not familiar with emacsclient) is that you need a separate instance of emacs already running, and that instance needs to execute the "server-start" elisp command. It will then sit idle until an emacsclient process runs to give it something to do. | [reply] |
If I understand what you're asking for here, I think you need to look at Emacs::EPL: emacs-perl integration via inter-process communication.
I was just writing up some notes on installing it today over at the emacswiki.
Summary: Don't try to install it with CPANPLUS, don't expect "make test" to work, and *do* read the README file.
epl.info in html form
| [reply] |