mfontani

Why does signing up through Github require the "act on behalf" permission?

That seems risky.

Unfortunately many older mud servers (diku? Rom?) started with the wrong \\n\\r and codebases spawned from them just continued. Very few send the proper \\r\\n

Nice, limits for ipv6 are for a /64 and there's quite a lot of those in a /48...

That's great, but not "open source". The "Attribution-NonCommercial-ShareAlike 4.0 International" license isn't.

> Why do I, some random person installing this module, care if the tests pass now?

Because running those tests in your environment ensures that... that module can run in your environment.

By way of example, if a module requires a specific library installed to actually run, running its tests will ensure you catch the problem, and install it, so it can then actually run. Else you'd only find out at runtime that something's missing.

Note also that not all tests are the same, and (unfortunately!) not all modules' tests are the same, either: there's tests that ensure the module works "generally", and there's some author/development tests that on a _properly written_ module are only ran by the author/developer, and skip running when the modules are instead installed by mere users, for whom instead the "standard" "will this module work in this environment?" tests are the only one that get ran.

> I have horrible memories of the DBD::MySQL package failing to install because it ran tests that assumed localhost was running a MySQL server

I believe that got fixed, IIRC, as I've had no trouble installing that module (and running its tests at install time, natch). I said "fixed" as that seems like the sort of test that makes sense for the module's authors/developers to run, and not mere users of it.

That depends on "which version" of "Perl 7" you're saying, as IIRC there were various "factions" that had varying ideas about what ought to happen when "perl7" runs programs that didn't specify a "use v..." or that specified a specific "5.something" version.

I'm personally of the idea that enough backwards compatibility _should_ be preserved, but not _so_ much as to inhibit new/better syntax constructs and the like.

But honestly it's the sort of thing that is more like "I'll know it when I see it" more than anything.

Re "long term maintenance mode", there's the not so small matter of how many people can, in fact, actually develop perl. The codebase is large and full of many traps. It's a difficult, but not impossible, codebase to contribute to.

My sincere hope is that enough things will get out of "experimental", including quite a bit more of the "class" feature, for the end result to be enough to be called "7" and we'll go from there.

Basically... mostly a marketing thing, as today's 5.40 is way, way different (and better in so many respects) than 5.8 or 5.20 or even 5.32... but the (minor) version number doesn't show that.

A "perl 7" would.

Ctrl + [ instead of Esc gets one back into normal mode, with no delay Takes a while getting used to it (I still haven't)

> What's your reason to migrate from kitty to wezterm?

My reason to no longer using kitty is simple: I don't like having to copy kitty's terminfo data to every single system I connect to in order to have my terminal work.

It's fine for those few systems I very often connect to, of course.

But I also connect to ephemeral systems, sometimes for a short session, and the toil and friction inherent in having to do that just isn't worth it.

Sure, "kitty +kitten ssh ..." can work in most people's scenarios. Didn't quite work in mine, due to various intricacies about my ssh setup - multiple ssh keys, handled mostly by ssh-ident.

wezterm Just Worked for me. As I got "back" to also using other systems like Windows and MacOS, it Just Worked there, too. No fiddling with terminfo, no fiddling with $TERM, either.

Happy days.

I had a long battle with making kitty work with tmux. I settled on the following in ~/.tmux.conf, before moving to wezterm for good. Maybe it fixes things for you, too:

    set -g default-terminal xterm-256color
    set-option -sa terminal-overrides ',xterm-kitty:RGB'
    set-option -ga terminal-overrides ",xterm*:Tc:smcup@:rmcup@"
    set-option -ga terminal-overrides ",screen*:Tc:smcup@:rmcup@"
    set-option -ga terminal-overrides ",tmux*:Tc:smcup@:rmcup@"

I honestly don't know whether all are needed, or only some. But with these, it worked well for me.