File size of lf executable increased

[krackout]

There's an increase in the lf executable file size (Linux AMD64). From 3.6MiB reached to 5.4MiB without adding significant features. My previous compile was on 505c4ef commit (about three months ago). I compiled the latest yesterday and noticed the difference. What could it make the executable bigger?

The size is not so big in absolute numbers, but it's quite an increase in percentage. I regularly copy lf to remote servers to administer, sometimes the connection bandwidth is narrow.

[krackout]

I think I got it: It's commit 3f63bc9, add option to sort base on certain locale. The size bump is 1.6MiB, from 3.6MiB to 5.2MiB, 44.4% increase. 5.4MiB is the size of lf with latest commit included.
Is it worth it? I suggest reconsidering the addition of 3f63bc9 to master.

[joelim-work]

Thank you for mentioning this. I don't plan to use that new locale feature myself, but at the time I thought it was a good idea because otherwise there's no way to sort files based on the rules of a particular locale (as opposed to sorting based on raw bytes). Without including direct support for handling different locales, the only other solution I can think of is if someone implements a custom sorting method as mentioned in #618.

This is one example of the problem of feature management in software development. Especially with an application such as lf that is designed to be minimal, how does one decide whether a feature should have built-in support, made available through extensible configuration, or outright rejected because it is too niche? For the case of locale, I think there can be various opinions among different people - I am neutral on this myself, but am open to further discussion.

[krackout]

I understand your considerations on the matter of feature management, that's the big picture. The balance between minimal (or even austere) and feature-rich but bloated.

Regarding the specific commit, I'm not indifferent on the locale issues myself since I use latin and greek keyboard layouts and have filenames with greek and latin characters. So I sympathize people with locale issues, having met many; yet with unicode, sorting based on raw bytes works well for greek. Perhaps it's a good candidate for availability through extensible configuration, for whoever needs it.

I can live with it, keeping an lf without this commit for remote servers and having the latest on my personal computers.

[joelim-work]

The use case specified by the author of #1818 was for strings in Chinese, which I believe sorts based on Pinyin romanization and some other factors. For example 你 (pronounced nǐ, U+4F60, means "you") comes before 他 (pronounced tā, U+4ED6, means "he"), despite the fact that it comes later in terms of Unicode code points. Similarly, I'm quite sure there are other languages out there (that I don't speak) where sorting by raw bytes produces inferior results.

So the fact remains that locale-specific sorting is a feature that some users might be interested in, and is also something that lf does not support prior to #1818. The question is then how to implement such a feature, which could include:

• Native support, toggled using an option. This is the current approach, but even if the feature is disabled by the user, the resulting code from the collate library still ends up in the compiled binary.
• Conditional compilation via feature flags. This is possible but increases code complexity, and additionally opens the door for controlling other features using this approach, which can quickly spiral out of control. I personally don't think this kind of complexity is worth it, just to fulfil the desires of having both locale-specific sorting and smaller binaries.
• Delegating the sorting functionality to another script/program via configuration, as specified in Sort by custom method #618. This is more generic, can handle other use cases outside of locale-based sorting, and is more in line with lf's minimalistic design goals. The only issue is that it requires more work for users to configure, although I think it won't be more complex than configuring image previews, and to me it is also an acceptable solution.
• Rejecting the feature entirely. This means that the feature is considered too niche to include in the main project, and any interested users will have to maintain a fork of the project. This is also a possibility, though I would feel somewhat guilty of approving and merging the PR in the first place. There were a few users who were reacted with interest to Request - sort by locale #323, and removing this feature would impact all of them.

Currently I'm inclined to stick with the first approach and keep things as-is, but we can keep this discussion open if anyone else has other suggestions. I suppose I can also mark this locale feature as experimental, if you're still unsure about whether it should have been added or not.