Hacker News new | past | comments | ask | show | jobs | submit | thetic's comments login

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.


> #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


>> I’ll cast away the const if needed.

> Undefined behavior[2]

How so? As the page you linked mentions, simply casting 'const T *' to regular 'T *' is well-defined; it's only modifying a const object through the pointer that's UB (C17 6.7.3/7).

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

Assigments within expressions don't create sequence points. However, the expression of an expression statement is a full expression (i.e., not a subexpression of another expression), and there is a sequence point between each pair of full expressions (C17 6.8/4). In other words, the semicolons create sequence points.


> > I’ll cast away the const if needed.

> Undefined behavior[2]

To be clear, it's only UB if the object was defined const, which is the case given he wrote:

> One small exception: I still like it as a hint to place static tables in read-only memory closer to the code. I’ll cast away the const if needed.

So you are correct on this point. Funnily enough, such objects are relatively rare IME, so I had to double-check to see that he was advocating it specifically in the rare case where it must not be applied.


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

And people keep telling me that nobody uses the C preprocessor to define their own syntax any more!


> Undefined behavior[2]

Given that this particular undefined behavior usually causes crashes in practice, I expect the author is talking about casting away the const but not actually writing to the pointer. Which is legal.


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


He never said he needs to cast away const to do what he is attempting to do, he just said that he wants to cast away const to reduce clutter, even though the program would have the same semantics as if he kept the const.


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.


Or a common situation is mutable -> const -> mutable.

And that is legal.


https://github.com/python-poetry/roadmap/issues/3


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


- qutebrowser

- vifm

- ranger

- i3

- sway

- tmux

- zathura

- tig


Vifm looks really interesting, and admittedly I haven't tried ranger. Will give them a go, thanks!

The others are all very fine pieces of software I all use but imo not nearly on the same level. They're essentially programs with fancy keyshortcuts.


You should also check out nnn (https://github.com/jarun/nnn) if you're looking for terminal-based file manager.


IIRC the golden standard is midnight commander ( https://midnight-commander.org/ ), which is another old timer. I wonder how nnn and vifm compare to mc.


Kitty does not run on Windows.


I think the confusion is due to the putty fork that's also called kitty.

wezterm is actually cross-platform and has great support for wsl2 as well. It also comes with a mux component which moves the mux stuff to your local machine and eliminating a lot of issues with running tmux/screen.

I looked into alacritty and kitty as well. Aside from being the best terminal for my needs, wezterm's developer is also pretty friendly and open to issues/PRs and is very responsive. I like the tool and the project so much that I help out with little things like packaging whenever I can.


Thanks for this reminder, I had peeked at wezterm a month or so ago and it sounded slick, but I was pretty happy with my iTerm+tmux setup. Just got a chance to play with wezterm a bit, and I think it's going to be my new term, because:

  - The ssh mux seems to work at least as well as mosh+tmux.
  - It has decent keyboard Copy/QuickSelect/Search (I liked tmuxes, but didn't get that at my native terminal).
  - Runs on MacOS and Linux, my work and home environments.


Yes wez's mux is pretty nice. It will probably get better too. I think it has some mosh-like functionality too. I like that my terminal behaves the same locally and running as muxed domain on a remote server. One less set of shortcuts to remember. If it's not clean I mean for operations like copy/paste yes, but also starting a new tab (which will open a tab in that domain), splitting the current view etc.


Wezterm (kitty too) is really a great piece of software, I use terminals 12 hours a day, but I did not spent a lot of time configure them, but this article is inspirational.

PS: kitty developer is the same developer of calibre, another beautiful software.


> wezterm's developer is also pretty friendly and open to issues/PRs and is very responsive.

Really? His attitude in the issues page was the main reason I left wezterm for alternatives.


Can you provide an example? I would be very suprised if we're talking about the same guy.


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++) {
            // ...
        }
    }


That extra scope is an issue for what they're doing, however. They have a macro called "list_for_each_entry()" which syntactically behaves as if it were a "for(...)" (because it is a "for(...)"). To make the extra scope work with that macro, either the user of the macro would have to end the loop with an unbalanced amount of closing braces (to match an extra opening brace within the macro), or it would require a second macro to be used at the end of the scope. Keep in mind that this macro is used in literally thousands of files within the kernel.


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(...)
    }


Then you get dinged by static analysis tools like SonarQube because you introduced a useless scope or increased the "cognitive complexity" to the code and have to explain it to a team leader who might not understand why you did that.


A team lead who does not understand that does not have the technical chops to be a team lead.


Doesn’t mean they aren’t still your team lead though!


Should we really be making decisions with people like that in mind?


If they are your team lead, would you have a choice?


I guess don't use a C99 linter on a C89 codebase?


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


sorry, I meant named parameters


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


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: