Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs-like editors written in Common Lisp

cliki.net

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Emacs-like editors written in Common Lisp

#61

Post by tmtvl »

OrderlyTiamat wrote: post #59
tmtvl wrote: post #2

It's nice to see more Emacsen, though without something like eglot or lsp-mode I don't think they'll really take off. That said, I am very fond of the undo-tree package for Emacs and I doubt I could switch to any editor that doesn't have something similar.

is there a tldr on undo-tree's capabilities? I really like emacs' default undo behaviour, especially it's region bound behavior. undo-tree is kind of like vim right? Ive actually never really grokked that one either. I even remove undo-tree after installing evil as its an unwanted change for me, and evil has no option not to use it.

Undo tree stores the changes you make in a tree, like Emacs does by default, but its undo function is undo only and its redo function is redo only. When there are multiple different changes you can redo you can select which one you want.

Vundo offers that functionality with Emacs' default undo tree, making it an objectively better package as it preserves undo-in-region, which undo-tree lacks.

Re: Emacs-like editors written in Common Lisp

#63

Post by pfdietz »

Jtsummers wrote: post #44
epr wrote: post #32

Earlier quoted context omitted.

What? Wasn't ANSI CL standardized in 1994? Besides incremental performance and security improvements, what needs to change? Compare this to other popular languages from C++ to Python, which surely generate tons of additional work by continually changing the languages themselves.

There are a lot of redundancies in the language standard library caused by it being an amalgamation of multiple prior Lisps. Later standards could have deprecated some of those and then later removed them to provide a cleaner system, but they were needed in order to achieve the goal of mostly supporting other Lisps out of the box at the time of the standard (that is, with few or no code changes). elt and nth as examp…

The issues in the first two paragraphs there are addressable at the user level: just import from a package other than COMMON-LISP, where things are implemented to be more to your liking.

So, what you actually want is that doing this could be done in a way that everything is as efficient as if one invoked the CL built-in functions. I think a little more smarts in CL compilers could do this, in particular efficient invocation of generic functions when the argument classes are known at compile time (doing this in a way that allows methods to be added or redefined requires some care but can be done.)

Re: Emacs-like editors written in Common Lisp

#64

Post by iLemming »

pvinis wrote: post #4

I'm really curious: do people consider common lisp to be the go-to lisp today? if yes, that's awesome, I'll look into it. if no, what is the go-to? and is there an emacs-like using that lisp?

To be honest, I personally never understood this notion "of what Lisp should I choose?". For the first-timers, for learning - any Lisp would do, Clojure, Racket, Fennel, CL, Janet, even Emacs Lisp. Once you're through the basics - structural editing, REPL-driven workflow, etc., then switching between Lisps is not that difficult.

Yes, they are different languages, working atop different platforms. They have different semantics, vastly different core libraries, etc. Yet at the same time, somehow, there's little mental overhead when switching between them.

I don't have any difficulties moving between Fennel, Clojurescript, Clojure, Clojure-Dart, LFE. But if I had to manage writing code and maintain multiple projects in Lua, Javascript, Java, Erlang and Dart - I would claim that my name is Guy Stele Jr. and I am a very smart programmer. Alas, I'm not that smart, that's why I chose Lisp.

Re: Emacs-like editors written in Common Lisp

#65

Post by Jtsummers »

pfdietz wrote: post #63
Jtsummers wrote: post #44

Earlier quoted context omitted.

There are a lot of redundancies in the language standard library caused by it being an amalgamation of multiple prior Lisps. Later standards could have deprecated some of those and then later removed them to provide a cleaner system, but they were needed in order to achieve the goal of mostly supporting other Lisps out of the box at the time of the standard (that is, with few or no code changes). elt and nth as examp…

The issues in the first two paragraphs there are addressable at the user level: just import from a package other than COMMON-LISP, where things are implemented to be more to your liking. So, what you actually want is that doing this could be done in a way that everything is as efficient as if one invoked the CL built-in functions. I think a little more smarts in CL compilers could do this, in particular efficient inv…

Right, cleanup stuffs like I started off with would be easy enough to do now. And reasonably common extensions are covered by things like Alexandria. But going to more generics introduces a potential performance hit without the implementations being onboard to improve how they handle generic functions and method dispatch. And then there are other enhancements (like concurrency) that are bounded, with regards to portability, by whatever implementations uniformly make available. So any changes there will require implementations to be involved if it's going to result in portable code. Otherwise you'll have people implementing things using, maybe, CFFI and tying it to a particular implementation, OS, and set of external libraries, which breaks portability.

Re: Emacs-like editors written in Common Lisp

#66

Post by nequo »

OrderlyTiamat wrote: post #59
tmtvl wrote: post #2

It's nice to see more Emacsen, though without something like eglot or lsp-mode I don't think they'll really take off. That said, I am very fond of the undo-tree package for Emacs and I doubt I could switch to any editor that doesn't have something similar.

is there a tldr on undo-tree's capabilities? I really like emacs' default undo behaviour, especially it's region bound behavior. undo-tree is kind of like vim right? Ive actually never really grokked that one either. I even remove undo-tree after installing evil as its an unwanted change for me, and evil has no option not to use it.

