Customizable status bar

[joelim-work]

Introduction

There have been issues raised in the past about how to customize the contents of the status bar, for example #112 and #310. For a very long time the contents of the status bar was hard-coded, and support was added only very recently in #1168 to select which fields to display and in which order. However, this is still rather limited, because the set of available fields is pre-defined, and there is no support for custom colors or formatting. This presents a problem, because users will invariably request arbitrary information to be displayed, in whatever format they desire.

In my opinion, the only way to allow users to have full power to customize the status bar, while maintaining simplicity in the design, is to delegate the work to external commands, as opposed to implementing everything inside lf. In addition, the external commands cannot be invoked by the main thread that is responsible for drawing the UI, for performance reasons. I have spent a few days on this and come up with the following solution:

1. Create a separate thread that is responsible for invoking the external commands.
2. Add a timer (running every second) that sends a trigger to that thread.
3. When the thread receives a trigger, invoke the external commands and then send the information back to the main thread.
4. Once the main thread receives the information, it can use the information to update the contents of the status bar.

Demonstration

The following video shows in the status bar:

• The time and date as the output of date, which is updated in real time.
• The value of the selmode setting as it is changed.
• The amount of free disk space remaining, which is decreased when fallocate is used to create a big file, and restored when the file is deleted.

2023-05-18.12-19-20.mp4

From a configuration perspective, all the user has to do is specify the external commands in the ruler option:

set ruler 'acc:$date:selection:$lfselmode:ind:$diskfree'

For external commands where you simply want the output without any additional formatting, you can use them directly (e.g. $date).

If you want to pass options to external commands and apply any post-processing afterwards, you can write a wrapper shell script. Below is the shell script for the $diskfree component (see #1103):

#!/bin/sh

free=$(df -h --out=avail . | awk 'NR == 2 { print $1 }')
printf '\e[48;2;100;150;50m df: %s \e[0m' "$free"

The current values of lf settings are exported as environment variables, so they can be referenced in shell scripts to display them. Below is the shell script for the $lfselmode component (see #1174):

#!/bin/sh

printf '\e[48;2;0;50;150m selmode: %s \e[0m' "$(printenv lf_selmode)"

Replacing the builtin df component

In addition to allowing the status bar to be customized, #1168 also adds functionality for calculating the amount of free disk space natively inside lf. I think this is an unfortunate inclusion, as this is something could be handled externally. I am leaning towards the side of removing the builtin df component, but we may end up keeping it since it has already been officially released in r29, and removing it would be a breaking change.

Customizing other builtin components

One idea I had was to export the values of all the builtin components (e.g. acc and ind) and just have one external shell script for formatting the entire status bar. I don't see any way to implement this easily though, since this effectively means running an external command and immediately update the screen every time the user presses a key, which isn't good for performance reasons. Perhaps these could be handed separately, with config options similar to the already existing errorfmt.

Conclusion

I think that this implementation fits in line with the minimalist design of lf, and is superior to attempting to handle every possible component directly inside the program. In terms of the patch size, all of this was implemented in about 60 lines of code, so the overall change is actually quite small. Hopefully there is enough interest in this feature, and if so I am happy to submit a pull request for this.

[joelim-work]

Regarding the customization of other builtin components, I have found a way to achieve this - by having a single external shell script return a format string with placeholders which lf later substitutes with its internal values.

The placeholders can have the following forms:

• {{name}} - in which case the value is directly substituted
• {{name|format}} - in which case the value is applied to the format string format and the result is substituted, if and only if the value is not blank. This is useful for handling optional values like progress.

Of course, allowing for this level of customization means the resulting shell script will be more complex:

#!/bin/sh

df=$(df -h --out=avail . | awk 'NR == 2 { print $1 }')

hidden="\e[48;2;50;50;120m hidden "
if [ "$(printenv lf_hidden)" != true ]; then
    hidden=""
fi

acc="{{acc|\e[48;2;150;100;200m %%s }}"
cut="{{cut|\e[48;2;150;0;50m cut: %%s }}"
copy="{{copy|\e[48;2;150;150;50m copy: %%s }}"
selection="{{selection|\e[48;2;200;50;200m select: %%s }}"
selmode="\e[48;2;0;70;80m selmode: $(printenv lf_selmode) "
clock="\e[48;2;0;120;80m $(date +%r) "
free="\e[48;2;0;100;150m free: $df "
ind="\e[48;2;0;130;170m [{{ind}}] "
reset="\e[0m"

printf "${acc}${cut}${copy}${selection}${hidden}${selmode}${clock}${free}${ind}${reset}"

And here is the video:

2023-05-18.22-26-42.mp4

[joelim-work]

I'm still not entirely convinced by the above approach actually.

I think I have yet another idea which is to handle the drawing of all the internal state like acc and ind in the main loop, and for all the external info like free disk space, date, etc. have a cron job to determine those values and then set them as user values (added in #865), which can then be accessed inside lf. Then there's no need to create a separate Go thread since the external cron job effectively does the same thing.

[joelim-work]

OK so turns out the user-defined values approach is much simpler in terms of both design and implementation. I have submitted a PR #1257