Hacker News Reader

Comment by hollerith | Hacker News Reader

The software we are talking about relies on McCLIM, whose github README.md says that "Right now the only backend supported by McCLIM is CLX, which ties it to the Xserver on the host system."

In contrast, Gnu Emacs has bindings to native GUI libraries on Windows, Mac and Linux. By "native" I mean Xserver is not required on any of them (and GTK is required only on Linux).

Details: on Linux the feature/pgtk branch of Gnu Emacs (of which I am a happy user) talks directly with GTK and Wayland with no need for an Xserver though there is a risk that feature/pgtk will never be merged into Emacs's mainline because influential Emacs users like to run their Emacs process on powerful computers remote from the computer in front of them, and so far no one has gotten that "remote" feature to work in the feature/pgtk branch without using "the TTY interface", which lacks features of the other interfaces described above (the Windows interface, the Mac interface, etc).

View on HN

X has been the bane of McCLIM for the last 20 years. It limited adoption and delivered horrible first impressions to not-hardened Lisp users / McCLIM developers: Basic-level functionality that's supremely important for a positive experience such as font rendering, absence of graphical glitches, tearing, smoothness and overall look&feel was bottom-of-the-barrel for very long periods of time. Maybe it still is, I don't know since I no longer use X.

Hopefully that is about to change. Daniel Kochmanski seems willing to push McCLIM forward with alternative rendering backends. Moreover, Luke Gorrie (of SLIME and Distel fame) is working on an Emacs McCLIM backend: https://mobile.twitter.com/lukego/status/1387747747864973312

Alternative backends are old thing, Daniel mainly documented how to make them (other than various cleanups underneath).

The reality is that nobody cared enough about those alternative backends to keep them alive (other than CLX, for a time beagle was usable - but only on OSX, unless someone did a lot of work to compile it for other unices using GNUstep/OPENSTEP)

Well yeah, if there's no documentation on how to create a backend, the barrier to entry is that much higher. It is great that this is now getting addressed.

And none of the old alternative backends, including Beagle, ever worked for me. I certainly tried. I think it's fair to say that all of them were in various states of disrepair and none ever reached the point of "fully working".

I'm pretty sure beagle worked for a time, but that time was probably "CCL/RMCL on PPC mac with OSX" and I don't think it would cover all versions of that.

Yeah I worry about the reliance on CLIM too. I want to like it but it seems so complicated and general despite also not seeming that useful or relevant today. Perhaps it is something that really requires everything to already be in CLIM, or perhaps it is just incomplete and insufficient at the moment due to a lack of resources.

Supporting multiple backends sounds like a good idea but if CLIM is one backend among “many” then it cannot be taken advantage of. But maybe CLOS will allow CLIM to still be exploited.

The backend are implemented “behind” CLIM itself: McClim is designed to abstract over multiple rendering backends. For a while the X backend was the only one that was ready, but I think there’s ongoing projects for a Windows and a Gtk/Cairo backend right now.

This is the kind of backend I was referring to:

> Climacs depends on McCLIM for its graphic user interface. Second Climacs is independent of any particular library for making graphic user interfaces, allowing it to be configured with different such libraries. Though, at the moment, the only graphic user interface that exists uses McCLIM

Hm, Luke has also been working on a GTK backend for McCLIM. I wonder if he gave up on that, or just working on it in the background, or simply put it on pause for a bit?

That must be someone else. The Emacs backend is the first one I'm working on.

So it seems. It's actually lokedhs. I must have mixed up "loke" with "luke".

The surprise for me, working on the Emacs backend for McCLIM, is that CLIM is actually a lot simpler than it seems.

The CLIM specification is overwhelming. The Lispworks and Franz user manuals for CLIM are too. There are just too many concepts being presented at the same time and with incredibly complex class hierarchies (e.g. a Stream is a Medium is a Pane is a ... I can't keep track.)

But behind all of that there are a few simple and mostly separate frameworks: describing colored geometric shapes and text; associating drawn shapes with application objects; defining commands to operate on application objects.

You can actually pick and choose from these APIs and map them onto whatever "backend" you like. The Emacs backend, for example, initially just translated the geometric drawing commands into SVG elements. That was really easy. Then we added unique IDs to those elements so that we can enable/disable them as input sources - also fairly easy.

The Emacs backend is becoming fairly extensive but it's still only 650 lines of code: https://github.com/nuddyco/McCLIM/blob/clime/Backends/Emacs/...

> Luke Gorrie is working on an Emacs McCLIM backend

This works quite well now. If anyone wants to try it the installation instructions are at https://gist.github.com/lukego/0b74b94492066ae2b8c2a12b18e84....

FYI I use waypipe with the feature/pgtk branch as part of my daily workflow, and it works great---better than X11 forwarding in fact.

> and GTK is required only on Linux

You can build GNU Emacs for X with Lucid instead. Motif too, but that is getting removed soon.

Thanks for correcting.

Some cross-platform text editors like Textadept require GTK on Mac and Windows, but Gnu Emacs does not, is what I meant to say.

Reply on news.ycombinator.com