• 8 Posts
  • 110 Comments
Joined 2 years ago
cake
Cake day: December 16th, 2024

help-circle


  • W is a double-v for us, so our alphabet goes uvw (u ve dobbel-ve), rather than uwv (ju dabbel-ju vi).

    Germanic languages vary a bit in their attitude towards w; we Norwegians use it pretty much just as a fancy old-timey v and could frankly drop w from our alphabet without missing anything (just like q is practically never used).

    Germans use w the way we use v, and then use v pretty much like f.

    The anglo w sound is something we have to learn in English class, and even then a lot of people start to hypercorrect and pronounce even the "v"s in English as their w. It can be wery funny to listen to, or wery frustrating.


  • Us nords have nine vowel letters:

    • a e i
    • o u y
    • æ ø å

    and they all are just themselves for a name. Like e isn’t “c with a line” any more than q is “o with a leg”.

    They’re also all monophthongs, which is hard to communicate to anglophones who pronounce their vowel letters overwhelmingly as diphthongs. E.g. anglos probably read the vowel letters as

    • ey i ay
    • åo ju way
    • ??? ??? ???

    There’s an æøå song which might help.














  • The stance coupled with the garish background colour reminds me of how Pike also had a very dismissive view of using colours for syntax highlighting, and then later opened up about having a kind of colourblindness.

    Both of them also seem to mean colour when they write syntax highlighting. That’s just one typographic tool among many. We also use bold, italics, underline, and even whitespace to highlight programming syntax. We could write a lot of programming languages as if they were prose, but we don’t. People hate that and call it “minified code”.

    Humans also have a great capacity for colour vision, much better than most mammals. Some of us are even tetrachromats. Our colour vision is basically a free channel of information: It’s always on; we don’t have to concentrate to be able to discern most colours. When things in nature are more colourful than usual, like leaves in fall or a colourful sunset, we don’t find it tiresome; we find it refreshing and seek it out. But when our built environment becomes all shades of grey, we tend to find it depressing.

    But humans are also different in many ways here. Better or worse colour vision is one thing, but some are also prone to getting overstimulated; others require more than average stimuli. We have great selective attention as a species, but again, individuals vary. There’s no one syntax highlighting that works for everyone.

    Ultimately we should just find some syntax highlighting that we find generally pleasant, and then stick with it until we reflexively use the information carried in those colours. Use habit formation for our benefit.

    Tonsky may enjoy his garish background colour and have found a mushy colourscheme that works for him, but he’s also way off base in his assessment of colourschemes in general.





  • fwiw if you do a cargo build you should be able to see the error messages in the correct context. If I replicate line 25 in a little test project and run cargo build I get

    error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
     --> src/main.rs:4:43
      |
    4 |     let guess: u32 = guess.trim().parse() {
      |                                           ^ expected one of `.`, `;`, `?`, `else`, or an operator
    
    error: could not compile `unacceptable-rs` (bin "unacceptable-rs") due to 1 previous error
    

    If I try this with a blank helix config I don’t get any of the text output from rust-analyzer at all, just the three dots indicating there’s a problem there, so it’s unlikely it’s a bad design choice on helix’s part.



  • Isn’t that just nitpicking?

    No, because the definitions are phrased very differently. Software doesn’t have to be copyleft to be considered FOSS either, as is the case with tons of BSD and MIT and whatnot code that’s used in proprietary programs—all they have to do is make it clear that they’re using their software (and even that’s not a given).

    Even with copyleft licenses like the GPL, as long as they never distribute their software to anyone they don’t have to offer them the source code either, as with so many backends. The AGPL gives consumers of distributed systems some more rights.

    Free software is mostly about providing you rights when you encounter the source code, meaning that you’re allowed to modify it and share it. This is as opposed to stuff like “source available” licenses that permit you to read the source code, but not modify or share it.


  • Such a license would neither be regarded as free software nor open source.

    Some other alternative could be making GPL-3.0-or-later + a Contributor License Agreement a more common option, so that it is possible to tell companies that if they want to use the library in some closed-source application, they need to work out a license deal.

    CLAs are frequently involved in turning software proprietary though, so it isn’t exactly held in the highest esteem in the FOSS community.

    And without a CLA you essentially get the Linux kernel situation, which will be stuck on GPL2 forever, since they can’t reasonably get everyone to agree to switch to GPL3, especially since some copyright holders are not just unwilling, but unreachable or dead (and in several jurisdictions copyright lasts for decades after death).

    Personally I suspect public funding, similar to science, education and libraries, is a more likely option, though that’ll be an uphill political struggle a lot of places.