Martin Tournoij

unread,

Oct 4, 2022, 12:15:18 PM10/4/22

to vim/vim, Subscribed

The difference between the 'normal' and 'big' builds is not very large:

normal    | 3195080 (3.1M)        | 2514680 (2.4M)
big       | 3261704 (3.2M), +65K  | 2560856 (2.5M), +45K

And I'm not sure many people are using the 'big' featureset.

This removes the 'big' featureset, and aliases that to 'normal', leaving us with three builds:

          | -O2            | -Os
tiny      | 1633984 (1.6M) | 1190576 (1.2M)
normal    | 3195080 (3.1M) | 2514680 (2.4M)
huge      | 3410232 (3.3M) | 3070104 (3.0M)

Which are all fairly distinct.

Features now included in 'normal':

FEAT_LANGMAP
FEAT_KEYMAP
FEAT_EMACS_TAGS
FEAT_CSCOPE
FEAT_CONCEAL
FEAT_TERMGUICOLORS
FEAT_VARTABS
FEAT_MOUSE_NET, FEAT_MOUSE_DEC, FEAT_MOUSE_URXVT
FEAT_SIGNS
FEAT_AUTOCHDIR
FEAT_RIGHTLEFT  (unless --disable-rightleft)
FEAT_ARABIC     (unless --disable-arabic)
FEAT_SODIUM     (unless --disable-sodium, or libsodium isn't found)
FEAT_SOUND      (unless --disable-canberra, or libcanberra not found)
FEAT_MBYTE_IME  (Haiku)

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/11283

Commit Summary

6bc6bdb Alias 'big' version to 'normal'

File Changes

(14 files)

Patch Links:

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

codecov[bot]

unread,

Oct 4, 2022, 12:26:00 PM10/4/22

to vim/vim, Subscribed

Codecov Report

Merging #11283 (6bc6bdb) into master (351523f) will decrease coverage by 0.63%.
The diff coverage is n/a.

@@            Coverage Diff             @@

##           master   #11283      +/-   ##

==========================================

- Coverage   81.81%   81.18%   -0.64%     

==========================================

  Files         162      152      -10     

  Lines      189096   179050   -10046     

  Branches    42999    40649    -2350     

==========================================

- Hits       154710   145362    -9348     

+ Misses      21833    21030     -803     

- Partials    12553    12658     +105

Flag	Coverage Δ
huge-clang-none	`82.72% <ø> (-0.01%)`	⬇️
huge-gcc-none	`?`
huge-gcc-unittests	`0.29% <ø> (ø)`
linux	`81.18% <ø> (-1.24%)`	⬇️
mingw-x64-HUGE	`?`
mingw-x86-HUGE	`?`
windows	`?`

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/version.c	`83.96% <ø> (-1.22%)`	⬇️
src/if_perl.xs	`54.85% <0.00%> (-17.93%)`	⬇️
src/gui_beval.c	`41.43% <0.00%> (-11.16%)`	⬇️
src/regexp_nfa.c	`80.44% <0.00%> (-9.07%)`	⬇️
src/arabic.c	`85.86% <0.00%> (-8.70%)`	⬇️
src/typval.c	`84.95% <0.00%> (-8.29%)`	⬇️
src/regexp_bt.c	`78.48% <0.00%> (-7.48%)`	⬇️
src/vim9execute.c	`83.11% <0.00%> (-7.18%)`	⬇️
src/json.c	`77.84% <0.00%> (-5.47%)`	⬇️
src/vim9compile.c	`87.42% <0.00%> (-4.78%)`	⬇️
... and 135 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Oct 4, 2022, 1:39:50 PM10/4/22

to vim/vim, Subscribed

> The difference between the 'normal' and 'big' builds is not very large:
>
> normal | 3195080 (3.1M) | 2514680 (2.4M)
> big | 3261704 (3.2M), +65K | 2560856 (2.5M), +45K
>
> And I'm not sure many people are using the 'big' featureset.
>
> This removes the 'big' featureset, and aliases that to 'normal',
> leaving us with three builds:
>
> | -O2 | -Os
> tiny | 1633984 (1.6M) | 1190576 (1.2M)
> normal | 3195080 (3.1M) | 2514680 (2.4M)
> huge | 3410232 (3.3M) | 3070104 (3.0M)
>
> Which are all fairly distinct.

This change does not make the code simpler, #ifdefs remain.
It does remove a choice, which has always been a bit confusing, there is
no clear argumentation why a feature is in normal, big or only in huge.

The normal build is clearly adding the +eval and +syntax features. And
quite a few more or less related features.

The best what I can come up with is that features that are for "most
users" would be in normal, while those that are rarily used or for a
specific target group would go in huge.

I think we could put anything for special language handling in huge. I
can't guess how many users there are for each feature, such as +langmap,
but it's easier to say "if you want language-specific features, use
huge".

> Features now included in 'normal':

The ones that are related to +eval and +syntax would be:
FEAT_CONCEAL
FEAT_TERMGUICOLORS
FEAT_SIGNS

Language related:
FEAT_LANGMAP
FEAT_KEYMAP

FEAT_RIGHTLEFT (unless --disable-rightleft)
FEAT_ARABIC (unless --disable-arabic)

FEAT_MBYTE_IME (Haiku)

Rarily used:
FEAT_EMACS_TAGS
FEAT_CSCOPE
FEAT_VARTABS
FEAT_MOUSE_NET, FEAT_MOUSE_DEC, FEAT_MOUSE_URXVT

FEAT_SODIUM (unless --disable-sodium, or libsodium isn't found)
FEAT_SOUND (unless --disable-canberra, or libcanberra not found)

What's left:
FEAT_AUTOCHDIR

Might as well move this to the normal build.

Now the question is: If we make this change, is that an improvement?

--
In war we're tough and able.
Quite indefatigable
Between our quests
We sequin vests
And impersonate Clark Gable
It's a busy life in Camelot.
I have to push the pram a lot.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Martin Tournoij

unread,

Oct 4, 2022, 2:16:43 PM10/4/22

to vim/vim, Subscribed

This change does not make the code simpler, #ifdefs remain. It does remove a choice, which has always been a bit confusing, there is no clear argumentation why a feature is in normal, big or only in huge.

Yes, my motivation was that I was looking at what exactly the different feature sets actually do and I found that the differences between "small" and "tiny" and "normal" and "big" were actually pretty small.

IMHO it's confusing now what the differences are. It's not really a "code thing" to make the code easier, but to make it easier for people who want to build Vim. That's also why I sent the other patch to merge the "tiny" and "small" builds; that it removed a bunch of #ifdefs was more of a side-effect than anything else.

I think the real question is: how often are people using the 'normal' or 'big' builds in the first place? My suspicion is that most people are using the 'huge' build, and a small subsection the 'tiny' build.

For example Ubuntu and Debian have the "vim" package (huge) and "vim-tiny", but no "vim-big" or "vim-normal". Alpine Linux (focused on being small) just has the "huge" build. Arch Linux just has a package for the "huge" build too. There are countless of distros, but I can't find any that uses the 'normal' or 'big' builds. The Windows installer is 'huge', macvim is 'huge'.

So in that sense I'm not sure if it really matters what we include in 'normal' or 'huge'; I'm fine with any choice on this, it's the removal of a feature set that's the improvement IMHO. I think we could probably just merge the 'normal' and 'huge' builds too (leaving just 'tiny' and 'huge') and no one will notice.

I can't guess how many users there are for each feature, such as +langmap, but it's easier to say "if you want language-specific features, use huge".

It seems to come up fairly frequently: https://vi.stackexchange.com/search?q=langmap

Aside: organising the docs in +feature-list could also help maybe, like so:

Features in tiny version (always enabled):
	*+autocmd*		|:autocmd|, automatic commands.
	*+cursorbind*	|'cursorbind'| support
	.. etc..

Features in normal version (includes everything in tiny):
	*+arabic*		|Arabic| language support
	*+autochdir*		support 'autochdir' option
	.. etc..

But it still leaves with the thing that the differences are pretty small and that AFAIK few people are using the 'normal' or 'big' versions.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

vim-dev ML

unread,

Oct 4, 2022, 3:04:29 PM10/4/22

to vim/vim, vim-dev ML, Your activity

* Martin Tournoij ***@***.***> [221004 14:16]:

> > This change does not make the code simpler, #ifdefs remain. It does
> > remove a choice, which has always been a bit confusing, there is no
> > clear argumentation why a feature is in normal, big or only in huge.
>
> Yes, my motivation was that I was looking at what exactly the
> different feature sets actually do and I found that the differences
> between "small" and "tiny" and "normal" and "big" were actually pretty
> small.
>
> IMHO it's confusing now what the differences are. It's not really a
> "code thing" to make the code easier, but to make it easier for people
> who want to build Vim. That's also why I sent the other patch to merge
> the "tiny" and "small" builds; that it removed a bunch of #ifdefs was
> more of a side-effect than anything else.

I haven't been following this thread, so I may not understand what the
actual changes are. That being said, I would be very hesitant to remove
tiny in favor of small; rather, I would do it the other way around.

The purpose of tiny (or at least the way it is currently being used in
Debian and Ubuntu; probably others) is to have a usable version of Vim
that is not only as small as possible on disk, but uses as little memory
as possible while running. It is used when you are on systems or in
situations where resources are scarce.

The differences between small, normal, big, and huge are really
user preferences, while tiny has a very specific functional mandate that
cannot be replaced by a larger version. I.e. if a user wants normal,
but it is not available, big will usually suffice. However, when a user
needs tiny, small will not do.

...Marvin

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Martin Tournoij

unread,

Oct 4, 2022, 3:09:00 PM10/4/22

to vim/vim, vim-dev ML, Comment

I haven't been following this thread, so I may not understand what the actual changes are. That being said, I would be very hesitant to remove tiny in favor of small; rather, I would do it the other way around.

The purpose of tiny (or at least the way it is currently being used in Debian and Ubuntu; probably others) is to have a usable version of Vim that is not only as small as possible on disk, but uses as little memory as possible while running. It is used when you are on systems or in situations where resources are scarce.

The differences between small, normal, big, and huge are really user preferences, while tiny has a very specific functional mandate that cannot be replaced by a larger version. I.e. if a user wants normal, but it is not available, big will usually suffice. However, when a user needs tiny, small will not do.

That was already done in #11268

Merging these two added just one feature to 'tiny' (cmdwin) with a ~4K disk footprint. There was no meaningful difference between the two.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Yee Cheng Chin

unread,

Oct 4, 2022, 5:08:14 PM10/4/22

to vim/vim, vim-dev ML, Comment

Aside: organising the docs in +feature-list could also help maybe, like so:

Features in tiny version (always enabled):
	*+autocmd*		|:autocmd|, automatic commands.
	*+cursorbind*	|'cursorbind'| support
	.. etc..

Features in normal version (includes everything in tiny):
	*+arabic*		|Arabic| language support
	*+autochdir*		support 'autochdir' option
	.. etc..

I don't care much about big vs normal vs huge, but please don't split the features like this. Most users really don't care about this huge vs normal distinction, and as you pointed out this is mostly an option for the party building Vim, not for the users. There is no need to expose such grouping to the user, as it would make scanning for the feature you want much more time consuming (since I just search alphabetically).

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Tony Mechelynck

unread,

Oct 5, 2022, 5:42:51 AM10/5/22

to vim/vim, vim-dev ML, Comment

Don't judge other people's preferences by your own.

I use Big Vim day-to-day, because most differences between Big and Huge are features I don't need, and the few that I do need can be enabled individually at configure time.

FWIW, here are the environments settings I use to compile my day-to-day build of Vim:

Environment variables to be set by SOURCING this script in bash before compiling a Big build of Vim

export CONF_OPT_GUI='--enable-gui=gtk3'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=big'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.m...@gmail.com"'

Best regards,
Tony.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Tony Mechelynck

unread,

Oct 5, 2022, 5:45:33 AM10/5/22

to vim/vim, vim-dev ML, Comment

For some reason I can't modify a post after sending it.

export CONF_OPT_GUI='--enable-gui=gtk3'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=big'

#export CONF_ARGS2='--with-vim-name=vim-big'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.m...@gmail.com"'

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Tony Mechelynck

unread,

Oct 5, 2022, 5:49:21 AM10/5/22

to vim/vim, vim-dev ML, Comment

Try again.

# Environment variables to be set
# by SOURCING this script in bash before compiling Big Vim

export CONF_OPT_GUI='--enable-gui=gtk3'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=big'

export CONF_OPT_COMPBY='"--with-compiledby=antoine.m...@gmail.com"'

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Marvin Renich

unread,

Oct 5, 2022, 7:11:07 AM10/5/22

to vim...@googlegroups.com

[I sent this yesterday, but it went to the List-Post address, which
apparently points to the github issue tracker rather than the vim-dev
list. I'm resending to the list.]

* Martin Tournoij <vim-dev...@256bit.org> [221004 14:16]:

> > This change does not make the code simpler, #ifdefs remain. It does
> > remove a choice, which has always been a bit confusing, there is no
> > clear argumentation why a feature is in normal, big or only in huge.
>
> Yes, my motivation was that I was looking at what exactly the
> different feature sets actually do and I found that the differences
> between "small" and "tiny" and "normal" and "big" were actually pretty
> small.
>
> IMHO it's confusing now what the differences are. It's not really a
> "code thing" to make the code easier, but to make it easier for people
> who want to build Vim. That's also why I sent the other patch to merge
> the "tiny" and "small" builds; that it removed a bunch of #ifdefs was
> more of a side-effect than anything else.

I haven't been following this thread, so I may not understand what the
actual changes are. That being said, I would be very hesitant to remove
tiny in favor of small; rather, I would do it the other way around.

The purpose of tiny (or at least the way it is currently being used in
Debian and Ubuntu; probably others) is to have a usable version of Vim
that is not only as small as possible on disk, but uses as little memory
as possible while running. It is used when you are on systems or in
situations where resources are scarce.

The differences between small, normal, big, and huge are really
user preferences, while tiny has a very specific functional mandate that
cannot be replaced by a larger version. I.e. if a user wants normal,
but it is not available, big will usually suffice. However, when a user
needs tiny, small will not do.

...Marvin

Bram Moolenaar

unread,

Oct 5, 2022, 7:32:37 AM10/5/22

to vim...@googlegroups.com, Marvin Renich

Fortunately, this is what has been done. Martin more or less did it,
but used the name "small". I prefer to use the name "tiny", since this
is what more people will recognize.

Dropping "big" is more complicated, since there are more features to
either move to "normal" or "huge". And there is no clear policy of what
goes where. At the same time "big" is not a good name either, it adds a
random set of features on top of "normal". Might as well take "normal"
and add any features that you need on top of that. Or just take "huge"
and get everything.

--
Microsoft: "Windows NT 4.0 now has the same user-interface as Windows 95"
Windows 95: "Press CTRL-ALT-DEL to reboot"
Windows NT 4.0: "Press CTRL-ALT-DEL to login"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\

Marvin Renich

unread,

Oct 5, 2022, 8:27:34 AM10/5/22

to vim...@googlegroups.com

* Bram Moolenaar <Br...@moolenaar.net> [221005 07:32]:

> Fortunately, this is what has been done. Martin more or less did it,
> but used the name "small". I prefer to use the name "tiny", since this
> is what more people will recognize.

Thanks! I, too, think tiny is a better name; it really emphasizes why
that version exists.

> Dropping "big" is more complicated, since there are more features to
> either move to "normal" or "huge". And there is no clear policy of what
> goes where. At the same time "big" is not a good name either, it adds a
> random set of features on top of "normal". Might as well take "normal"
> and add any features that you need on top of that. Or just take "huge"
> and get everything.

SGTM. I don't really have an opinion here. Perhaps a preference for
"normal" to continue to not have support for external (non-vim)
scripting languages; put them all in "huge".

For the Debian maintainers (Is that just you, James? Thanks for your
long-time support in Debian): it would be nice to have a gtk version
without all the external scripting languages. I know this increases the
maintenance load, so the status quo is certainly acceptable.

Thanks for a great editor, Bram.

...Marvin

James McCoy

unread,

Oct 8, 2022, 10:18:09 AM10/8/22

to vim...@googlegroups.com

On Wed, Oct 05, 2022 at 08:27:30AM -0400, Marvin Renich wrote:
> SGTM. I don't really have an opinion here. Perhaps a preference for
> "normal" to continue to not have support for external (non-vim)
> scripting languages; put them all in "huge".
>
> For the Debian maintainers (Is that just you, James? Thanks for your
> long-time support in Debian):

Currently, yes. :) I used to have more co-consipirators, but they moved
on to other things (at least one to emacs).

> it would be nice to have a gtk version
> without all the external scripting languages. I know this increases the
> maintenance load, so the status quo is certainly acceptable.

We tried to use the <lang>/dyn functionality a few years ago, but that
doesn't play well with binary distributions. You could end up in a
state where, e.g., Python upgraded across an X.Y version (which is ABI
incompatible with X.Y-1) but Vim wasn't rebuilt against the new Python.
Then anyone trying to use the Python interface would crash.

Even if Vim had been built, there would be nothing preventing a partial
update, where only Python was updated, and therefore the same problem
would exist.

The dynamic loading of language bindings would need to be reworked so
shared objects are built with explicit linking against the language
library (which would be properly tracked in the package metadata) and
then those could be optionally installed by users that wanted them.

Last time I looked into that, though, it's non-trivial to make that
switch because the code present in the language bindings is dependent on
how you build Vim (small vs huge features, gui vs no-gui, etc.).

Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB

Bram Moolenaar

unread,

Oct 8, 2022, 2:27:09 PM10/8/22

to vim/vim, vim-dev ML, Comment

Closed #11283 via 25f3a14.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Marvin Renich

unread,

Oct 8, 2022, 5:52:17 PM10/8/22

to vim...@googlegroups.com

* James McCoy <jame...@jamessan.com> [221008 10:18]:
[snipped very nice explanation of the problems with dynamically linking
the language bindings]

Thanks for the explanation.

...Marvin

Bram Moolenaar

unread,

Oct 11, 2022, 4:51:47 AM10/11/22

to vim/vim, vim-dev ML, Comment

Tony wrote:

> Don't judge other people's preferences by your own.
>
> I use Big Vim day-to-day, because most differences between Big and
> Huge are features I don't need, and the few that I do need can be
> enabled individually at configure time.

That is similar to what I was thinking: keep "normal" for including the
most useful features, and leave the less frequently used ones for
"huge". Then you can use "normal" and add a couple of features that you
specifically need.

> FWIW, here are the environments settings I use to compile my
> day-to-day build of Vim:
>

> # Environment variables to be set by SOURCING this script in bash before compiling a Big build of Vim

> export CONF_OPT_GUI='--enable-gui=gtk3'
> export CONF_OPT_MULTIBYTE='--enable-multibyte'
> export CONF_OPT_AUTOSERVE='--enable-autoservername'
> export CONF_OPT_FEAT='--with-features=big'

> export ***@***.***"'

You can drop "--enable-multibyte', it is always included now.

--
press CTRL-ALT-DEL for more information

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\

/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Yee Cheng Chin

unread,

Nov 4, 2022, 12:57:13 AM11/4/22

to vim/vim, vim-dev ML, Comment

Seems like this broke +sound on macOS builds. Please make sure to scrub existing usages of macros before undef'ing them. Filed #11497 to fix this.

[vim/vim] Alias 'big' version to 'normal' (PR #11283)

Martin Tournoij

You can view, comment on, or merge this pull request online at:

Commit Summary

File Changes

Patch Links:

codecov[bot]

Codecov Report

Bram Moolenaar

Martin Tournoij

vim-dev ML

Martin Tournoij

Yee Cheng Chin

Tony Mechelynck

Environment variables to be set by SOURCING this script in bash before compiling a Big build of Vim

Tony Mechelynck

Tony Mechelynck

Marvin Renich

Bram Moolenaar

Marvin Renich

James McCoy

Bram Moolenaar

Marvin Renich

Bram Moolenaar

Yee Cheng Chin