Osm.el – OpenStreetMap Viewer for Emacs
github.com
github.com
I'm flabbergasted at how snappy and intuitive it is!
- performance is not great (although it’s getting better with the advent of native compilation in Emacs 28)
- the system language is awkward (no namespaces, dynamic scoping by default, ...)
- no preemptive multithreading
- etc.
On the plus side, it is auto-documenting and extremely malleable.
[0]: Yeah, it can be a full-fledged OS. Just add a Linux kernel: http://informatimago.free.fr/i/linux/emacs-on-user-mode-linu...
RMS's dislike of Common Lisp really caused a colossal amount of damage. Imagine an Emacs written in Common Lisp instead of Emacs Lisp, with decades and decades of improvements. Having written a reasonable amount of software in both, Common Lisp Emacs would be very, very preferable, in part for the reasons you list and in part for others (e.g. a full-fledged, built in object system and improved extensibility).
[1] https://nyxt.atlas.engineer/article/why-building-nyxt-instea...
If Emacs were written in Common Lisp, only people on big mainframes would have been able to use it in 1985, and it probably wouldn't have become popular in the first place. Also, implementing Common Lisp would have taken much longer. RMS has said that his main goal with his LISP dialect was to keep the programming language as small and performant as possible, since at that time, machines had maybe 1MB of RAM (if you were lucky) and no virtual memory. This is why for instance he decided against lexical scoping (and still, Emacs was known back then as "eight megabytes and constantly swapping").
[0]: https://github.com/lokke-org/lokke [1]: https://gitlab.com/python-on-guile/python-on-guile
This is not much of a problem in practice these days. As you probably know it's trivial to enable lexical-binding for an entire source file and many (most?) modern packages do just that. It's even on by default in the scratch buffer. Emacs is just more user friendly than most other systems when when it comes to backwards compatibility.
Long line performance is still a huge problem. Emacs team does an amazing job keeping up, but the age shows itself everywhere. In the end I've realized that org/magit were not life-changing for me, evil-mode it the only thing I care about. :)
I don't even use LSP because I have my own ways of browsing source code through emacs. So I go off and tout emacs' amazingness, but then when someone tries it and attempts to use what worked in other editors, it's a slow laggy mess.
I don't think people should try to use Emacs to build an OS on top of, but building an OS without understanding why Emacs survived is going to just end us up in the same world of inflexible, brittle, clunky software we're in now.
Overpass Turbo for queries: https://overpass-turbo.eu/
Level0 for text-based edits: https://wiki.openstreetmap.org/wiki/Level0
Meanwhile Google Maps has one increasingly user-hostile frontend per platform. It won’t let me see how long a route with waypoints is, and it just started showing me a news feed every time I use it.
OpenStreetMap is as precious as Wikipedia, and very few people seem to realise it.
When do those big performance improvements for Emacs Lisp ship?
Thanks!
Someone else here said that Osm.el is very performant. At its best, Emacs is like a Smalltalk environment where you can happily do all of your work in one environment.
Anyway, I have bookmarked Osm.el and if Copilot becomes available for Emacs I really look forward to spending a day installing both at once.
Great, another distraction to tap my time.
"The Unix philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978: Make each program do one thing well"