New release needed ?

[X-Ryl669]

Description of the problem or steps to reproduce

This is not a problem per se, but it might become.

Currently, the last micro release is almost one year old. There's a lot of activity going on, but because no new release happens, many PR are out of sync, which is just discouraging for developers, contributors and volunteers.
PR are lingering and no one will include them.

Is there any plan to release a new version, and if yes, what features to expect in it ?

If I were to sort the PR, many are about new syntax coloring scheme for exotic file formats. I guess they can be merged "as-is", after all, there's not much loss if they don't actually work well. And at least, they'll be improved by new PR instead of a 2 year old lingering PR no one can test anymore.

Plugins also need some love, there are many plugins I consider as fundamental (like the file manager for example, or the language server) that are lagging behind and must be imported from exotic URL.

There are also feature plugins that, IMHO, need to be sorted out but worth it:

1. Code folding
2. Faster highlighter
3. Atomic or close to atomic file save

What do you think?

[niten94]

Is there any plan to release a new version, and if yes, what features to expect in it ?

There has been a lot of commits made since 2.0.13 was released 1 year ago so releasing a new version has been discussed in #3254 but 2.0.14-rc1 was released 1 week ago. There has been no regressions reported so it seems like the preparation with releasing 2.0.14 may be near completion when reading the comments in the discussion.

If I were to sort the PR, many are about new syntax coloring scheme for exotic file formats. I guess they can be merged "as-is", after all, there's not much loss if they don't actually work well. And at least, they'll be improved by new PR instead of a 2 year old lingering PR no one can test anymore.

I have not properly tried reviewing pull requests related with syntax definition files so I cannot say much, but merging them if there are not too much problems seen seems to makes sense when thinking about it. Having bugs that stand out or too much problems with the files may be less liked than not using syntax highlighting.

There are also feature plugins that, IMHO, need to be sorted out but worth it:

1. Code folding
2. Faster highlighter
3. Atomic or close to atomic file save

major label has been at least added on one issue linked with the pull requests listed except Code folding. The usage of the label was discussed in #3254 and I think the issues (and linked pull requests) with the label have higher priority than others, but it does not at least seem to be easy implementing those 2 pull requests for now.

[dmaluka]

There is a plan to release a new version in the nearest days. There is already a prerelease: https://github.com/zyedidia/micro/releases/tag/v2.0.14-rc1. The release will probably have no differences from it. Some context: #3254 (comment). We are not planning to add any more PRs to it (except regression fixes, if we find any regressions), not even trivial highlighting improvements etc. They can wait until the next release.

There are also feature plugins that, IMHO, need to be sorted out but worth it:

1. Code folding
2. Faster highlighter
3. Atomic or close to atomic file save

#3127 and #3273 are quite worthful, yeah. #3127 appears to work very well, but needs quite yet some time and energy to properly review it. And #3273 addresses quite an important issue, but it is not quite finished.

There has been a push from many people (like from you just now) for a new release ASAP, so we decided to go ahead with it before finalizing those PRs (as we concluded it makes sense indeed, since so many other improvements have accumulated since 2.0.13 already). Some background: #3380 (comment)

As for #2942, I personally haven't looked into it yet, haven't had time or motivation for that, since I've never found code folding a useful feature.

[X-Ryl669]

Ok understood. I guess a minor bump will be required for adding features then (like code folding, scrollbar dragging/clicking, and so on).

Would it be possible to move the syntax highlighting part to a plugin or dynamic module repository? There's so much noise for new syntax files it makes searching in issues and PR trouble some.

Also, what about plugins ? Should we wait after the 2.0.14 release or until a 2.1.0 release ?
Many plugins are outdated in official repo, there is unofficial one and a less official too.

That's probably because the Lua interface is constantly changing or lacking, so would it be possible to set as a goal to stabilize this interface? I'm asking here because I'm not a go developer but I did write some plugins in Lua, and I'm just waiting for some features to drop (like refreshing the screen upon asynchronous update) to update them.

[JoeKar]

v2.0.14 is now out there. 🎉

The usage of the label was discussed in #3254 and I think the issues (and linked pull requests) with the label have higher priority than others, but it does not at least seem to be easy implementing those 2 pull requests for now.

Yep, we were quite busy with the last PRs added. After v2.0.14 is out now I hopefully find some time to work with my older and the other marked major PRs/issues.

Would it be possible to move the syntax highlighting part to a plugin or dynamic module repository? There's so much noise for new syntax files it makes searching in issues and PR trouble some.

We've already trouble to maintain this single source, while more dependencies are known to cause problems. Moving this to a different repository increases the effort necessary to keep everything somehow maintained.
The largest problem we currently have is, that we've not the maintainer rights for every involved repository and already consider additional forks (see this discussion).

Unfortunately we can't even allow more contributors to add labels, which highly improves the filtering.

We can only encourage to be patient for waiting for a new release and support us with reviews (and possible approvals) where ever possible.

[Andriamanitra]

