Dynamic display of `InfoBar` messages

[past-gen]

Description

Personally, I find the info bar mostly an eyesore. Either it's spams with generic actions logging, taking up space unnecessarily, or it keeps displaying that stale latest message even when it's no longer relevant. And for this reason, I prefer to keep it hidden.

However, sometimes seeing a single timely warning can become a real life timesaver, and there's no way around it. Yet.

Thus, I'd like to suggest an alternative approach, or rather optional improvements to the current one, since not everyone may agree with me on this:

• Desired behavior:

  wezterm-gui_ya7cygKM7Z.mp4

• Desired implementation (names are merely placeholders):

  • infobell: option sets the minimal level of verbosity (Message, Warning, Error, Plugin etc.) that triggers the display of the InfoBar
  • infobell.timeout: how long to display InfoBar in ms; renew the timer if currently shown and/or the message's being updated
  • infobell: "" or infobell.timeout: 0 means keep it hidden unconditionally
  • only relevant when infobar: false
  • ? inherit the behavior pattern of the prompt where it overlaps the status bar instead of toggling the info panel every time, as long as the prompt still has the higher priority
  • ...

[dmaluka]

That can be easily addressed in Lua? E.g. something like:

function onAnyEvent()
    config.SetGlobalOptionNative("infobar", micro.InfoBar().HasError)
end

[past-gen]

• onAnyEvent(): runs when literally anything happens.

@dmaluka While it technically can, I don't think it really should.

If I understand correctly, this callback should only be used for debugging purposes, as the overhead would be enormous.
Or perhaps in situations where it is necessary to monitor every action possible in order for the logic to work properly. And this is not such a case.

Either that, or I have misinterpreted what literally anything happens means, and the impact on performance would be negligible?

[Andriamanitra]

As long as you don't do anything crazy in the callback it should be fine. Events typically only happen as a response to user input so they're pretty rare on the timescale of a computer. Just try it out and see if you notice a performance impact.

[Neko-Box-Coder]

If I understand correctly, this callback should only be used for debugging purposes, as the overhead would be enormous.

No, it is not. In the sense that you won't be able to tell the difference. Anything that returns immediately (for the most part) is fine to put in onAnyEvent(). Is it efficient? No, but it works.

micro doesn't really have a concept of timer since micro only refreshes on user input/action so onAnyEvent() would pretty much be your only choice.

[past-gen]

Is it efficient? No, but it works.

Exactly.

so onAnyEvent() would pretty much be your only choice.

Mine? Maybe. But why?

Why implement some crippled third-party wrapper with O(n) complexity for monitoring/processing every user action, when Micro can handle it internally in a reactive manner with O(1), just by performing all the necessary manipulations on the InfoBar message update?

...

micro doesn't really have a concept of timer

• After(t time.Duration, f func()): run function f in the background after time t elapses.

What's this then? It may not be the Timer timer, but should suffice, I think.

Let's say we extend InfoBuf struct with a HasTimer and TimeOut variables first, then:

1. every time a message's shown, given that infobell status being positive and conditions are met, TimeOut is incremented by infobell.timeout
2. (recursive)? After function initialized, unless HasTimer, with a callback that decrements TimeOut by the very same infobell.timeout, HasTimer updated
3. hide the InfoPane and exits the loop when TimeOut <= 0, HasTimer updated

Sounds easy enough, and way more performant, at least in theory...

---

Events typically only happen as a response to user input

In a text editor... where "user input" is that only thing that is preformed constantly... and matters... and should be most optimized-est-est thing of them all? They're just synchronously "happen", like in sequnce? Did I get that right?

Not sounds too reassuring, If I'm honest...

Just try it out and see if you notice a performance impact.

It is enough that I have three different usage experiences just from running raw Micro (or any other TUI app for that matter) within WezTerm, Conhost or Alacritty (which sucks ass on Windows, btw; while being most responsive of all, ironic).

From my personal perspective, Micro isn't being nearly as responsive as SublimeText is, for example. So, unless it's proven impossible otherwise, I'd rather not make any unnecessary changes that might affect it even more.

We also shouldn't forget that, however performant the app itself may be, it will always be restricted by the environment it runs in (e.g. a terminal emulator) while it remaining what it is, a TUI app.

That being said, I believe any opportunity for optimisation should be pursued, even the tiniest one.

[dmaluka]

when Micro can handle it internally in a reactive manner with O(1), just by performing all the necessary manipulations on the InfoBar message update?

That's exactly what onAnyEvent already does: it doesn't iterate anything, it just reacts to an event.

You may look into the code to see how it works: https://github.com/micro-editor/micro/blob/master/cmd/micro/micro.go#L546

From my personal perspective, Micro isn't being nearly as responsive as SublimeText is, for example.

Yes, there is a huge room for optimization in some parts of micro (around screen drawing, syntax highlighting etc). For example, see the discussion in #2970. You are welcome to improve that. But those parts have nothing to do with micro's event loop, in particular with onAnyEvent.

