[HN Gopher] Second Climacs - Emacs Implementation in Common Lisp
___________________________________________________________________
Second Climacs - Emacs Implementation in Common Lisp
Author : xvilka
Score : 90 points
Date : 2021-05-25 14:53 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| acdw wrote:
| As I've been learning more Emacs Lisp and Common Lisp, I've found
| that they're really quite similar. So I've been wondering why
| Emacs wasn't written in Common Lisp. Of course, I think the
| answer to that one is the age of Emacs -- it was around before
| CL? -- but this project will be one that I check in on
| periodically, for sure.
| iib wrote:
| This is the story [1], told by Stallman. But yes, basically
| because Common Lisp was too big. That is also the reason GNU
| uses Scheme as a language for extensions.
|
| [1] http://www.gnu.org/gnu/rms-lisp.html
| ska wrote:
| emacs in various forms definitely predates CL; but I suspect
| around the time CL was ratified (84?) any discussions about a
| re implementation would have focused on the size of CL
| implementations being unacceptable for inclusion in an
| editor...
| lispm wrote:
| subsets of Common Lisp existed early on
| ska wrote:
| Sure, and lots of lisps existed in the 15 years or so
| before CL.
|
| The ones that looked anything like CL were pretty heavy. I
| imagine the decision to write elisp at all in the first
| place was made by people pretty familiar with what existed
| at the time, and why it wasn't a good fit for them....
| lispm wrote:
| xlisp for example started small in 1983 and over time
| added some CL features. It was also used by Autodesk as
| the base of Autolisp on a zillion PCs...
| jhgb wrote:
| Common Lisp didn't exist in a useful state at that time.
| Furthermore was probably too large for this application at that
| time.
| agumonkey wrote:
| Also a bit controversial.
| nerdponx wrote:
| I'd be curious about a Racket implementation. I know Racket is
| supposed to be a research and teaching language, but in several
| respects it seems to be a better Common Lisp than Common Lisp
| itself.
| vindarel wrote:
| Here are some lispers' impressions: https://gist.github.com/v
| indarel/c1ef5e043773921e3b11d8f4fe1...
|
| Racket seems to miss at least two big points: the
| interactivity/the debugger and the condition system.
| dreamcompiler wrote:
| That might have become more true recently because of the
| Racket-on-Chez compiler, but until then Racket was in most
| cases slower than Common Lisp because it wasn't AOT compiled
| to the metal, which Common Lisp is.
|
| I also like CLOS (the Common Lisp object system) better than
| the object systems available in Racket, as well as Common
| Lisp's macro system. But that's just personal preference. The
| existence of Typed Racket is pushing me to explore Racket
| more.
| gmfawcett wrote:
| > it wasn't AOT compiled to the metal, which Common Lisp
| is.
|
| It's required that a CL implementation supports
| compilation, but compiling to machine code isn't required.
| e.g., Clisp has a bytecode compiler.
|
| - https://en.wikipedia.org/wiki/Common_Lisp#Compiler_and_in
| ter...
|
| - https://clisp.sourceforge.io/impnotes.html#bytecode
| lispm wrote:
| Though they experimented with a native code JIT...
| mark_l_watson wrote:
| That would be nice, for sure. At least the Racket IDE editor
| supports some Emacs key bindings.
| dreamcompiler wrote:
| Hemlock is another Emacs implemented in Common Lisp. I don't know
| how it differs from Climacs except the latter obviously uses CLIM
| as its front end. Modified versions of Hemlock are used as the
| IDE editors for CCL and Lispworks.
|
| https://en.wikipedia.org/wiki/Hemlock_(text_editor)
| mark_l_watson wrote:
| It is nice being able to use parts of (or all) of the LispWorks
| editor in applications.
| rjsw wrote:
| Hemlock is still delivered with CMU Common Lisp if people want
| to try it out.
| vindarel wrote:
| That's very cool and I'm waiting for it but the usable Common
| Lisp based editors are Lem and LispWorks:
|
| https://github.com/lem-project/lem/ supports CL, Python, C, Rust,
| CSS, Go, HTML, Java, JS, Nim, OCaml... (see the modes/
| directory), it has a directory mode (a la dired) and it seems to
| support LSP (I only tried it for CL so far). It is very much
| Emacs inspired, but is lacking documentation and self-
| documentation features :( There is Lem-OpenGL !
| https://github.com/gregcman/lem-opengl
|
| The most functional, feature-complete, proven editor is the
| LispWorks IDE: http://www.lispworks.com/ A review: https://lisp-
| journey.gitlab.io/blog/discovering-the-lispwork... It's
| proprietary. The free version has annoying limitations. It is
| written with the portable CAPI framework. It has an excellent
| graphical stepper.
|
| And, you might not know, but popular editors are getting good to
| very good support for CL now, at last. SLIMA for Atom nearly
| reaches feature parity with Slime (it doesn't have a stepper).
| For VSCode, see Alive. There's a Jupyter kernel, an Eclipse
| plugin and more. https://lispcookbook.github.io/cl-
| cookbook/editor-support.ht...
|
| libraries: https://github.com/CodyReichert/awesome-cl
| xyzelement wrote:
| > It is called Second Climacs because it is a complete rewrite of
| the Climacs text editor
|
| Oh OK. I _thought_ the name is a naughty pun. Now thanks to this
| totally innocent explanation, I _know_ it is :)
| na85 wrote:
| "Second Climax" is a well-established literary term for the
| climax of the second act of a play:
| https://en.m.wikipedia.org/wiki/Three-act_structure
| imoverclocked wrote:
| _giggles_
| analognoise wrote:
| What's the license?
| Nzen wrote:
| Second Climacs describes itself relying on McCLIM, which is
| enough to infect it with GPL.
| jackdaniel wrote:
| McCLIM is licensed under lgpl-2.1+ and does not impose its
| license on applications.
|
| That said using the word 'infect' seems to imply that
| copyleft licenses are a disease; this does not sound like a
| serious discourse argument.
| analognoise wrote:
| I thought the 'infect' was just used because it's a 'viral'
| license - it fits the medical analogy/broad usage of the
| terms 'viral' and 'infect'.
|
| Is there a standard way to put it that doesn't have
| negative connotations?
| medstrom wrote:
| Infect implies it's involuntary. Nothing's involuntary in
| a new project like this. The standard way to put it is
| "so we went with GPL" or even just "it's GPL".
| Nzen wrote:
| I affirm that I misrepresented McCLIM's license despite
| looking directly at it. I appreciate that you corrected my
| error.
|
| Depending on how modularly Second Climacs combines McCLIM
| into itself, it is possibly LGPL licensed or, at minimum,
| released under the Github terms of service: view and fork.
| I am not in a position to assess the level of integration
| Strandh has opted for.
|
| The Gnu Public licenses are designed to _proscribe_ the
| minimal license features required for works combined with
| those released under GP licenses.
|
| No, my assessment is not a serious argument, it's an
| incorrect puzzle solution, during lunch.
| _ph_ wrote:
| Only when you distribute Climacs with McCLIM included. If you
| distribute it with another backend, the code could be
| licensed with any licence.
|
| In any way, they should attach a license.
| bjoli wrote:
| For those of you not in the lisp sphere: Robert is a very
| competent guy. He is probably the guy you would want for this
| kind of thing.
| loosetypes wrote:
| In school a couple years back I spent fair amount of
| extracurricular time playing around with various lisps and
| frequenting related irc channels.
|
| Robert often went out of his way to answer my dumb questions
| and really helped me better understand a number of things.
|
| Thanks Robert!
| hollerith wrote:
| 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).
| eklitzke wrote:
| 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.
| metroholografix wrote:
| 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
| p_l wrote:
| 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)
| metroholografix wrote:
| 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".
| ashton314 wrote:
| I've often wished for a rewrite of Emacs--the rendering engine
| sure could use some love. The hardest thing in my mind is getting
| compatibility with all the existing Emacs packages. That's where
| I derive most of my value from. If it can't support org-mode,
| magit, mu4e, racket-mode, etc., there's no way that I could
| switch.
| wiz21c wrote:
| The cluffer documentation is really good... But it shows that
| there's a lot of things still to do regarding performance (for
| example to edit very long lines). I'd be happy to read something
| about a proper, performant implementation of a text editor
| buffer. That seems like a very interesting topic.
| p_l wrote:
| Robert presented some of his ideas few years ago at one of the
| European Lisp Symposiums, unfortunately I don't recall the
| title right now. But should be findable using the ELS site[1]
|
| [1] https://www.european-lisp-symposium.org/
| gosukiwi wrote:
| Not even a screenshot? :(
| Mertzenich wrote:
| >I am not accepting contributions at this time.
| nemoniac wrote:
| So if Second Climacs were to get an Emacs Lisp interpreter, how
| far along would it be?
| HDMI_Cable wrote:
| How is this compared to Emacs? Are all of the extensions cross-
| compatible? I would love to use Common Lisp for everything.
| na85 wrote:
| From TFReadme:
|
| >At the moment, all you can do is type some text, and you can
| use C-x i to insert and existing file. Some basic Emacs
| commands also work, like C-f, C-b, C-p, C-n, M-<, M->, and C-x
| C-c. The visible window does not automatically follow the
| cursor yet.
| vindarel wrote:
| You can use CL for everything[0] :] As for text editors,
| there's Lem and LispWorks
|
| https://github.com/CodyReichert/awesome-cl
|
| https://github.com/lem-project/lem/
|
| https://lisp-journey.gitlab.io/blog/discovering-the-lispwork...
___________________________________________________________________
(page generated 2021-05-25 23:01 UTC)