Readit NewsEDIT: Sorry, not SnapdragonX - apparently I can't read.
Also, who is "MetaComputing" and can I trust them with my money? Something about the big "Web 3 Integrated Devices" branding on their landing page makes me less than enthusiastic. Otherwise I'd be hovering over 'buy'
Foot feels fast, but I've not actually measured the latency. It also seems to use less CPU than GPU accelerated terminals (which it isn't) from just glancing at btop. So I'm not sold on GPU-acceleration as a feature unless I see benchmarks demonstrating the value in improved latency and reduced CPU use compared to foot
I love that foot's scrollback search, selection expansive, and copy can be entirely keyboard driven. Huge QoL feature for me that often seems neglected to me in other terminals.
And thats the thing. Neovim (vim) is about the unix way, use existing tools and use them from vim.
Last time i checked this was not an option in helix, and some very trivil things was impossible, like populating the quickfix (is it a thing n helix?) from a makefile command.
Bottom line is helix is basically a stipped down version on vscode, and wont really succeed without a plugin system (and when/if it lands, its basically just a vscode alternative)
Kakoune fully embraces the unix philosophy, even going so far as relying on OS (or terminal-multiplexer, e.g. kitty or tmux) for window management (via client/sever, so each kakoune instance can still share state like open buffers).
A comparison going into the differences (and embracing of the unix philosophy by kakoune) by someone who uses both kakoune and helix: https://phaazon.net/blog/more-hindsight-vim-helix-kakoune
Sensible defaults and easy setup are a big deal. No one wants to fiddle with setting up their lsp and tree-sitter. There's probably more to their differences in popularity than just this, though.
Cause -> cognitive disease Cause -> plaques
That is, that the same cause is behind both.
There may be some arrows from plaque to disease as well (i.e., that plaques also increase disease).
I dont know the truth, but just trying to understand/follow Alzheimers news and reading comments.
I use kakoune, because I like the client/server architecture for managing multiple windows, which helix can't do. The less configuring I do the better, but I've hardly done any in the past year. It's nice to have the option.
I do use kakoune-lsp and kak-tree-sitter.
If it were called std::has_copy_constructor, there would be no need to write even the title of this article, let alone the body.
Also, maybe this should require a diagnostic due to it being statically obvious that it is calling a deleted constructor:
Derived(Derived const& d) : Base<T>(d) {}
Clang:
#include <type_traits>
struct Base
{
// Default-constructible
Base() = default;
// Not copy-constructible
Base(Base const &) = delete;
};
struct Derived : Base
{
Derived() = default;
Derived(Derived const& d) : Base(d) { }
};
copy-constructor.cc:15:33: error: call to deleted constructor of 'Base'
15 | Derived(Derived const& d) : Base(d) { }
| ^ ~
copy-constructor.cc:9:5: note: 'Base' has been explicitly marked deleted here
9 | Base(Base const &) = delete;
| ^
1 error generated.
The only reason we don't get a diagnostic is that the language plays it loose with templates, in many cases deferring type checks until instantiation.
It is possible to argue that is_copy_constructible isn't necessarily badly named, but rather foiled by templates.
The problem with eager diagnostics and templates is that the program could define a `Base<int>` specialization that has a working copy constructor later. [0]
I think if you define an explicit instantiation definition, it should type check at that point and error. [1] I find myself sometimes defining explicit instantiations to make clangd useful (can also help avoid repeated instantiations if you use explicit declarations in other TUs).
[0] https://en.cppreference.com/w/cpp/language/template_speciali...
[1] https://en.cppreference.com/w/cpp/language/class_template.ht...
True and it would indeed be desirable that it were. Here I go out on a limb and assume it's because someone got bitten by attempting to use the loop index outside the loop (common for search operations) while declaring the index within and outside the loop. A bug (gcc and clang can warn about using -Wshadow, but which sadly isn't part of -Wall) which might easily occur when multiple people edit the code over a longer time-span.
Deleted Comment
So I use a "normal" floating environment (xfce, but could be another one), and I use Terminator in full screen enabled on a specific shortcut, so that I have tiled terminals.
I've been using niri (a tiling WM) recently. This is their very first design principle: https://github.com/YaLTeR/niri/wiki/Design-Principles Maybe other PaperWM-inspired WMs are similar. niri is the first I've used.
If your windows within a workspace are wider than your screen, you can scroll through them. You also have different workspaces like normal. I'll normally have 1 workspace with a bunch of terminals, and another for browsers and other apps (often another terminal I want to use at the same time as browsing, e.g. if I'm looking things up online).
This is an overstatement so gross that it can be considered false. On Skylake-X, for mixed workloads that only had a few AVX-512 instructions, a net performance loss could have happened. On Ice Lake and later this statement was not true in any way. For code like ChaCha20 it was not true even on Skylake-X.