Recently added in Lem: tree-sitter for JSON, YAML, Nix, Markdown, WAT; new language modes: Clojure, Perl, Kotlin, Zig (with LSP); git-gutter mode.
Lem has a (quite simple still) Git/hg/fossil interactive mode (interactive rebase is there but no reword for instance) and org-mode support is coming (https://github.com/mahmoodsh36/organ-mode).
Lem now is ncurses + webview (+ the non-longer maintained SDL2 backend) and it has daily multi-platform binaries. Try it out!
Common Lisp standard (and its implementations) really needs an uplift to shine. There are so many shortcomings and missing features in it that listing them here would take a lot of space. Instead, I will point to some proposals like Common Lisp 3[1] and Compact Lisp[2]. Meanwhile proper typing should be introduced out of the box, like in Coalton[3], for example. Also, pattern matching should be the part of the language, not some external library [4]. Even something basic but foundational is not yet standardized - Unicode support!
The author mentions in the article text (and re-emphasizes in a footnote) that you will want to use platform-specific APIs for improved accessibility even when this limits extensibility:
> you will want to support font fallback, input methods and screen readers, all of which require interacting with platform specific APIs and are thus much less customizable
May I ask the heretical question why of these two situations:
(a) you have one editor that makes compromises between extensibility and accessibility
(b) you have one non-accessible editor that goes all-in on extensibility, and one not-fully customizable editor that goes all-in on accessibility
one would prefer (a) over (b)? Situation (a) sounds like strictly more total effort for a worse outcome, as you have one much more complex system that tries to navigate both purposes.
What I got from this is that the author doesn't like the term Extensible being used for situations that don't follow good software engineering practices. Maybe the term Hackable is less offensive and implies dirtiness being okay.
7 comments
[ 3.1 ms ] story [ 46.7 ms ] threadGlad we settled that.
Lem has a (quite simple still) Git/hg/fossil interactive mode (interactive rebase is there but no reword for instance) and org-mode support is coming (https://github.com/mahmoodsh36/organ-mode).
Lem now is ncurses + webview (+ the non-longer maintained SDL2 backend) and it has daily multi-platform binaries. Try it out!
https://lem-project.github.io/
[1] https://github.com/blakemcbride/common-lisp-3
[2] https://github.com/lassik/compact-lisp
[3] https://coalton-lang.github.io/
[4] https://lispcookbook.github.io/cl-cookbook/pattern_matching....
> you will want to support font fallback, input methods and screen readers, all of which require interacting with platform specific APIs and are thus much less customizable
May I ask the heretical question why of these two situations:
(a) you have one editor that makes compromises between extensibility and accessibility
(b) you have one non-accessible editor that goes all-in on extensibility, and one not-fully customizable editor that goes all-in on accessibility
one would prefer (a) over (b)? Situation (a) sounds like strictly more total effort for a worse outcome, as you have one much more complex system that tries to navigate both purposes.