Walking the tree of changes has proven very useful to me several times.

Undo-tree can also display the diff for each change. Useful when an operation induced changes in different parts of a long document (for example rerunning source code blocks with org-babel).

Re: Emacs-like editors written in Common Lisp

#67

Post by User23 »

LukeShu wrote: post #9
pvinis wrote: post #4

I'm really curious: do people consider common lisp to be the go-to lisp today? if yes, that's awesome, I'll look into it. if no, what is the go-to? and is there an emacs-like using that lisp?

Some folks'd say that yeah, Common Lisp is the go-to Lisp. Some folks'd say no, the go-to is Scheme. Guile is GNU's common language runtime, sorta like Java's JVM or Microsoft's CLR. And Scheme is really the only first-class language of Guile; to a lot of people "Guile" means "Scheme". I don't know of an Emacs-like using Scheme, but there is an effort to implement Emacs-Lisp on Guile, and have GNU Emacs ditch its Lis…

If I ever take a sabbatical year then porting the C parts of GNU Emacs to Common Lisp is a project I’d love to do. Then one could host GNU Emacs in a CL image and get the whole package ecosystem. The end goal would to make CL and Elisp both valid choices for customization.

My implementation strategy would probably be to start by using FFI to reuse as much of the C code as possible and then incrementally rewrite it. Or not, maybe that wouldn’t even be necessary.

Re: Emacs-like editors written in Common Lisp

#68

Post by pfdietz »

Jtsummers wrote: post #65
pfdietz wrote: post #63

Earlier quoted context omitted.

The issues in the first two paragraphs there are addressable at the user level: just import from a package other than COMMON-LISP, where things are implemented to be more to your liking. So, what you actually want is that doing this could be done in a way that everything is as efficient as if one invoked the CL built-in functions. I think a little more smarts in CL compilers could do this, in particular efficient inv…

Right, cleanup stuffs like I started off with would be easy enough to do now. And reasonably common extensions are covered by things like Alexandria. But going to more generics introduces a potential performance hit without the implementations being onboard to improve how they handle generic functions and method dispatch. And then there are other enhancements (like concurrency) that are bounded, with regards to porta…

I'd argue genericizing a built-in won't impose a performance penalty on anything it currently is required to do. That's because it already has to dispatch on the classes it does handle, and also should recognize and error when it's given a class it doesn't. Adding more cases just means replacing the old error case with more decisions (if dispatch is implemented by a decision tree), or expanding the hash table (if dispatch is handled by the usual CLOS dispatch table.)

There is a general philosophy in the design of Common Lisp: expose to the user facilities that are used by an implementation for the implementation of built-ins. I don't think Common Lisp is quite complete in this respect, but this would be the place to extend it.

Re: Emacs-like editors written in Common Lisp

#69

Post by djha-skin »

ducktective wrote: post #58
djha-skin wrote: post #48

Earlier quoted context omitted.

To be clear, unfortunately I do not program professionaly in CL. I use vim + vim-slime (jpalardy) + GNU screen + rlwrap. dotfiles here[1], here[2] and here[3]. Blog post about this will be written subsequently at https://blog.djha.skin . 1: https://git.sr.ht/~djha-skin/dotfiles/tree/main/item/dot-con... 2: https://git.sr.ht/~djha-skin/dotfiles/tree/main/item/dot-loc... 3: https://git.sr.ht/~djha-skin/dotfiles/tree/ma…

Very cool! Thanks for sharing the dots! I'm a vim user too, but recently I've been considering Common Lisp mainly due to this post: https://mikelevins.github.io/posts/2020-12-18-repl-driven/ so I did a brief tour on Emacs (cause everyone uses sly) but both Emacs and CL take too much time so I've postponed them. Would be nice if you describe your vim+cl workflow and how does it hold up to Emacs+Sly+Org-mode ™

https://blog.djha.skin/blog/developing-common-lisp-using-gnu...

Re: Emacs-like editors written in Common Lisp

#70

Post by ArtixFox »

brabel wrote: post #55
djha-skin wrote: post #22

Earlier quoted context omitted.

I have used Clojure on and off for probably 7 years. But when I tried to distribute my program which was a CLI tool, it proved incredibly painful. Clojure startup time is really bad over a second in the best case and it gets worse the more libraries you include. This is not a problem if you are writing a web application, but it's terrible for command line applications. The community seems thoroughly disinterested in…

For CLIs, Common Lisp is excellent. I wrote a small program in CL and Rust, and (SB)CL can run faster than Rust EVEN FROM SOURCE! It's just completely mindblowing how fast it starts. If you don't believe me, write a program that does something like count how many times each letter appears in a text file in CL and Rust, then run them with `time`. I can pretty much guarantee CL runs as fast or faster. EDIT: my comment…

Ooooh nice!!! That is amazing but how viable is common lisp for low level programming. Instead of embedding CL, what about a DSL that creates binaries, does something like this exist?
Post reply on HN