In fact, I have plans for the BUFFER filehandle to refer automatically to the current buffer. Filehandles can be tied in Perl. Translation can be performed in READ, READLINE, PRINT, etc. methods. Again, for optimization, one might eventually want something more low-level. Likewise, STDIN and STDERR will automatically use the minibuffer, and STDOUT will send its output to the current buffer. I don't know any of the details of Mule, text properties, intervals, etc., but Perl is quite flexible. There are as yet no Perlmacs applications. One idea is a graphical Perl debugger and data browser. Another is to use Perl's POSIX thread support (with a global emacs mutex, of course) to download big files in the background. Then there is Perl's network connectivity, database drivers, etc. See http://www.perl.com/CPAN/modules/00modlist.long.html for a long list of possibilities. Yes. I don't see any way around that requirement. uh-oh! You read my mind... ;-)

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; wrote: Efficiency can wait. At the moment I am more interested in tuning the semantics of Perl as Emacs language and Perl as Lisp extension. Touché! Perl is certainly the product of a hectic evolution and has evolved some rather gross warts, but it is still oh-so-comfy for us addicts. Aside from the issue of regex search and replace, which I assume for the sake of argument will be hard to get to work with Perl regex, do you see any other Emacs features that cannot be accessed simply by calling functions with the usual elisp data types? Huh? I want Perl to chew on the text in my buffer, not draw widgets. Could you please elaborate.

Kyle Jones <kyle_jones(a)wonderworks.com&gt; wrote: The sequence `C-u M-| perl' is etched in my spinal cord, but sometimes one wants Perl for more sophisticated jobs, and sometimes one is deprived of a reasonable shell. Sure, I suppose you could implement a major mode as a separate Perl process, but who really wants to invent protocols for such things? Not to mention ways to serialize and deserialize interesting data structures. Actually, I find it quite entertaining. :^) But seriously, if ordinary Perl code or ordinary Lisp code is crashing its interpreter, there is probably a simple low-level fix, once you run it through GDB with all the bells and whistles on. I have done this intensively over the 15 months of Perlmacs' existence, and I claim that it is pretty solid, clean, and concise. Of course, that doesn't mean we'll be ready to enable Perl support by default for quite some time.

Per Abrahamsen <abraham(a)dina.kvl.dk&gt; wrote: I have a feeling that is what RMS says when people tell him about XEmacs. The difference between dynamic and static linking is mainly psychological. GNU Emacs does a good job satisfying the editing requirements of Richard Stallman. I thought XEmacs sought to do the same for the rest of the world, but apparently it is only for the rest of the Lisp-speaking world. Perhaps we should fork an X^2Emacs that goes the rest of the way.

John Tobey writes: I have to say that I am flatly floored by what I have read over the last few hours. To John: Keep the faith, and keep doing good work. There are lots of people who want what you're doing. I suggest ignoring the attitude, and focusing on the work rather than forking a new strain just because some key people need to have their world views enlargened.. To the XEmacs beta team: You guys need to get a life. I really cannot believe what I have read from you guys on this topic recently. It's not the facts that floor me, its the attitude. So you don't like Perl. Fine. Who cares what you languages you like, anyway? So you don't want XEmacs hooked up to too many different things. Tough. It's going to happen whether you like it or not. Maybe you've forgotten what the GPL is all about? After seeing what has been said to John, I feel certain that my own purposes in inquiring about Elisp/C extension coupling would not impress you either. So what's your goal? To drive away people toting uncouth baggage? Or to make XEmacs a flexible and powerful work environment? You guys need to get that straight and let us know. Should you decide you want to make XEmacs into a platform which can foster the creative inclinations of people beyond your core team, you might oughtta invest a little time in making it as easy as possible, and as safe as practicable, for people to dynamically load in modules they want, that you don't want in the core distribution. In any event, please cut John--and by obvious extension, the rest of the world--some slack for being interested in more things than just Elisp, and tone down all this rhetoric. It makes it hard to concentrate on the work. I for one, have a lot to learn about XEmacs, both the lisp side, and the C internals. And I would like to believe I have the freedom to ask questions on the beta channel. Although I have actually gotten many helpful snipets over the last few weeks, including a little constructive advice at the top of this thread, I have to say that seeing all this attitude projected at John has definitely cast a cold frost across the XEmacs landscape. -- Geoffrey Furnish Actel Corporation furnish(a)actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski

Geoffrey Furnish writes: If you don't like the way the project is being run you always have the option of forking your own branch. That is how XEmacs came into being and there's certainly no law that says XEmacs can't have disgruntled spinoffs of its own. The reason this kind of forking has not happened over past disputes is the same reason why the current maintainers are nervous about merging Perl and Emacs. In a word: maintenance. Merging Perl and Emacs is only the beginning, there are years of work after that, just as there are years of work ahead once you fork a branch of Emacs. We simply cannot accept work that isn't in a form that we can realistically maintain. We have no paid help, not a single person. So we have to be discerning, we have to say "no" sometimes, we have to distinguish hard work from good design. It is not good design to take two systems evolving at different speeds, and in different directions, and written for fundamentally different purposes and mash them together. Particularly two systems as complex as Perl and Emacs.

At 12:11 AM 4/20/99 -0400, John Tobey wrote: I thought the whole reason that we included loadable modules was so that projects like this could be "supported" in the main development tree without shooting large numbers of users and maintainers in various parts of their anatomy. I don't see what the fuss is, although if you can't do it with loadable modules then I would have to start jumping up and down and tearing my hair out .... :) andy

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

John> I personally will be happy if all Perl support goes through John> funcall. This would be rather slow for typical Perl-ish direct buffer manipulations, I should think. John> Maybe things like car and cdr can avoid it for John> speed, but that will happen in a Perl module (Emacs::Lisp) John> and will not touch the xemacs binary. ??? Why would Perl code go ripping into list structure? It was in a different context, but you did write "I want Perl to chew on the text in my buffer". And car and cdr are not good examples, I think; they're heavily optimized already. Any attempt to speed them up ... you're rattling coffins here .... John> I'm not sure why any of this concerns Lisp programmers, John> unless they choose to use Perl. Because they shouldn't have to care what's in any package that XEmacs can execute. So they might be using Perl, but they shouldn't have to know it. Worse, a package that they thought was Lisp (because that's the language it was written in) could require a Perl module. Of course, you could always add "This XEmacs is Perlmacs-enabled. That means that nothing can be relied upon to behave like it used to (although as far as we know it does, we cannot _prove_ that it will continue to do so), and you could experience severe data loss unless you carefully check all possible Lisp/Perl interactions in all packages that you may explicitly or implicitly load." to the splash screen. That's what Kyle was saying, although much more politely. John> So, if I understand you, XEmacs can be linked as a library John> and dynamically loaded? What about unexec? Yes to the first. I don't understand unexec, so I can't answer that. John> It is possible to override some core Perl functions. I John> believe `open' is among them. Already, I have written a John> tied version of Perl's %ENV hash that updates John> `process-environment'. I plan to coordinate signal handlers John> using a similar strategy. OK, that all sounds doable. But there's a lot of stuff that Perl can do, and that XEmacs can do; I don't see how we can claim to be trying to guarantee no dangerous interactions of the kind referenced in my hypothetical splash screen. That's what XEmacs.org means when it says "XEmacs supports" AFAIK. John> However, that simply does not appeal to me. An embedded John> interpreter is more elegant, in my opinion, so it is what I John> chose to work on. Well, you have my best wishes; that's as good a reason as I've heard for working on anything. But I've heard enough to know that, speaking for exactly one person, I'm not much interested in the goals you've stated. I admit that there are times when I would use a limited Perl functionality to munge buffers (although fewer as time goes on), but the halfway house you describe sounds too unpredictable to me for writing reusable packages; I'll stick to `shell-command-on-region' plus a few extra keystrokes where necessary. -- 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."

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; wrote: Just out of curiosity (as I don't follow the newsgroups that much), how many people are opposed to Mule? I had the impression it was pretty well established, having been adopted by both FSF and XEmacs. Of course, I don't use it much, being an American. If it's just good old Erik with his cl-emacs, I can almost guarantee you that man will never ally himself with a Perl programmer.