if the screen is resized and the prompt no longer fits on one line the prompt is corrupted

[jtnord]

if the amount of text that can fit on a line is changed that causes the current prompt to reflow across multiple lines then the existing prompt gets corrupted and multiple items are repeated.

could be a clink issue also? clink version : 1.3.34.893e64 flexprompt 0.9

Can be reproduced by any way that changes how much text can fit on a line, e.g. zooming (changing font size in terminal or changing terminal window width.

video shows zooming as it is easier to capture

https://user-images.githubusercontent.com/494726/177745015-eff15105-dcc5-4c19-8570-36eb0ed806d1.mp4

[chrisant996]

Please share your flexprompt_autoconfig.lua file, and/or any Lua scripts that configure the prompt.

I don't experience that degree of mangling. The OS resizes the console asynchronously, which means it's impossible for any program to handle resize entirely correctly. But I've never seen the kind of explosion of text that your video shows. You may be right that flexprompt is accidentally appending content repeatedly. But I can't reproduce it, so it might be related to your specific prompt configuration.

[chrisant996]

I can reproduce it with a one-line prompt.

And it doesn't appear to be related to resizing. For example, if you press Up to cycle through history, the prompt keeps getting drawn one line lower than it should.

I can't tell yet if it's flexprompt at fault or Clink at fault.

[jtnord]

Please share your flexprompt_autoconfig.lua file, and/or any Lua scripts that configure the prompt.

https://github.com/jtnord/flex-prompts (as I have not updated to your main branch yet)

-- WARNING:  This file gets overwritten by the 'flexprompt configure' wizard!
--
-- If you want to make changes, consider copying the file to
-- 'flexprompt_config.lua' and editing that file instead.

flexprompt = flexprompt or {}
flexprompt.settings = flexprompt.settings or {}
flexprompt.settings.lines = "one"
flexprompt.settings.right_frame = "round"
flexprompt.settings.use_icons = true
flexprompt.settings.heads = "pointed"
flexprompt.settings.left_frame = "round"
flexprompt.settings.frame_color = "dark"
flexprompt.settings.flow = "concise"
flexprompt.settings.right_prompt = "{overtype}{exit}{duration}{time:format=%H:%M:%S}"
flexprompt.settings.spacing = "normal"
flexprompt.settings.powerline_font = true
flexprompt.settings.tails = "flat"
flexprompt.settings.use_8bit_color = true
flexprompt.settings.separators = "pointed"
flexprompt.settings.left_prompt = "{battery}{histlabel}{cwd}{k8s}{git}"
flexprompt.settings.style = "classic"
flexprompt.settings.charset = "unicode"
flexprompt.settings.symbols =
{
    prompt =
    {
        ">",
        winterminal = "❯",
    },
}

[chrisant996]

Well, my best guess so far is that it is flexprompt at fault.

Because:

• I made a prompt filter to write the resulting prompt string to a file after flexprompt built it.
• I made an alternative prompt filter that simply uses that pre-made string, instead of using flexprompt.
• The identical prompt string works fine outside of flexprompt, but runs amok inside of flexprompt.

But so far I don't see how flexprompt could be causing this. Still looking...

[chrisant996]

Looks like an issue in Clink: It's caused by the presence of a right-sided prompt string plus wrapping the prompt plus the prompt string changing when re-filtered -- or something like that, anyway -- the exact details are still slightly fuzzy, but once I make the initial prompt string be different from the re-filtered prompt string, then the problem reproduces.

The reason I couldn't reproduce it at first is because using a hard-coded prompt string caused the prompt string to not change when the prompt is re-filtered, and thus it doesn't re-display the prompt, and thus the cursor position doesn't get perturbed.

[jtnord]

@chrisant996 I am still seeing this with v1.3.40.1901c2 which contains ac3bd25e4cc2b93a2ef469af847a2720e5bb5236

[chrisant996]

@chrisant996 I am still seeing this with v1.3.40.1901c2 which contains ac3bd25e4cc2b93a2ef469af847a2720e5bb5236

Are you seeing the exact same behavior as in the video above? Or is it different than before? If it's different, can you share a video of the new behavior?

UPDATE: confirmed. Will look into it.

[chrisant996]

Oh, haha. The exact same problem happens in bash in Ubuntu in WSL in Windows Terminal.

Apparently the Readline library doesn't handle terminal resize very well.

Looks like I will have to write a custom resize handler, instead of relying on Readline's resize behavior.

But, on top of that, there is no way for a console mode application to fully reliably handle when the console is resized. If you resize quickly, then the console continues to change size while the console mode application is redrawing its output. And so the output naturally gets a little garbled while resizing. But the degree of garbling that's happening here is because Readline isn't handling resize correctly.

[chrisant996]

While investigating the terminal resize problems, I found many additional bugs in Readline's display code. The bugs are reproducible in bash in Ubuntu.

At this point, the costs associated with trying to fix Readline itself look significantly greater than writing fresh C++ code that takes advantage of Clink's native awareness of ANSI escape sequences and multibyte UTF8 characters.

It may take some time to complete that; it's tracked in issue 340 (linked above).