[past-gen]

You are welcome to improve that

I would, if I could. Sadly, nor do I have enough programming experience, or knowledge of the Go lang specifically, to actually improve something. Look for me when you need to break something perfectly working, eh.

Doesn't mean I can't see flaws in your logic, though. Thus:

That's exactly what onAnyEvent already does: it doesn't iterate anything, it just reacts to an event.

My opinion remains unchanged; onAnyEvent is literally being a part of an infinite loop for { DoEvent() }.

Just to make it absolutely clear, I am not talking about its execution pattern, as it doesn't really matter here, but rather point your attention at the amount of actions that will potentially have to be processed by that callback, as you advise, before it is actually justified.

There might be one, or there might be a thousand. What, are you saying that we should process 'em all just for the sake of it, when this can be done exactly once, at the exact appropriate moment, you know, when the notification is actually being updated, by the mechanism responsible for that exact task?

This is the dumbest most counterproductive thing I've seen this week, and I can literally see myself in a mirror right now.

[dmaluka]

I am not talking about its execution pattern, as it doesn't really matter here, but rather point your attention at the amount of actions that will potentially have to be processed by that callback

Sure, it is completely up to you what exactly you implement inside your onAnyEvent callback. In my above example, for example, it is just one config.SetGlobalOptionNative() call. If for some reason you think that calling it every time is gonna be expensive, you could "optimize" it, for example, by using a global variable, comparing it with micro.InfoBar().HasError every time, and only calling config.SetGlobalOptionNative() if it changed. That would be exactly what you want: enabling or disabling the infobar "exactly once, at the exact appropriate moment, you know, when the notification is actually being updated, by the mechanism responsible for that exact task".

[past-gen]

Look... would you prefer holding your dick only when you piss and/or beat your meat, or also when brushing your teeth, making yourself a sandwich, or kiss your kids goodnight? Even if it's just through your trousers?

I understand what you're saying, really, but it isn't about expenses, it's about the architecture. When we have an InfoBar instance already, that is responsible, it IS only a sane approach to extend it with features related to how info's being delivered to the user and handled afterwards. As it potentially could be useful elsewhere later on, for example.

There should never be a debate about that.

That would be exactly what you want: ...

Again, it is not. A hypothetical thousands of micro.InfoBar().HasError calls and corresponding condition checks should be performed for no reason.

Is it efficient? No, but it works.

[dmaluka]

When we have an InfoBar instance already, that is responsible, it IS only a sane approach to extend it with features related to how info's being delivered to the user and handled afterwards.

We cannot extend micro's core with every possible feature in the world. It costs size, complexity, maintainability, comprehensibility of the documentation by end users, etc. Which is why we have plugins.

[past-gen]

@dmaluka ...that I can understand, and even accept, albeit unwillingly.

If the approach I've proposed wouldn't resonate with others, or maintenance cost dimed unbearable, could I at least count on introduction of a more considerate OnNotification/OnInfoBarUpdate handler, that'd target notifications specifically?

That'd serve as an acceptable compromise of sorts.

[dmaluka]

It just isn't very clear to me what real practical problem that would solve. I.e. a compromise between what and what exactly?

[past-gen]

It just isn't very clear to me what real practical problem that would solve. I.e. a compromise between what and what exactly?

• Look... would you prefer holding your dick only when you piss and/or beat your meat, or also when brushing your teeth, making yourself a sandwich, or kiss your kids goodnight? Even if it's just through your trousers?

• the amount of actions that will potentially have to be processed by that callback, as you advise, before it is actually justified.

• A hypothetical thousands of micro.InfoBar().HasError calls and corresponding condition checks should be performed for no reason.

• We cannot extend micro's core with every possible feature in the world ... Which is why we have plugins.

Instead, just once per message, as any sane person would do it:

...

// Message sends a message to the user
func (i *InfoBuf) Message(msg ...any) {
	// only display a new message if there isn't an active prompt
	// this is to prevent overwriting an existing prompt to the user
	if !i.HasPrompt {
		displayMessage := fmt.Sprint(msg...)
		// if there is no active prompt then style and display the message as normal
		i.Msg = displayMessage
		i.HasMessage, i.HasError = true, false

        SomeKindOfLinkToCallbackDefinedByUserInPluginToRunOnEveryMessageUpdate(i) <----------------------
	}
}

...

// Error sends an error message to the user
func (i *InfoBuf) Error(msg ...any) {
	// only display a new message if there isn't an active prompt
	// this is to prevent overwriting an existing prompt to the user
	if !i.HasPrompt {
		// if there is no active prompt then style and display the message as normal
		i.Msg = fmt.Sprint(msg...)
		i.HasMessage, i.HasError = false, true

        SomeKindOfLinkToCallbackDefinedByUserInPluginToRunOnEveryMessageUpdate(i) <----------------------
	}
	// TODO: add to log?
}

...