Skip to content

Conversation

@ArchWand
Copy link

This implements #2873. As per the discussion in the issue, this is unlikely to be merged; however, I would like to make the code available.

@ccjmne
Copy link
Contributor

ccjmne commented Jun 12, 2025

Thanks for sharing the changes you made to your own version of this tool, it's a valuable habit 👍

I am more in the camp of this not landing on master, for essentially one notable reason: $? still isn't 0 even after you Ctrl-L'd a few times—the last command that was run has errored out, still.

As far as I can tell, $? is the actual reference [1] [2] that is made available to us (and tools) to determine what happened with the most recently executed foreground pipeline.

I wouldn't mind too much either way, but I resort to just adopting the defaults if they're sane; and in this case, the "drift" that could occur between $? and the visual indicator exposed by p10k seems like it'd be inexact, however innocuous it may be: that simply clashes with the corresponding concept in the underlying tool, the shell interpreter.

In any case, I'm certain you're not the literal only one wanting this! [3]
Sharing the how-to is undoubtedly healthy, I just meant to accompany it with a little why-you-might-not-want-to.

Cheers!

[1] https://www.gnu.org/software/bash/manual/html_node/Exit-Status.html
[2] Well, $? isn't the end of the story: I am fond of $pipestatus (Bash: ${PIPESTATUS[@]}) as well :)
[3] Although I suspect that appreciating the rigorous, methodical "just-expose-the-reference" might change your perspective.

@romkatv
Copy link
Owner

romkatv commented Jun 12, 2025

Thanks, @ccjmne. I couldn't have described it any better.

@ArchWand
Copy link
Author

Thanks for the feedback! I'm relatively green at software and especially at contributing, so this is super helpful!

I'm aware of that issue, and it's exactly how I want the prompt to behave; while I don't want the prompt to show the visuals, I note mentally that the last command errored as needed.

The state drift does seem like it could lead to weird edge cases; the main issue I can think of is that other modules might also depend on the status, which this would screw with. However, for my use-case I think this would actually be a benefit, making error-related information only show once. That does mean the param name is a bit inaccurate, since it affects more than just the status. There's definitely an argument for not leaving footguns lying around tho.

One way to fix this discrepancy would be the "magic enter" solution in the linked stack overflow in the linked issue; I personally would not like this as it loses the previous error code (at that point, shy not make enter equivalent to ctrl+l?). Either way, that would be outside the scope of powerlevel10k.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants