This article is mostly about using emacs -nw which will depend on a bunch of things like how terminal input is handled! With regular Emacs, as a GUI, I typically split as well but I prefer vterm over M-x shell.
I usually use `emacsclient -nw` inside a terminal (sometimes over mosh). I've found eat[1] to be much a better than vterm at being a terminal emulator inside Emacs (inside a terminal). It flickers less, and seems to handle key forwarding a lot better. The only downside is it's slightly slower than vterm at handling a large chunk of data (e.g. cat an access log).
Sorry for the tangent: I was very eager to try vterm until I read that people have had issues with evil-mode [1]. Any idea whether eat and evil can get along?
It works somewhat more reliable (I've found vterm to break in some interesting ways depending on your cursor position even with evil-collection), but it's pretty awkward to use with evil, at least without any configuration.
For example, pressing 0 to go to beginning of line goes to before the $PS1, rather than the input beginning, going from NORMAL → INSERT inserts text at the end instead of at the cursor, Emacs motion keys doesn't work, etc. I think if I take some time to remap the key it might work, but usually I just switch to Emacs mode or just restrict myself to use only cursor key to navigate.
Glad you found it helpful! Most of it is distilled from High Performance Browser Networking (https://hpbn.co/). It’s a very well organised, easy to follow book. Highly recommended!
Unfortunately, it’s not updated to include QUIC and HTTP/3 so I had to piece together the info from various sources.
There's usually two pieces, a short one that can be taken as is for the general press and another which goes more in depth at a university level I would say.
I used to use org-mode with hugo but it got annoying, I didn't like how I needed to structure my org files, it kind of forced me into some structure. Now I use Zola with Markdown. I'm losing in power but it's so much simpler tbh.
Ink and Switch has been such a source of joy for me. I like reading their articles because they come from such a different place than what you currently see in most software (Cloud based subscriptions). Just a breath of fresh air backed by cool tech and cool people. Thanks!
I think being able to just create cross platform binaries + having good tooling out of the box as well. You can get started with go very easily and sharing programs as binaries just removes a whole lot of issues you'd have in other languages.
It’s a good first step, but a significant number of GitHub Actions pull a Docker image from a repository such as Docker Hub. In those cases, the GitHub Action being immutable wouldn’t prevent the downstream Docker image from being mutated.
I'm just so tired of writing bash scripts inside the YAML. I want to be able to lint and test whatever goes into my pipelines and actions. Not fight shitty DX on top of whatever Azure spits out when it fails.
This is entirely understandable, and entirely the fault of whoever thought bash scripts belong in configuration files. If you’re trying to stuff a tiger into a desk drawer, the natural consequences are hardly the fault of the desk drawer.
But it's the situation we're in now. It's what you see in the docs and what my colleagues write as well. I entirely agree that scripting into a markup language doesn't make sense yet the inertia is there and I wish there was some way out.
if you're writing bash inside of yaml then something has gone wrong well before yaml entered the picture, this is a problem with e.g. azure not with the yaml format
Can't tell if asked honestly. Because that's how most platforms handle their pipelines. Terraform or Bicep let you use a declarative language for your platform. Everything else is calling cli commands or scripts from pipelines, written in YAML.
Invariably, ppl will write inline scripts instead of actual scripts in their own files. There are also some SDKs for most of these operations that would let you do it in code but they are not always 100% the same as the CLI, some options are different, etc.
Yes, this is how Gitlab pipelines work. It's actually easier to just inline the script most of the time than have a bucket of misc scripts lying around. Especially since you have hooks like before/after_script which would be really awkward to externalize.
I mean, how else could to work? Beyond a new EU treaty (Lisbon treaty replacement) banning discussion of it, I'm not sure that there's any way to prevent it coming back.
Voting should be on specific clauses, and if anything is rejected there should be a cooling period before it can be brought up for voting again.
The cooling period does not preclude discussion of course. That's why we pay the MEPs: They are actually expected to show up in the EP and discuss. Not only show up on voting day and follow what their party dictated.
