Emacs should become a Wayland compositor
emacsconf.org
emacsconf.org
Wouldn’t be a bad idea at all to have the equivalent of modern Lisp Machine.
May as well go all in on that idea and make a name for yourself.
> What's the recommended treating regimen?
Implement!
The only way out is through.
The final goal is something akin to DOS, but the prompt is a Lisp that has access to the entire machine at full privileges and complete control over the hardware. I'm also exploring how to make it possible to rewrite the most core functions from the Lisp environment, so I could, for example, replace a naive "eval" function with native code after boot.
What can you build with the most minimal "operating system" paired the most meta-programmable environment? My dream is to add a simple display, keyboard and have this run on a RISC-V SoC, that simply boots with the prompt:
"> "
(I hate you for making me write this down and adding more fuel to the fire.)
Or just run Mezzano [1].
That said, Mezzano is cool and I should play with it more.
That's nice... but I think you're underestimating the amount of work to produce something you actually want to use:
> Yeah, that's my plan for the weekend. I'm currently working on a minimal Lisp implementation written in Rust,
> One of the questions I want to answer is what is the minimum amount of constructs you need to have complete control over your hardware, while able to rewrite the entire kernel at run time. I bet it's not that many.
You should take a look at both PreScheme (part of Scheme48) and Squeak. There's a lot of prior art you can look at without compromising your vision.
I'd also suggest you commit to a (modest) end state you want to achieve. I'm reminded that Linus Torvald's original motivation for Linux was to understand the multitasking hardware in the 80386. His first working development "kernel" ran two fixed tasks that printed something like A's and B's.
So you may be well served by starting with something minimal, but functional and building out as you have time. This also has the advantage that if you run out of steam for the work, you'll still be able to explicitly state you achieved an interesting goal. (As opposed to "Yeah, I started out building a bare metal Lisp, but got bogged down in the interereter and...")
Agreed: https://github.com/mschaef/vcsh
At least for hobby development, I find the fun/utility trade off to be a point of ongoing thought.
But it's worth spending more time with it, so thanks.
I haven’t tried it since moving to M1/ARM, but it is cool.
We have learned a great deal over decades about how to make languages that enable building reliable, expressive systems. Lisps can draw upon very little of that learning. Types can do heavy lifting, where put to work.
Instead of rebuilding something that was tried in the '70s, learn what they didn't know then, and apply it to something wholly new.
Types are cool, but are way overrated. Correctness isn't the only useful metric to optimise for. They are important if I am running a business and I don't want my crashing software to lose customers, but they are a hindrance if I just want to have fun and break things. Fun and productive businesses have been built on Lisp, BASIC and Python.
Languages aren't continuously getting better. They are on a cycle that repeats every 25 years. We've just entered another strong typing era.
Types, as I wrote above, can perform heavy lifting in a language that empowers them. New vistas await!
Level 1 junior programmer: who needs typing lol
Level 2 senior programmer: types are critical to ensure software runs as intended. You are here.
Level 3 greybeard: who needs typing lol, there is a time and place for them. I am here.
--
This is tongue-in-cheek, not meant to insult you. I get where you are coming from, but you are still giving too much importance to them. The subject matter here is me wanting to have fun, not writing medical software. Can I please have fun by writing a toy language that doesn't have a type system, or does that make me a noob?
Again: if you imagine types are only or even mainly for correctness, you have much to learn. You can start anytime you like. It will stretch your brain in new ways that are of no relevance to medical software.
Ironically, this comment reminds me of nothing more than the Smug Lisp Weenies of yore.
https://wiki.c2.com/?SmugLispWeenie
I realize that we're all about technical purity over marketing, but I don't think you'll convince people to join your cause by 1) insulting their knowledge and 2) dismissing their interest in an alternative point of view as a way to 'reclaim their youth'. You may be right on both counts - I don't know - but even for someone interested in the technology alone, it's hardly a convincing argument to want to look into more strongly typed languages. (or whatever other technical feature you might want to advocate)
Lisp received decades worth of attention and investment from folks at the frontier of the field, and it's stayed relegated to the margin for almost the entirety of that time. For people that took the time to learn Lisp, it could be a compelling and powerful environment. But the problem has been that to understand the advantages, you have to spend real time and effort to get there. You have to do the reading, do the work, write and evolve software, and accept a different way of working.
The strongly typed functional programming community of today has some of the same sorts of issues and Lisp did back in the day. It's a compelling technology with lots of benefits, but it takes real work to understand and take advantage of. For people that have done the work and already get it, it's an obviously compelling thing - the way things 'should be'. For people that don't, it's an academic ivory tower or worse.
Whatever you believe about your favored technology, it's the way this gap is addressed that will make the difference in whether or not it's successful or not. Lisp never did get it right. (Although Clojure arguably got pretty close.)
I don't mean to specifically offend your sensibilities with respect to your comment, but I can't help but think you're just repeating the same mistake the Lisp folks did. (And no, there isn't a technical distinction between Lisp and whatever that will fix what is fundamentally a marketing and persuasion issue.)
They even get the = register. Evaluates elisp instead of vim script, but what are you gonna do?
Celebrate? I like vim, but I don't think I've ever heard someone praise vimscript; even neovim added lua.
Trying to evaluate x + y and have vim insert the result is now (+ x y), which is more key-presses. It's a trivial, but slightly annoying in my common case.
Also throwing a bunch of things into an array and indexing into the result, then incrementing a number is more complicated as well (I usually run this in a macro to process a list of things), which is another ~15% of my usage.
There are a lot of things to complain about in vimscript, but infix operators and c-style array indexing has never been at the top of that list.
That being said, in the general case, elisp offers a really nice way to integrate with the editor. Far superior to classic vim-script. It just makes the = register slightly more annoying.
But, asking someone someone to maintain an entire language interpreter just to make the = register more familiar is kinda too much to expect of someone. At least the = register is there, I've never found another vim emulator that even has it.
Oh well, c'est la vie. Evil + slime/sly is still a better lisp experience than anything else I've tried.
Not enough to use it as PID1 on real hardware, but enough to be tempted to try it in a VM
You can put in a hypervisor (M-x start-virtual-machine) to run a bloated Linux distro so you can Firefox or Chrome (M-x start-virtual-machine-with-browser), but I'm sure somebody can streamline that even further.
Or do you mean the kernel itself?
And while reading that page I realised that I actually work with GNU, not even GNU/Linux, systems in production every day. Because I'm mostly working on applications deployed in clouds: the kernel is managed, and I'm not sure if AWS even promised that EKS runs on Linux and not something entirely else but very compatible. But GNU userspace is definitely there in my containers.
Suggesting using it as a compositor is sort of like suggesting sawing your own leg off. Makes no sense and is obviously a stupid idea.
FYI i daily drive emacs for everything and have probably written a million lines of code in it through the years, but I'm not gonna pretend it isn't janky as all hell.
I mean, it would work, but debatable how good it would be. The thing with X is that it lets you do more with the video device. Even better if you go the OpenGL way
(though ok, it is a bit of a corner-case optimization)
Surprised to find out the headline is 100% serious.
At some point I moved to a Mac because I realized that perfecting my window manager setup was just killing my productivity. I hope that one day I'll be able to get back to it – maybe when I retire.
Which is funny because macOS out of the box has some of the worst window management ever seen on any OS.
The thing I actually care about is navigating between windows by typing something that gets autocompleted. Spotlight or Alfred get me mostly there. In chrome I use Powerswitch to navigate between windows, and there's Cmd K for Slack. Having one interface for those would be grand, but I'm not holding my breath.
You're not holding it wrong, it's just a very primitive desktop environment. No snapping, poor external monitor support, defaults to magically moving desktops in relation to each other, etc.
If you want good window management right out the box, you won't get it from MacOS.
I'm still looking for an sxiv replacement, though.
By default, StumpWM lists normal buffers on C-x b, and X-windows using some other keybinding like C-t b
Hey, let's throw systemd in there while we're at it.
Anything to procrastinate on adding a good editor to it, right?
(But to be fair even a minimal Emacs is about 20MB RSS these days).
Back then mine was the "scary" machine in the workshop with its AMD Duron 700 and a whopping 512MB of RAM... and Emacs was just about usable on it!
He knew what he was doing.
From the documentation. I don't know why they didn't make it the same, but this is how it is, though maybe because M-butterfly is rather hard to press.
No, there aren't.
Have you tried literally every other text editor?
I switched from Vim. In Emacs, I can inline previews of LaTeX formulas in the same buffer as the one that I am editing. This is possible because Emacs has a GUI. Vim cannot do this because it runs in the terminal, and it also doesn’t seem possible to do this in gVim.
Meanwhile Emacs implements Vim’s modal editing through evil mode. So for this use case, Emacs seems to be strictly better than Vim.
I used Vim for 5 years, tried various different editors (Atom, Geany, Kate,...), and now for the past 4 years I've been using Emacs. And I'm liking it a lot more than Vim (though that may have something to do with my switching from typing QWERTY to Dvorak).
Hum... As an emacs user, I'm quite comfortable to disagree here.
When in an editor, you want to both type text and run code. Vi only messes up on the emphasis for both cases (due to the legacy of descending from ed), but even emacs has a "run code" mode.
Modal editing has ergonomic benefits similar to Sticky Keys, I don't see anything dated about it.
I'm not sure I agree writing is done the most either. Moving around is probably pretty high up there. It does depend on the file of course, but for config files or [video] playlist files you probably do more small edits and movements than writing of pure text. Writing email would be the other extreme.
I use swayWM and Emacs (with frames instead of windows) and configured sway to have Emacs-style key bindings. So I mimicked EXWM behavior without knowing about EXWM.
Right. That's why everybody uses popwin, amiright?