Would it be possible to move the syntax highlighting part to a plugin or dynamic module repository? There's so much noise for new syntax files it makes searching in issues and PR trouble some.

Adding a label for syntax highlighting related issues and pull requests would completely solve the search issue without any added complexity.

[dmaluka]

Many plugins are outdated in official repo, there is unofficial one and a less official too.

I heard many times that it is a mess, but had no time to look into that myself. Too much stuff to fix in micro itself.

the Lua interface is constantly changing or lacking, so would it be possible to set as a goal to stabilize this interface?

Realistically, no.

When it comes to the interfaces explicitly documented in help plugins, we already do our best to not break them anyway.

But when it comes to the "implicit" interfaces, i.e. to this:

This may seem like a small list of available functions, but some of the objects
returned by the functions have many methods. The Lua plugin may access any
public methods of an object returned by any of the functions above.
Unfortunately, it is not possible to list all the available functions on this
page. Please go to the internal documentation at
https://pkg.go.dev/github.com/zyedidia/micro/v2/internal to see the full list
of available methods. Note that only methods of types that are available to
plugins via the functions above can be called from a plugin. For an even more
detailed reference, see the source code on Github.

^ this may sound like for any such public Go methods, we always take into account that they may be used not just by micro itself but by plugins, and we try to keep all those public methods indeed suitable and meaningful to use by plugins, and we try to keep their interfaces stable. But in practice there has never been such a commitment.

Basically this has always been a big clever hack, which allows to make plugins quite powerful with very little effort (we provide plugins with lots of interfaces to various functionalities automatically, without extra work to export those interfaces to Lua, or even to define or document them, or even to think which interfaces should we export), at the cost of making plugin interfaces very ill-defined, messy, often weird and non-intuitive and inconvenient and confusing, and unstable.

We add some method e.g. to Buffer, to use it internally in micro, and we make this method public just to be able to use it not just in internal/buffer/* but also in other parts of micro, e.g. in internal/display/bufwindow.go, and as a side effect this method becomes available to plugins as well. So one day some plugin author may start using it and relying on it. Whereas it may make no sense to use this method outside micro, and it may be actually a very bad idea, since it may change micro's internal state in unpredictable ways. But we are not committed to doing anything like adding "CAUTION: not for use in Lua" to the documentation of any such methods. (Many of those methods lack any documentation.)

That's the reality.

That said, we do avoid making changes that are just too likely to break plugins. For example, in #3343 we avoided changing SetOptionNative() interface, and added DoSetOptionNative() instead.

IIRC @zyedidia once said somewhere that he never treated micro's plugin functionality too seriously, he considered it just a nice-to-have not-too-important addition to micro's core functionality.

[dmaluka]

I did write some plugins in Lua, and I'm just waiting for some features to drop (like refreshing the screen upon asynchronous update) to update them.

IIRC asynchronous screen refresh actually never used to work, - until it started working recently, i.e. until this release actually, since we made any asynchronous lua code work internally as synchronous from micro's perspective (unless you are using the unsafe interface for timer callbacks, which we removed in #3023 and then added back in #3211 since users complained.)

[X-Ryl669]

Yes exactly. Currrently (as of 2.0.14), this still doesn't work, since after the timer expires, Micro doesn't refresh the buffers so the change to the content made by the plugin isn't visible to the user. I thought you'd made the required changes, but I haven't seen you've reverted them.

So the plugin will still be broken even in the last release (I'll open another issue for this then).

That's a good example why hardening the Lua API would be better. There is still no way for Lua to tell micro to refresh currently. Your initial change with After function would have given a way (even if it's a bit convoluted compared to a dumb "Refresh" method), yet I understand the reason you did it.

Maybe a minor bump can be used to update the API to have a safer Lua environment: Deprecate AfterFunc now (but don't replace by After, just add it, and remove the Lock). The only 2 plugins making use of this is mine and Language Server. Almost all other plugins aren't asynchronous, so the burden will be upon us not you. I think it's safe to have all asynchronous code running in a parenthesis (the After callback context) so it prevent the issues you've spotted with updated content from outside Lua.

[dmaluka]

I thought you'd made the required changes, but I haven't seen you've reverted them.

The only thing that was reverted is the removal of the old API (4ffc220 -> ed21018 + 4718c98). The new After API was not reverted, it is still available and is the recommended and documented way to use timers, as you may have noticed from help plugins.

There is still no way for Lua to tell micro to refresh currently.

And there is no need for Lua to do that, unless you are using the old time.AfterFunc API, which you shouldn't use because it is unsafe.

Deprecate AfterFunc now (but don't replace by After, just add it, and remove the Lock).

That is exactly what we did.

AfterFunc was never documented anyway.

...Now I'm actually thinking about removing this old timer API once again, but this time don't remove this singe AfterFunc function but make it an alias for After, rather than the raw Go's time.AfterFunc.

[JoeKar]

Do we need to keep this issue open? We've now the v2.0.14 ready and the most important stuff scheduled for v2.0.15.