📣 Releasing r41

[joelim-work]

There hasn't been much activity in the past couple of weeks, so I figure it's probably a good time to create a new release.

Please see the changelog for more details about the release.

Note

From now on I will post a link to the changelog, instead of copying the actual markdown and having to update it whenever it changes.

Tcell seems to be in heavy development recently, so I think it is better to delay the v3 migration for a while, until it stabilizes further.

Anyway there will be a change freeze for around a couple of weeks to see if there are any regressions. If anyone has any queries or concerns, please let me know.

[CatsDeservePets]

@joelim-work I think it might be a good time to publish a new release. What do you think?

[joelim-work]

Regarding #2563, I could not reproduce it myself so I have declined to comment there. In any case the latest release of Tcell does not contain the bug fix for #2554, so maybe it is better to wait until a new version is released.

I have also reviewed PRs #2491, #2537 and #2561. As you can probably tell by now, I am very strict with PRs - below are some brief points about my thought process behind them:

• I expect contributors to test patches before submitting them. Providing a test case or steps to reproduce the original issue is also very helpful for reviewers, and it indicates that the contributor has verified that their patch works.
• PRs where the expected behavior does not change are much easier to review, this includes refactors, and trivial bug fixes resulting from an oversight in the original implementaion. PRs which modify the expected behavior (more complex bug fixes or feature requests/enhancements) are much more difficult as the new behavior has to be evaluated - this is often opinionated and what one user sees as a necessity may be seen as irrelevant from the perspectives of others. If in doubt, it is worth going through the commit history to see why things may have been done a certain way.
• LOC on its own is a weak indicator of complexity - just because a PR contains only a few lines of diff does not mean that it takes me only a few minutes to review.
• I am generally more interested in changes that simplify lf rather than add enhancements to it. These days I am less interested in trying to make it a perfect file manager when yazi now exists - I have heard users say they switched to yazi because they find it better than lf, but I have rarely heard the opposite.

[valoq]

Also, on a more personal note: I have been rather stressed lately (and more grumpy than usual I think), so I did not really have the time or motivation to take a deeper look at pull requests that I'm not personally very interested in. Nevertheless, I still appreciate your engagement in lf.

Dont worry about it. Id rather see a good stable release then rush things.

I have also reviewed PRs #2491, #2537 and #2561. As you can probably tell by now, I am very strict with PRs

That is why I have a very good impression of the state of this code :)

About the raised points:
It would probably make sense to add some PR and issue template that user have to fill out (or at least provide suggestion) to cover these points. I also noticed that I kept forgetting the changelog entries, so that would be one example to ask for in PRs along with a reproduction example.

For issues I think we should also ask for the reporter to mention the tested version they encountered the problem with and to ask them to reproduce the issue on the current master branch.

I am generally more interested in changes that simplify lf rather than add enhancements to it. These days I am less interested in trying to make it a perfect file manager when yazi now exists - I have heard users say they switched to yazi because they find it better than lf, but I have rarely heard the opposite.

Frankly I think these tools are fundamentally different and speak to separate user groups in many cases. Lf provides a still very minimal file manager that can be extended easily with scripted functions, while yazi is far more complex and has lots of default features. In my mind its a bit like the difference between Arch Linux (being like lf) and Ubuntu/Fedora (being like yazi).

On that note, perhaps we should highlight this more in the readme and describe lf as a simple and minimalistic file manager with easy to extend features. With the new filter code, it is now even one of the most reliable option and personally that is my primary motivation - reliable filesystem display and file operations.
Bottom line is; Users looking at this repo will read one or two lines to determine if they should look further into it, and there it should be highlighted what makes lf stand out in comparison with other tools.

[CatsDeservePets]

It would probably make sense to add some PR and issue template that user have to fill out (or at least provide suggestion) to cover these points. I also noticed that I kept forgetting the changelog entries, so that would be one example to ask for in PRs along with a reproduction example.

For issues I think we should also ask for the reporter to mention the tested version they encountered the problem with and to ask them to reproduce the issue on the current master branch.

I thought the same, actually. I am in favour of this.

[valoq]

@joelim-work Its high time for the new release Id say

[joelim-work]

I have now created a new release r42