micro: DoEvent: Don't forward the resize event into the InfoBar

[JoeKar]

In case the InfoBar has an active prompt (e.g. Find, etc.) it shouldn't generally receive any event, because it isn't responsible for each. In case a resize event has been fired it needs to be processed by the tab handler instead.

Fixes #3033

[dmaluka]

Generally the InfoBar should receive the resize event. It should know when the width of a command bar changes, so that if there is a long text in the command bar, it should properly scroll this text horizontally. (Currently it doesn't scroll the command line at all, which is a big problem in itself.)

[JoeKar]

I agree, but then both handlers should receive the resize event and not just one and then react accordingly, because this...

...was a no-go too. 🤔

So let us treat this as a follow-up which then changes the logic at the same location again.

Wait..

...the resize-fix leads to the situation that the whole string can be displayed. So from my perspective the problem is only present in the moment the terminal stays small and the string becomes too long. At this point it should be shortened to the length of the x-axis beginning at the front with ... as placeholder. In the moment of resizing the terminal the reverse should take place.

[dmaluka]

I agree, but then both handlers should receive the resize event and not just one

Yes, that's exactly what I meant.

I've uploaded #3179

So from my perspective the problem is only present in the moment the terminal stays small and the string becomes too long. At this point it should be shortened to the length of the x-axis beginning at the front with ... as placeholder. In the moment of resizing the terminal the reverse should take place.

This (the fact that we don't draw ... or any other placeholder) may not be a huge issue. I'm talking about a more important issue: when the command bar is active (HasPrompt is true), it means that the command line is being edited, which means that we should display that part of the line where the cursor is (which is BTW most likely at the end of the line), while currently we always display the beginning of the line.

Well, this issue is already reported: #2527 so I don't need to explain it myself. :)

[dustdfg]

This (the fact that we don't draw ... or any other placeholder) may not be a huge issue. I'm talking about a more important issue: when the command bar is active (HasPrompt is true), it means that the command line is being edited, which means that we should display that part of the line where the cursor is (which is BTW most likely at the end of the line), while currently we always display the beginning of the line.

Well, this issue is already reported: #2527 so I don't need to explain it myself. :)

Hmmm what a shame... I didn't noticed it when played with multi line #3113

[JoeKar]

Hmmm what a shame...

I didn't realize this too. :(

@dmaluka is right and he already created the starting point. Now we've to add the necessary business logic into the resize event of the InfoBar. Thanks for keeping the overview, when I miss that.