Osm.el – OpenStreetMap Viewer for Emacs(github.com)
github.com
Osm.el – OpenStreetMap Viewer for Emacs
https://github.com/minad/osm
49 comments
I'm once again reminded of: "Emacs is a great operating system, only lacking a decent editor."
That’s the adage oft repeated by people who had had a cursory look at Emacs, but haven’t been really using it. In reality, the opposite is true. Emacs is a great editor, but the operating system that it is [0] is lacking in many ways:
- 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...
- 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...
> the system language is awkward (no namespaces, dynamic scoping by default, ...)
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).
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).
> 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.
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").
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").
IIRC, Coral Common Lisp ran on a Mac Plus, which had 1 MB RAM. It included an editor.
I'm very interested in guile-emacs, not because I think it'll replace main emacs, but I do think it'd be really neat to have my config in a 'cleaner' lisp like scheme, a clojure like language, lokke[0], or even python[1]
[0]: https://github.com/lokke-org/lokke [1]: https://gitlab.com/python-on-guile/python-on-guile
[0]: https://github.com/lokke-org/lokke [1]: https://gitlab.com/python-on-guile/python-on-guile
There has been some work on that over the decades (but of course not enough momentum): https://phemlock.common-lisp.dev/
That may be what nyxt browser is trying to do. The author claims that nyxt could be extended to be anything, including an alternative for emacs.
[1] https://nyxt.atlas.engineer/article/why-building-nyxt-instea...
[1] https://nyxt.atlas.engineer/article/why-building-nyxt-instea...
> dynamic scoping by default
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.
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.
I'm pretty sure when the adage was created it was much closer to the truth. Now it's mostly a joke.
I started using emacs close to 30 years ago. As a text editor, it's pretty much the same as it ever was (the same goes for vi also).
I mostly meant that what we expect from an OS changed a lot since then.
It's not, though, because you now have a wealth of choices beyond the text editor that comes bundled with Emacs.
Emacs is a reflection or a rhyme of a great operating system; it has the critical feature of total inspectability/hackability, but the implementation is poor. There is no other system in use today that has that kind of total transparency all the way to the bottom, or at least, as far down as Emacs does.
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.
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.
False. Emacs has a wonderful vi(m) implementation in the form of evil-mode.
It does have a decent editor, though: Evil mode.
Better than decent. I switched from neovim to evil mode a few years ago and never looked back.
I am in process of switching from emacs to neovim atm (doom evil user before). Whatever I do in emacs (emacs28, jit-compilation, M1) I still experience some UI lags l cannot get with profiler. I suspect slow lsp interface and suboptimal caching/gc. At some point I've tried neovim and was just surprised by how fast it feels.
Company mode is the big offender for me, it handles very large completion lists poorly. I'm not yet fully satisfied with the latency situation in my emacs config, but for me there is no going back. Evil mode let me keep almost all of the muscle memory I ever learned in vim/neovim, and the rest of the emacs ecosystem more than makes up for the latency issues in my opinion.
Corfu might be worth a look, as a lighter weight alternative to company mode: https://kristofferbalintona.me/posts/corfu-kind-icon-and-cor...
And Corfu was written by the same person as this OpenStreetMap Viewer.
I've also experienced some heavy lag immediately after startup - maybe warming up the caches? Had a feeling it gets worse after each package update with compilation.
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. :)
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. :)
Honestly this is a big thing that emacs folks don't value, multi threaded performance.
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 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.
Doesn't everyone need geo-locate and map coordinates while simultaneously editing a config file? You're on hackernews, people will come out of the woodwork to defend this stuff.
In the future, doing queries and edits within Emacs would be awesome!
Overpass Turbo for queries: https://overpass-turbo.eu/
Level0 for text-based edits: https://wiki.openstreetmap.org/wiki/Level0
Overpass Turbo for queries: https://overpass-turbo.eu/
Level0 for text-based edits: https://wiki.openstreetmap.org/wiki/Level0
I just tried it and wow, this works surprisingly great. Pretty snappy, zooming and searching works fine (well, it's using openstreetmap.org for searching, so the results are pretty bad, but that's not the fault of this package).
This is the beauty of open data and open source in general. No one is forcing you to use the tools as intended. Want a map of all free bathrooms near a café as a markdown file? Knock yourself out! People will even help you do it.
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.
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.
Always fun to see cool things written for the big Lisp interpreter that poses as an editor.
When do those big performance improvements for Emacs Lisp ship?
When do those big performance improvements for Emacs Lisp ship?
nativecomp has already shipped. Is there anything more in the pipeline?
Shipped as in "merged to master" but Emacs 28 that will feature this has not been released yet, or am I wrong?
Release branch for Emacs 28 has been cut, but Emacs 28 has not been released yet, no. Emacs main branch is now 29.0.50 now.
You're right. I've read so much about it that I had stored it as "it's here" in my mind.
Thanks!
Thanks!
That looks so cool (but I didn’t install it). I regret after 30 years using Emacs that I have mostly moved in to VSCode. I toy with going back to Emacs but I have become addicted to tools like GitHub Copilot that saves me so much time that I can’t imagine not having it always running. Eventually Copilot support will come to Emacs.
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.
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.
Very nice. I looked before for some kind of graphics support in Emacs, but didn't find anything. I didn't know that Emacs could render and (I assume) interact with SVG. Apparently it's been in there for some time.
Great, another distraction to tap my time.
Great, another distraction to tap my time.
Yep. I also had a phase of "use Emacs for everything, literally" but I have it behind me. I now I use it as the editor. I use it to edit EvEryThIng.
This works great, in particular on the Purism Librem 5 :-)
[deleted]
RIP "Do one thing and do it well".
"The Unix philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978: Make each program do one thing well"
"The Unix philosophy is documented by Doug McIlroy in the Bell System Technical Journal from 1978: Make each program do one thing well"
But that's for individual programs in a larger system. Those of us who live in Emacs do follow the Unix philosophy at the granularity of individual applications inside Emacs or even individual Elisp functions.
This is like saying RIP "do one thing and do it well" because Osm.js has been written for Node.js. Osm.el is a program that does one thing well (view OpenStreetMap) for the Emacs runtime.
[deleted]
I'm flabbergasted at how snappy and intuitive it is!
[0] https://github.com/takaxp/org-tree-slide