Not as cursed as
print("eovdedn"[n%2::2])
Not as cursed as
print("eovdedn"[n%2::2])
I don’t fit into any of those categories.
Its obtuse, old, and doesn’t have a lot of functionality of modern code editors
Obtuse? Yeah. The keyboard focus means natural discoverability is low. But I immediately preferred modal editing once I learned it.
Old? Eh, most people use Neovim nowadays and write plugins in lua. Even in OG Vim, Vim9script broke compatibility for a better dev experience.
Functionality? Out of the box, it is just a text editor. But only VSCode might have a more active plugin ecosystem. ALE has been a thing for ages if it’s LSP support you’re looking for.
It’s not better, it’s not worse, I’m not in any way superior for using it, but I love it for a reason.
Same camp as wtype, you have to bind something to exec it.
autokey
I accomplish the same thing with compose sequences, and by binding a keyboard shortcut in my desktop to call a script with wtype
. It’s not a cross-compositor solution though, as you’d have to manually setup binds in each of them.
I don’t see much hope for this one-to-one unfortunately.
Relevant except below, bolded is the key point.
-v
prints non-printing characters in a visible representation. Making strange characters visible is a genuinely new function, for which no existing program is suitable. (sed -n l
, the closest standard possibility, aborts when given very long input lines, which are more likely to occur in files containing non-printing characters.) So isn’t it appropriate to add the-v
option tocat
to make strange characters visible when a file is printed?
The answer is “No.” Such a modification confuses what
cat
’s job is concatenating files with what it happens to do in a common special case showing a file on the terminal. A UNIX program should do one thing well, and leave unrelated tasks to other programs. cat’s job is to collect the data in files. Programs that collect data shouldn’t change the data; cat therefore shouldn’t transform its input.
xkb has been split off from Xorg, all Wayland compositors (that I know of) use it for mapping.
in the OP
My reply is to a commenter who said they prefer "${HOME}/docs"
over both options in the original image ("$HOME/docs"
or "$HOME"/docs
). Many people prefer to always include braces around the parameter name out of consistency, instead of only when they are required.
My comment explained why my habit is to only include braces when they are necessary.
It’s interesting, the results here are way different than the Code Golf & Coding Challenges Stack Exchange. I would never expect Haskell to be that low. But after looking at code.golf, I realize it’s because I/O on CG&CC is more relaxed. Most Haskell submissions are functions which return the solution.
Sidenote: I like the CG&CC method, it’s semi-competitive, semi-cooperative.
IMO It’s geared towards what is the best part about code golf: teaching people about algorithm design and language design.
My experience is still a good success rate there. Back in ~2015 my family got an USB WiFi card which needed an out-of-tree module, which the manufacturer had on Github, complete with DKMS instructions. It was upstreamed after about a year, though!
The only completely unsupported device I’ve had is my laptop’s fingerprint sensor.
I think this is a good default.
An impossible dream of mine would be to check a list of devices with haptic touchpads, and disable tap-to-click on those.
This has never stuck with me, and I hadn’t thought about why until now. I have two reasons why I will always write ${x}_$y.z
instead of ${x}_${y}.z
:
$x_
being expanded as ${x_}
."$#array[3]"
actually prints the length of the third item in array
, rather than (Bash:) the number of positional parameters, then the string 'array[3]'
.This isn’t true. Shellcheck doesn’t insist on braces unless it thinks you need them.
Typically find "$HOME/docs"
, but with a few caveats:
In Zsh or Fish, the quotes are unnecessary: find $HOME/docs
If I’m using anything potentially destructive: mv "${HOME:?}/bin" ...
Of course, if it’s followed by a valid identifier character, I’ll add braces: "${basename}_$num.txt"
Yep, I’m finding about half of my Reddit usage satisfied. I’ve got all the technical talk I want, but no gaming or writing communities.
I look forward to the day that Synapse is deprecated in favor of Dendrite or Conduit.
I’m pretty sure both are possible in xkb. But you’ll have to learn how to get a custom xkb_keymap into your DE of choice. I only learned enough to do one mapping:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols {
include "pc+us+inet(evdev)"
key {
type= "TWO_LEVEL",
symbols[Group1] = [ Multi_key, Caps_Lock ],
actions[Group1] = [ NoAction(), LockMods(modifiers=Lock) ]
};
key {[ Escape ]};
};
xkb_geometry { include "pc(pc105)" };
};
This remaps Capslock to Escape, Escape to Compose, and Shift+Escape to Capslock. Not what you want, but hopefully this will give you a starting point to playing/breaking xkb.
Another benefit of doing this with xkb: it’s now a separate codebase from X.org, and is used in every Wayland compositor I know of.
deleted by creator
My Linux review: 10/10, would recommend, but would not install for someone and let them use it for the next 5 years.
Excuse me, OCI container, we’re a runtime-agnostic family here.
Yeah, theres a lot of old old laptops which make no sense to run. But there’s a growing crop of more recent used devices that are only being sold off because they don’t support Windows 11, and the power efficiency story changes there. The OOP mentions “8.1 lappies”; my main laptop has a 15W 8th gen which is only in the last year starting to feel less appropriate for desktop use. (And honestly, a RAM and storage bump will probably get me another couple years.)
For environmental concerns, youve got to tax new devices with manufacturing costs as well.
100% agree about VMs though.