Timer callback in lua plugins can't refresh the screen

[X-Ryl669]

Description of the problem or steps to reproduce

In a plugin, add this code:

local time = import("time")

-- somewhere in init function
time.AfterFunc(time.ParseDuration("2s"), function()
  micro.InfoBar():Message("I'm alive")
end)

After 2s, the info bar is modified, but it's not visible, until you move the cursor or press a key.
This is likely due to the callback function being called out of the usual drawing code (thread?), so the screen.Redraw() in the InfoBar:Message is lost.

Ideally, it could be solved in go so the lua code doesn't have to deal with this or a new command could be added to force refreshing the screen from the main ui thread and we would have to call this from lua.

I don't know about the internal of micro enough to fix it.

[JoeKar]

This is likely due to the callback function being called out of the usual drawing code (thread?), so the screen.Redraw() in the InfoBar:Message is lost.

From my point of view it's even more simple, because no screen.Redraw() event is created in this scenario.

Try it yourself by adding...

"github.com/zyedidia/micro/v2/internal/screen"

...to the import section of internal/info/infobuffer.go and call screen.Redraw() e.g. at the end of the related InfoBuf Message() or Error() method (inside the if branch).

As far as I understood the rest of the messages, errors and prompts are created in a context/chain in which the update is called implicit.
I could imagine that requesting an explicit redraw with every message, error & (YN)prompt is more what the user would expect from these interfaces to do. Currently I can't imagine side effects, since it's just a event to wake the main thread for reprocessing.

@zyedidia & @dmaluka
What are your opinions about that?

[dmaluka]

I agree that in this case there is no redraw event generated at all, i.e. a screen.Redraw() is what is missing. The question is where to add it.

I don't think we should add screen.Redraw() it to the implementation of InfoBar():Message() itself. InfoBar():Message() is not special here. It is time.AfterFunc() that is special. The callback passed to time.AfterFunc() runs asynchronously, not in the main thread, as thus requires an explicit redraw. In this example this callback shows an infobar message, but it could instead do anything else that requires screen redraw (e.g. resize a pane) and we would have the same issue.

I could imagine that requesting an explicit redraw with every message, error & (YN)prompt is more what the user would expect from these interfaces to do.

That would not be enough anyway, since as I noted above, it is not just about messages, errors and prompts, it's about any actions that modify screen contents. (Which means pretty much any actions, actually.)

In micro itself, whenever such an action is done asynchronously, a redraw is explicitly done after it (grep for occurrences of screen.Redraw() in the source code). It seems reasonable to provide the same possibility to lua code, i.e. simply export screen.Redraw() function to lua, to let lua code that runs in a timer callback (or in any other async context) explicitly request screen updates.

Alternatively we could provide a "higher-level" interface than time.AfterFunc(), which would take care of redrawing the screen after executing the timer callback passed to it.

[X-Ryl669]

I've tried to find a Lua binding that's calling screen.Redraw() indirectly, but failed to do so.

Right now, I'm using the AfterFunc binding in the filemanager's PR I've submitted, to implement a filter function in the file manager. Typically, in the file manager's view, when you start typing letter & symbols, it automatically select the first file whose name starts with the filter. If you stop typing, after 5s, the filter auto clears by itself. This behavior is standard in all OS file manager, it's very intuitive.

In that PR, my need would be to hide the info bar once the filter is cleared to avoid confusing the user, so a Lua binding for screen.Redraw() would be perfect for the task.

There are over places where a asynchronous function is useful, like in the find function (it's a pain to keep hitting Enter to find the next match). Ideally, when using the find function, it should directly match while you're typing. You can't do that for each stroke, so you usually start a timer (and restart it upon keystroke) and when it fires, you search the buffer so it would imply redrawing asynchronously.

[JoeKar]

In this example this callback shows an infobar message, but it could instead do anything else that requires screen redraw (e.g. resize a pane) and we would have the same issue.

Yes, I know...I already did the search by myself.

It seems reasonable to provide the same possibility to lua code, i.e. simply export screen.Redraw() function to lua [...]

&

[...] so a Lua binding for screen.Redraw() would be perfect for the task.

Ok, I agree that this will provide the most flexibility to the end user, who can bundle a bunch of actions till he invokes the Redraw() action.

[dmaluka]

Oops, I've just submitted PR #2944 and only after that I've noticed that you already submitted #2939...

[X-Ryl669]

Seems like it's really needed then. I've used your documentation and merged the changes in the initial PR.