Re: Perl embedding: trial balloon

John> Efficiency can wait. At the moment I am more interested in John> tuning the semantics of Perl as Emacs language and Perl as John> Lisp extension. OK. It may be really slow, though, if you need to go through the low-level Mule functions rather than operate on the internal representation directly. John> Aside from the issue of regex search and replace, which I John> assume for the sake of argument will be hard to get to work John> with Perl regex, do This doesn't make sense to me at all. Just add the Perl regex engine to Emacs itself and define a bunch of functions with different names that use the Perl engine's functionality. This has been discussed a fair amount at different times. As long as you use the proper Emacs functions to to the replacing, you shouldn't have a problem. I can't vouch for their semantics as opposed to Perl's s/// operator, but you specified regex semantics, not substitution. John> you see any other Emacs features that cannot be accessed John> simply by calling functions with the usual elisp data types? Calling _Lisp_ functions (or low-level XEmacs functions), you mean? That will always work in the sense of "do something" and "not crash XEmacs unless there's an underlying bug". Whether the behavior will make sense to Perl programmers is another question. And it probably won't make sense to Lisp programmers, who will be expecting the "usual side-effects" and will be presented with a different set. John> Huh? I want Perl to chew on the text in my buffer, not draw John> widgets. Could you please elaborate. "External widget" means to set up Perl to use XEmacs as an embedded editor. Perl can slurp the file you want to edit into a Perl string, pass it back and forth to XEmacs, etc. Similarly, it can slurp Perl code out of another buffer. Restricting yourself in this way is guaranteed Mule-safe, because strings will always be in external represention rather than Mule representation (which internal representation may change in the not-so-distant future if Oliver Galibert has his way). This is of course a variation on Kyle's `shell-command-on-region' strategy, except that XEmacs itself is your shell, and it's embedded into Perl. John> The sequence `C-u M-| perl' is etched in my spinal cord, but John> sometimes one wants Perl for more sophisticated jobs, and John> sometimes one is deprived of a reasonable shell. If "more sophisticated" means running external processes, etc, (all those things that Perl has nice primitives for), it scares me, too. For example, take the file writing functions. Are you going to disable Perl's functions? If not, how are you going to make them respect Emacs's locking conventions? John> Sure, I suppose you could implement a major mode as a John> separate Perl process, but who really wants to invent John> protocols for such things? Not to mention ways to serialize John> and deserialize interesting data structures. You have to invent protocols and [de]serialize anyway, unless you don't care about any users who aren't you. You can just be more flexible and less careful when you grab access to the internal representation (== longer rope). No? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."