thetic

these kinds of things are already possible (albeit without animation) with native features:

- https://neovim.io/doc/user/pi_paren.html - https://neovim.io/doc/user/lsp.html#lsp-highlight

I don't even think that's a controversial opinion. Breaking convention isn't inherently bad; it has costs, some of which you described. In this case specifically, the novelty is not justified by any significant benefit.

If only there were a way to indicate the function argument isn't mutated. </s>

My spidey senses tingle whenever I see const-ness cast away because it almost always means something is wrong. Either a function is missing a qualifier on an argument, or something very unsafe is happening. Why force callers to cast away const-ness in hopes that everything will be fine when you can just write the correct function signature.

The legal cases in which he needs to cast away const could be avoided if the arguments to called functions were appropriately qualified.

> #define sizeof(x) (size)sizeof(x)

Undefined behavior[1]

> #define assert(c) while (!(c)) __builtin_unreachable()

Undefined behavior[1]

> I’ll cast away the const if needed.

Undefined behavior[2]

> The assignments are separated by sequence points, giving them an explicit order.

I don't believe assignments are sequence points and only the function call is.

[1] https://en.cppreference.com/w/c/language/identifier#Reserved...

[2] https://en.cppreference.com/w/c/language/const

This is planned for the next release: https://github.com/neovim/neovim/issues/14790

- qutebrowser

- vifm

- ranger

- i3

- sway

- tmux

- zathura

- tig

Kitty does not run on Windows.

Sure. This may not be a feasible approach for this case. I'm just pointing out alternative approaches to mitigate this kind of scoping problem in C89. Maybe wrap every use of list_for_each_entry in braces?

    {
        list_for_each_entry(...)
    }

Though C89 does not support declaration of a scoped loop variable like C99 does:

    for(int i = 0; i < 10; i++) {
        // ...
    }

C89 does support declaration of variables at the top of braced blocks whose scope is limited to that block:

    {
        int i;
        for(i = 0; i < 10; i++) {
            // ...
        }
    }

Though limited, C++ does support default parameters: https://en.cppreference.com/w/cpp/language/default_arguments.

Wouldn't the header need to be explicitly listed as a dependency to prompt it's generation anyway?

> The bad news is that inference rules are not compatible with out-of-source builds. You’ll need to repeat the same commands for each rule as if inference rules didn’t exist. This is tedious for large projects, so you may want to have some sort of “configure” script, even if hand-written, to generate all this for you. This is essentially what CMake is all about. That, plus dependency management.

This isn't a case for CMake. It's a case against POSIX Make. The proposed "portability" and "robustness" of adherence to the POSIX standard are not worth hamstringing the tool. GNU Make is ubiquitous and is leaps and bounds ahead of pure Make.

This one tripped me up too. I'm guessing he meant `a |= b`.

On the subject of annoying ambiguities in mathematical notations, I would like to point out the ridiculous convention of inverse function notation.

Is there any sensible rationale for sin^(-1)(x) meaning arcsin(x) while sin^2(x) means (sin(x))^2?

I used Input Mono for quite a while, but the '8' and 'B' characters are too easy to confuse.

This sounds like visual mode.