oh-my-posh: Incompatible ANSI escape sequence at the end

@rashil2000 can you confirm that the original issue as described 40 is now gone?

Yes, no error bell now!

Thanks!

"console_title": false ìn the general settings of the json config file.

oh-my-posh takes around 2 to 3 seconds to run on Windows

@chrisant996 that’s definitely not normal. It runs below a second on my machines (and also confirmed by others). The only time this occurred, it disappeared after a reboot of the user, and as far as I know hasn’t returned just yet.

Stopwatch says it’s around 1 second. I guess it feels like 3 seconds because Lua scripts in Clink can do the same work (including git enhancements) in around 1/4 second, but that’s to be expected since they don’t have to load a large binary or initialize internal runtime frameworks, etc.

Redundant ANSI escape sequences have been taken out by @lnu, which hopefully makes things a bit more efficient.

Cool, sounds great.

It sounds like all of the issues are well understood, so at this point I think there’s no need for me to collect/upload additional information.

Ok, so, I just reread the entire thread in 39 and see the mention of the bell and indeed that’s because of setting the title. Setting console_title to false will resolve that.

True, I checked starship and it shows less informations(at least by default) than omp.

I think this misses the point. Starship is, for most purposes, not a ready-to-go prompt utility; it shows very few things by default and needs a configuration file. I have uploaded my starship.toml here for reference.

I did not take the time to configure it extensively. Thanks for your config.

@lnu I’m going to create a POC to see if we can delegate the syscalls to a Rust lib. It’s perfectly possible and it could solve the issue entirely. See this repo for example.

It causes a functional issue in Clink, and should cause exactly the same functional issue in Bash, since both use the GNU Readline library which is the component affected by the oh-my-posh issue.

The CSI K escape code near the end of the prompt string can, under certain circumstances, accidentally erase the input text from the screen. Readline doesn’t expect anything else to be printing over its output, and for performance reasons it’s important not to print over or erase Readline’s output. But the CSI K escape code does.

The linked issue 40 has repro steps for one example scenario. Many other scenarios exist.