Anyone following along in the tinyscheme + mg thread on openbsd-tech? Would you use tinyscheme with mg?

My first thought was that this would be so cool if they did this. My second thought was that I bet there are some scheme (and maybe even some common lisp) people who might be more inclined to use OpenBSD if they chose to have scheme in base. I know myself, the fact they have Perl (and keep up fairly well with new versions) in base has always given me the warm and fuzzies about them.

But then I thought about it more. I wouldn't actually use it.

First, I don't use mg at all despite using and liking emacs a lot. When I want a small editor I use vi. To me, completely different key bindings and user interface is better when switching between editors than almost the same but with slight differences. mg, like every other little editor with emacs key bindings, always annoys me when I try to use it.

Then there's whether it's really exciting to have this as a way to use scheme instead of emacs lisp to customize my editor (imagining mg became my editor). Scheme is a nicer language IMO than Common Lisp, for sure, and would be an improvement over emacs lisp too. If some GNU person resurrected the guilemacs effort or they managed to somehow get guile and elisp to coexist harmoniously in a later emacs, that would be cool. But mg + tinyscheme? Are the OpenBSD people going to be the ones who finally redo emacs "the right way" with a "real lisp?" I don't think so. First, the people who've been thinking about this I've heard of are people many of the OpenBSD people probably wouldn't get along with (GNU people). Second, is tinyscheme a "real lisp"? It's some easily implementable subset of R5RS. This just sounds like emacs lisp all over again. Worse, because scheme people all seem to have their favourite implementations they want to use. For instance, I like using scsh enough that if I were using mg I'd be more likely to look at what they've done with tinyscheme and try to do the same with scsh instead, rather than using what they've done and participating in any group of OpenBSD tinyscheme users sharing scripts emacs lisp style. And then that's probably not even where they're going. It's probably more mg + tinyscheme is to emacs like nvi + Perl is to vim.

I recall discussion on tech@ about a year ago around adding a scripting engine to mg(1) as the thought was this would make it more flexible to individual tastes. tedu mentioned that he was working on implementing a small Scheme interpreter such that a number of Emacs extensions could then be used in mg(1). At the time, this was seen to be useful work -- adding a small Lisp-like interpreter to a small Emacs alternative. Take that, Mr. Stallman.

Now that there appears to be an interpreter available, the question returns as to whether this is the direction the project wants to take, & whether this is the language to use in other candidates for scripting -- systat(1) & top(1) being two possibilities.

So, what we are seeing on tech@ is continued discussion. It doesn't appear to be final, & I don't expect the work to integrate Scheme into mg(1) to commence quite yet.

I recall discussion on tech@ about a year ago around adding a scripting engine to mg(1) as the thought was this would make it more flexible to individual tastes. tedu mentioned that he was working on implementing a small Scheme interpreter such that a number of Emacs extensions could then be used in mg(1). At the time, this was seen to be useful work -- adding a small Lisp-like interpreter to a small Emacs alternative. Take that, Mr. Stallman.

I'd argue that anyone who thinks chucking an interpreter into a text editor makes it an emacs alternative doesn't get emacs. I suspect most of them would never want to and that's fine, but the truth of it is that all the so called bloat is what emacs is all about. Wanting to do emacs one better but at the same time be minimal is a contradiction. Wanting to do emacs one better by using scheme instead of emacs lisp, well if you can get there during your lifetime, then now we're talking.

I'd argue that anyone who thinks chucking an interpreter into a text editor makes it an emacs alternative doesn't get emacs. I suspect most of them would never want to and that's fine, but the truth of it is that all the so called bloat is what emacs is all about.

I agree, & I suspect the interested developers do too. My suspicion is that a number of people would find mg(1) more attractive if their favorite third-party Emacs modes could be integrated. I use Emacs nearly exclusively now, but I don't use Emacs for mail or its other kitchen-sink features. I don't live in Emacs, & I don't want to do so. I would drop Emacs entirely on OpenBSD if I could get a C-mode, Perl-mode, & Python-mode-like features (along with split windowing...) on mg(1). If the exact same extensions could be integrated (warts & all...), this would be a plus. I suspect this is the demographic targeted by the current developer mindset from what I read -- at least this is what I walked away with from the discussion a year or so ago.

The flip side of this discussion is what are the ill-effects which comes with growing mg(1) from a small compiled application to a run-time interpreted environment. mg(1) as it is now is refreshing small & fast in comparison to Emacs. Unfortunately, Emacs has some (not all...) features I would like in a replacement. If mg(1) could retain some of its original agility after having a script engine added, that would be the bomb (), but this would not be known until the work was finished.

Last edited by ocicat; 28th June 2012 at 06:43 PM.
Reason: added missing grammar for clarity

In reading undeadly's post mortem on the recent g2k12 hackathon, it looks like Lua 5.2 is being considered as the potential scripting engine for integrating into mg(1) as opposed to TinyScheme. Apparently, there is a similar discussion brewing around tmux(1) as well:

Quote:

...we figured that using Lua instead of Scheme would be an easier choice in order to extended mg, and to replace some existing C code with Lua. Having Lua in base would also allow for extending tmux(1) with Lua and various other neat applications of the language. So in order to prepare for such a move if it were to hapen eventually I spend some time on preparing Lua 5.2 for import into the base system. Please note that it's far from ready and may not even happen at all.

Oh well. Boring, but probably more in line with what most people are used to in terms of syntax. And Ted Unangst at least is a Lua fan which counts as one more OpenBSD developer in the Lua camp than I know of who is strongly in the Scheme camp, unless Aaron Hsu is an OpenBSD developer.

At least now I don't have to worry about taking myself on yet another useless excursion to explore replacing gnu emacs/elisp with mg/tinyscheme or trying to (or daydreaming about?) re-implement the Gnus newsreader in Scheme and mg. Actually, I read the other day that someone's done Gnus in Scheme for Edwin. Crazy.