[vim/vim] Consider aliasing the "normal" build to "huge" (Issue #19567)
Martin Tournoij
arp242 created an issue (vim/vim#19567)Here are the sizes of the normal and huge builds:
3,548K │ normal-O2
3,078K │ normal-Os
3,754K │ huge-O2 +206K
3,261K │ huge-Os +172K
The huge build is about 200K larger, which is not that much on 3.5M. Even more so since most people will use the runtime files, which is 47M for a full install, or 27M if you remove translated docs and GUI stuff. Many additional features in the normal build require the runtime files.
I'm not really aware of any distro that ships separate "huge" and "normal" builds?
So I propose "normal" to include all the features currently in "huge" and "huge" is made an alias of "normal", similar to how "big" and "small" were aliased to "huge" and "tiny" a few years ago.
This would simplify the build selection a bit, can simplify the CI a bit, etc.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19567)I'd say this is a resonable suggestion.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Ajit Thakkar
Gary Johnson
>> On Thursday, March 5, 2026 at 6:28:11 AM UTC-4 Christian Brabandt wrote:
>>
>> I'd say this is a resonable suggestion.
>
>
> I used normal builds for 25 or more years. I switched to huge a few years ago
> when I noticed that the relative size difference had shrunk over the years.
>
> If the builds are made identical, the default name should be normal rather than
> huge.
can enable a normal build, then enable additional features using the
--enable-<feature> configure options or -DFEAT_<feature> compiler
flags. However, it doesn't work to enable a huge build, then
disable unwanted features because not all features enabled by the
huge build can be disabled (e.g. keymap).
If this proposal is accepted, some work will need to be done to the
configure script and to feature.h to allow all features to be
enabled or disabled according to the user's preferences.
Regards,
Gary
dezza
dezza left a comment (vim/vim#19567)There is another shortcoming when it comes to selecting featuresets:
If you build --with-features=tiny --enable-gui=gtk3 you end up with a frankenstein, hybrid build that falls between being a -eval no eval build - which normally doesn't support conditions like if|endif. However, with a gui build you do have a stubbed if|endif, even if you are warned about -eval no eval and docs document a workaround which is NOT applicable to this hybrid-frankenstein tiny build.
So a tiny guibuild sits quite uniquely below a normal build, even if it it violates the description of a tiny featureset. Gating a vimrc for tiny using the if 0 trick documented above is now broken.
This is why distros have historically built separate gvim and vim binaries - as these hybrids that borrow features from higher features makes little sense and breaks the contract of a tiny build not supporting if|endif.
Even if the separation of tiny,normal,huge can seem seemingly negible there can in the future grow a larger gap and has scaled either way thru development timelines.
I think it would make sense to make normal featureset implicit with --enable-gui and potentially treat --with-features=tiny --enable-gui=... as an error to inform about this, or solve the issue entirely correctly disabling if|endif.
Another problem is that most of the builtin colorschemes of the newer ones actually don't even support tiny builds without requiring a silent! colorscheme-switch, ignoring errors of undefined functions such as set termguicolors.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Tony Mechelynck
tonymec left a comment (vim/vim#19567)I routinely build two "tiny" builds, one with --disable-gui named vi and another one with --enable-gui=motif named vim-small. I just loaded the latter one and typed
:if 1 | echo 'hello' | endif
followed by <Enter>. Nothing happened, as is expected in a -eval build.
In my usual gvim build (Huge with --enable-gui=gtk3 but no interpreted languages) the same command displays hello, again as expected.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
dezza
dezza left a comment (vim/vim#19567):if 1 | echo 'hello' | endif
followed by<Enter>. Nothing happened, as is expected in a-evalbuild.
Try setting an option then. The point is it does not guard against tiny in the gui build. The echo command still fails.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Tony Mechelynck
tonymec left a comment (vim/vim#19567):if 1 | echo 'hello' | endif
followed by<Enter>. Nothing happened, as is expected in a-evalbuild.Try setting an option then. The point is it does not guard against tiny in the gui build. The echo command still fails.
In the GTK3 tiny build, I didn't test. In the Motif tiny build :if ... endif is a nestable command as expected from a no-eval build:
:set awa? noautowriteall :if 1 | set awa | endif :set awa? noautowriteall
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
dezza
dezza left a comment (vim/vim#19567)well ok, it could be the gtk3 has other deps, at least last time I built tiny there.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.