r32 changelog (preview)
Unreleased Changes
- (Breaking) The example script
etc/lfcd.cmdis updated to use the-print-last-diroption instead of-last-dir-path(1444) (by atahrijouti and joelim-work). Similar changes have been made foretc/lfcd.ps1(1491) (by alunegov), andetc/lfcd.fish(1503) (by postsolar). - (Breaking) The documentation from
lf -docand thedoccommand is now generated from Markdown usingpandoc(1474) (by gokcehan). - (New) A new option
hidecursorinactiveis added to hide the cursor when the terminal is not focused (965) (by laktak). - (New) A new special command
on-redrawis added to be able to run a command when the screen is redrawn or when the terminal is resized (1479) (by joelim-work). - (New) Options
cutfmt,copyfmtandselectfmtare added to configure the indicator color for cut/copied/selected files respectively (1540) (by joelim-work). - (New)
zshcompletion is added for thelfcdcommand (1564) (by postsolar). - (Fix) Default value of
rulerfmtoption is now left-padded with spaces to visually separate it from the file stat information (1437) (by joelim-work). - (Fix) Previews should now work for files containing lines with 65536 characters or more (1447) (by joelim-work).
- (Fix) Sixel previews should now work when using
lfcdscripts (1451) (by joelim-work). - (Fix) Colors and icons should now display properly for character device files (1469) (by joelim-work).
- (Fix) The selection file is now immediately synced to physical storage after writing to it (1480) (by joelim-work).
- (Fix) Timestamps are preserved when moving files across devices (1482) (by joelim-work).
- (Fix)) Fix crash for
highandlowcommands whenscrolloffis set to a large value (1504) (by joelim-work). - (Fix) Documentation is updated with various spelling and grammar fixes (1518) (by hankertrix).
- (Fix) Files beginning with a dot (e.g.
.gitignore) are named correctly afterpasteif another file with the same name already exists (1525) (by joshuali925). - (Fix) Prevent potential race condition when sorting directory contents (1526) (by Michael-Gallo).
- (Fix) Signals are now handled properly even after receiving and ignoring
SIGINT(1549) (by mtoohey31). - (Fix) The file stat information should now update properly after using the
cdcommand to change to a directory for the first time (1536) (by joelim-work). - (Fix) Previous error messages should now be cleared after a
mark-save/mark-removeoperation (1544) (by joelim-work).
I will help to update this changelog from time to time. Feel free to reword/rewrite any entries as you like.
I have merged a few more PRs, all of which are small, primarily to maintain the progress of lf development, and keep the outstanding PR count low.
@joelim-work Sorry to disappear for a long time and thank you very much keeping everything in order. I will try to go over the PRs that you already approved and merge them in the upcoming days. I will also try to drop some comments in discussions where my feedback is requested.
I should note that I often try to skim through issues and PRs daily even though I'm not actively participating in discussions myself. I might try to join if I realize something that can be considered a red flag. So feel free to merge patches more liberally when I'm not around. I owe to participate in discussions at the very least if I want to be included in the decision making process. This also includes things that I have objected against before in the past (e.g. fsnotify)
Having said that, it feels a little strange that you are much more active than I am in a repository with my name. We can bring up the possibility of creating an organization if it can make you more comfortable. Let me know if you are interested in this and I will take a look at what we can do.
Happy holidays and see you after your break.
@gokcehan Thanks, hope you had a good break too, also happy new year to you.
Normally I try to avoid directly tagging you, but sometimes there are decisions that are controversial in nature, or are otherwise difficult to decide on, and I will seek feedback from you. I have also lately found myself to be on the conservative side when it comes to decision-making (e.g. rejecting PRs or feature requests where they either extremely niche and/or could be achieved via user configuration).
Regarding the idea of changing the repository ownership to a GitHub organization, perhaps it's another way of opening up the project to more users who wish to contribute, but I have honestly not given this much thought. I was actually thinking of slightly decreasing my activity here (compared to the previous year), partly for myself, but also to give others the opportunity to participate in the development of lf. For now I don't see myself developing any new features, maybe some bug fixes, reviewing PRs and responding to issues/questions.
Anyway I think things are fine as they are now, you don't have to change anything if you don't want to.
@joelim-work Thank you very much for keeping the notes up to date. I guess there is nothing else we need for the release now.
About the timing of the release, I will be a little busy in the next two days. Maybe I can take a look at this in the weekend or next week. Or alternatively maybe you can try to do the release yourself this time. I'm curious if there is still anything required on my side to make a new release, and this could be a nice opportunity to give it a try.
To make a new release, the only thing required is the following (we could also have these in our documentation somewhere):
- Create a new tag and push it to github
- Add the release notes to the corresponding release on github after the builds are finished and the artifacts are uploaded
- Send an email to the mailing list
@joelim-work Forgot to mention, we also need to update the documentation if it is not up to date yet.
By the way, I just realized we have this in our CONTRIBUTING.md:
Run
gen/doc-with-docker.shto update the documentation
Perhaps we should add "optionally" or something similar to this sentence to avoid the hard requirement of docker for contributions.
Hi @gokcehan I'm not really sure about taking over the release process, I still prefer to leave it to you as it is your project, although I don't mind things like reviewing the incoming PRs, and updating the generating documentation every now and then.
Regarding the actual release itself, it doesn't have to be this week or anything - it's not that urgent. I was just suggesting it because it's been a while since the last release. Maybe it might be better to wait for a couple of weeks anyway as a freeze period.
@joelim-work A couple of weeks freeze period sounds good then.
@joelim-work I was planning to make a release today, but there seems to be some patches that can be considered bug fixes, so I think maybe we should merge them and leave the release for another week.
@gokcehan That's fine, I didn't expect so many PRs would be created in the last couple of weeks. I am not in a rush for these kind of things anyway.
BTW I have written a regex to check for incorrectly formatted lines in the changelog, I'm not sure how you verify them otherwise:
grep -vE '^- \*\*\((Breaking|New|Fix)\)\*\* .+ \([0-9]+\) \(by [^ ]+\)\.$' <filename>