Prot is one of those contributors who has made his contributions accessible in the form of videos, tutorials, blogs, and other documentation. As far as I know, he's not contributing to the Emacs internals and instead providing packages, he has given most of his code to be part of GNU. I came across his work on modus-themes and understood from his documentation that he's done a lot of research in making it compliant to accessibility standards of WCAG AAA. This theme is going to be bundled with the next stable release of Emacs 28 when it comes.
One can truly see his journey in contributing to free software, including philosophy, documented in his videos. Congratulations Prot.
(defun modus-themes-wcag-formula (hex)
"Get WCAG value of color value HEX.
The value is defined in hexadecimal RGB notation, such as those in
`modus-themes-operandi-colors' and `modus-themes-vivendi-colors'."
(cl-loop for k in '(0.2126 0.7152 0.0722)
for x in (color-name-to-rgb hex)
sum (* k (if (<= x 0.03928)
(/ x 12.92)
(expt (/ (+ x 0.055) 1.055) 2.4)))))
Sounds like a prize well deserved! Stuff like this has traditionally been a blind spot in Free software. Glad to hear we're getting a more beautiful and accessible Emacs.
Prot videos are the best. He does a wonderful job of presenting a topic, covering the information thoroughly, and stays on topic. All without acting like a typical youtuber. He doesn't ask for likes or subscribes, doesn't have ads, doesn't have chat, he isn't a slave to patronage, and best of all he doesn't use that hyping style that many youtubers use today.
I wish more technical youtubers would go back to presenting like Prot.
I do sympathize with them though if they decide to put in ads, endorsements, solicit for likes and subscribers because from what I hear putting out high quality videos requires a lot of investment that needs to be compensated in one way or another. YouTube itself incentivizes churning out new content frequently.
Perhaps it's the infrastructure that's broken. Something like the approach that Brave browser implemented could make the above less necessary, where a viewer has a wallet with funds which get distributed to the various the producers proportionally to time spent on their content.
Prot is one of the most well spoken, humble, deliberate and wholesome people I've ever come across. Absolutely crazy to think that he came to Emacs and Lisp without any technical background and just started contributing.
I'm not quite sure what you mean by disentangling it from GTK. I can tell you that a major selling point of the 29 release is that the GUI is more entangled with GTK. Specifically, by removing all X11 code and using only GTK, Wayland will have native support, instead of requiring an additional X server as a shim between the two.
All attempts to use guile were never completed , and the resulting prototypes were always slower, mostly because of impedance mismatches between guile and elisp. As reported by the sibling comment, native-comp was merged and it makes the existing elisp code faster while being fully compatible. It was a major achievement, done in a relatively short time by a single contributor!
It means that elisp is here to stay with all its quirk, but as we all know, worse is always better (which is ironic when comparing lisps :) ).
"the resulting prototypes were always slower, mostly because of impedance mismatches between guile and elisp"
That may be technically true, but I think the real problem is that there was only one guy working on the project.
A lot more progress would probably have been made if there was a team of people working on it, but apparently it's just not important enough for most Emacs users. Some would like to see it happen, but not enough to actually contribute to the effort to make it so.
I'm not disagreeing with you, but this is kind of a moot point since the main selling point of Guile was always performance. AFAIK it was never the plan to actually make Emacs use Scheme rather than Elisp---the semantics of the languages just aren't compatible, and it would require throwing away too much of the existing Elisp ecosystem.^[1] Rather, the idea was to modify the better-performing Guile interpreter so that it could evaluate Elisp with the end goal being better performance.
Since the performance wins for native compilation exceed what people had hoped for with Guile Emacs, whether or not Guile Emacs was feasible isn't really that important.
[1] Furthermore: the biggest wart in Elisp compared to modern Lisps like Scheme is that it uses dynamic binding by default. But pretty much everything in Emacs (including third-party packages) declares lexical binding now (which is required for native compilation anyway), and the use of cl-lib nowadays is fairly ubiquitous, so a lot of the arguments about Elisp not being as "nice" as other modern Lisps aren't as compelling as they used to be 15 years ago.
"the main selling point of Guile was always performance"
I don't agree with this. For Emacs users like myself, Guile is just a way more elegant and powerful language than eLisp (and also preferable to Common Lisp, which is a lot more antiquated and clunky compared to Scheme). I would have written all my Emacs code in Guile (or any other modern Scheme) if I could.
If Guile Emacs could equal the performance of regular Emacs (or even a little slower) while allowing all existing eLisp packages to run, then I'd switch in a heartbeat. It needn't have offered better performance than regular Emacs to win me over.
In fact it was Guile Emacs exactly. What that entailed was both the ability of the Guile VM to run eLisp so that all existing eLisp packages would run on the Guile VM without modification and that Emacs users could write in Guile (or any other language that the Guile VM supported) instead of eLisp if they chose.
The big selling point was that no eLisp packages would have to be rewritten in Guile, but that wouldn't stop new packages and other code to be written in Guile if users chose. Both of these were essential for users like myself who actually prefer to write their own code in Scheme, but realize that rewriting all existing packages in it is an unrealistic goal.
That's interesting and I guess it would have worked. Unfortunately the reality is that nobody assign people to tasks in purely community driven open source projects like emacs. People do the task they are interested in.
At this point I guess it is more likely for elisp to slowly mutate into CL than emacs getting scheme support.
I know very little of the lisp ecosystem (I barely can write some elisp) so I don't know what are the pros and cons of scheme vs CL.
As far as as I can tell, there aren't a huge amount of contributors to the core emacs team in the first place. Still the native-comp was implemented by one person.
That means that native-comp was probably easier than well-performing Guile Emacs. I'm not disputing that, just pointing out that performant Guile Emacs could have probably been done if enough people contributed rather than leaving it to one person.
My not very well-informed take on the situation is: Yes, Emacs seems to make a lot of progress in many directions. Latest git master does have elisp native compilation support (via libgccjit). Various elisp semantics have been modernized (support for common-lisp style lexical closures).
Still it is rather lightweight (compared with, say firefox), you can download upstream source and compile&install it in minutes rather than hours.
Yeah, the dude looks exactly the archetypical way. I would imagine he codes Lisp, develops Emacs and has something to do with the FSF immediately after a single look at him :-)
One can truly see his journey in contributing to free software, including philosophy, documented in his videos. Congratulations Prot.