38 karma · joined July 23, 2014
(these are not necessarily the same issues, but at least similar-sounding ones I found by googling)
• widgets opening in wrong place: https://bugs.kde.org/show_bug.cgi?id=459188
• ignoring icon size configurations: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i..., closed as wontfix
• on touchscreen menus open wherever you left the cursor: https://bugs.kde.org/show_bug.cgi?id=406025, more info in https://github.com/PeterCxy/evdev-right-click-emulation/issu...
• cursor framerate issues: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1827 maybe, it's in the gnome issue tracker but described as wayland-specific, so might also be happening on KDE
• firefox using wrong screen's DPI: https://bugzilla.mozilla.org/show_bug.cgi?id=1632829, resolved by original reporter but last comment is a repro from someone else. also reported in https://github.com/flatpak/flatpak/issues/5300 but closed as "wrong bug tracker"
• fullscreening a video rotates it from portrait to landscape: https://bugzilla.mozilla.org/show_bug.cgi?id=1600962 possibly, https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/190522... possibly
In general wayland seems too buggy for major software like firefox to use it by default, per https://askubuntu.com/questions/1409389/why-doesnt-firefox-r...
Impressive list to hit in only 5 minutes!
I suspect there is room here for an unprincipled "preceding word/pattern is defined by the following line/s" loose-binding operator, to restore skimability, and a separate inline destructuring let form that cannot leak out of lexical scope. Which I suppose would warrant lambdas - perhaps with ⍺ ⍺⍺ ⍺⍺⍺ to denote enclosing function input, rather than argument/operand/hyperand, though nonconcrete functions would stress the type system as is
Oh man, that is a fascinating idea I've played around with some, glad someone's put it more seriously into practice.
Re: assignments, Aaron sure seems to sprinkle them liberally inside lines - though not generally ones referenced in subsequent ones, to be fair. (I suppose another notable attribute of the co-dfns codebase is extensive use of ⊣ as a leftwards statement separator)
Mathematical functions are prefix, which imo is much harder to follow than either infix (OO/APL) or suffix (RPN/Forth), though this may be more of an english-speaking intuition than some manner of universal truth. I do at least observe a trend towards "imperative but functionally pure / side-effect isolated" in recent language design.
Naively I would expect that to be part of the rendered DOM("<a prevent-default='click'>"), or otherwise in a declarative datastructure available to the UI thread. Are there many events that need conditional preventDefault, such that the JS handling code would grow nontrivial?
For me this was most poignantly demonstrated by https://chrisdone.com/z/
const jwt = require('jonwebtoken') Instead of thousands of debugger options, let's have a magic tool where you click on the thing that's going wrong.
There are reasons for the thousands of options though! Like, "debug this specific object" or "breakpoint when this condition is satisfied" exist as primitives already; there's more complexity there than just "what is the data backing this UI element". If Eve has indeed managed to get away from needing them, that is laudable, but it would be achieved by the full set of things you might want to do being blindingly obvious, not "magic" special-cases for "I was expecting something here and I don't see it" ((lambda (src)
(cons (cons (quote lambda)
(cons (quote (src))
src)
(cons (quote quote)
src)
(quote
(cons (cons (quote lambda)
(cons (quote (src))
src)
(cons (quote quote)
src)
) it solves a lot of the problems that CoffeeScript is trying to solve without drastic syntax changes.
I cannot speak to authorial intent, but for me the majority of the problems CoffeeScript(and moreso LiveScript) solves are syntax ones.