cultural reviewer and dabbler in stylistic premonitions

  • 50 Posts
  • 138 Comments
Joined 4 years ago
cake
Cake day: January 17th, 2022

help-circle







  • “But you can’t copy with Ctrl+C, it’s…” - You can. When something is selected It copies selection to clipboard, otherwise it sends SIGINT.

    What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected? In every one I’ve ever used, ctrl-c still sends SIGINT even with text selected (and one must must use ctrl-shift-C/ctrl-shift-V to copy/paste).

    I don’t have any suggestion for getting the behavior you’re asking for, but besides the normal ctrl-(shift)-C/V clipboard FYI you also have two other types of clipboard-like things: one which works anywhere (not only in the terminal) and is actually always automatically copying anything you select and lets you paste from it with middle click (this originated with X Windows but i think most Wayland compositors have also implemented it by now), and another which is found in GNU Readline (used by bash and numerous other REPLs) called the “kill buffer” which can be pasted (or “yanked”) from and cut (or “killed”) to using Emacs keyboard shortcuts (which also include various cursor movement controls).

    Notes:

    • the kill buffer is local to a given readline context, it’s not shared across different shell windows.
    • the list of emacs keybindings in that wikipedia article i linked is currently confusingly referring to the kill buffer as “the clipboard”
    • you can drastically reconfigure your readline keybindings and other behavior by editing your .inputrc file, but you cannot achieve what you were originally asking for because there is no concept of text selection in readline.

    HTH!














  • How exactly do they hope to lock devs in github??? That’s absurd, there’s no way they can achieve that. I can always take my projects elsewhere and there’s nothing they can do to stop me.

    I can’t tell if you’re joking? If not, what do you think “lock-in” actually means?

    It doesn’t mean that it is impossible to leave, it means that there is substantial switching cost. And, that is certainly the case for github-hosted projects: all active contributors need to make a new account somewhere else, issues and discussions need to be migrated, CI workflows typically need to be rewritten, and good luck finding something that gives as much free compute for CI as github does. Yes, it’s easy to mirror a git repo onto another service, but github is much much more than just git repo hosting and each of their features have their own switching cost.

    Also, OP actually said “lock devs in” rather than “lock projects in” - I actually am forced to have a github account if i want to contribute to projects which refuse to move their issues off of it 😢 … and the difficulty in creating new accounts anonymously these days prevents me from contributing to several things (lemmy, for instance) which i otherwise would.







  • fuck google generally, but in this case that mastodon post’s characterization that “Respondents overwhelmingly reject the suggestion” is not accurate - lots of people in that thread are in favor of removing it and those who aren’t aren’t making a strong case to keep it.

    imo client-side XSLT never needed to be implemented; afaict its primary use is styling RSS feeds and I doubt many people ever actually read RSS feeds styled that way even if millions of feeds are/were.

    some important context here

    tldr: This obscure “feature” is a significant source of vulnerabilities which attackers are able to compromise endpoints with right now. The GNOME project’s libxslt is used by all modern browsers and has been largely unmaintained for a long time, and it is a pretty sure bet that it has lots more remotely-exploitable bugs (in addition to those which have already been discovered and not yet fixed, or for which fixes are not yet widely distributed).

    it sounds like there is also a mostly-working JS replacement for this C++ code; if it is actually possible to ship that and avoid breaking any sites it would be preferable, but, otherwise, i for one would certainly be in favor of dropping browsers’ XSLT support (which was only ever for XSLT 1.0 anyway!) completely ASAP.