$ pkg install vim ... spidermonkey78: 78.7.0_5 sqlite3: 3.35.5_3,1 tiff: 4.3.0 tpm-emulator: 0.7.4_2 trousers: 0.3.14_3 ... Why in the world does an editor need TPM (trust platform module) support? Much less an emulator giving you a software TPM [vs. the trustable hardware TPM]. Why does an editor require an SQL backend and a web framework (JavaScript interpreter)?
*** Bug 257377 has been marked as a duplicate of this bug. ***
Hi David. There are several vim ports, for different use cases. The default (editors/vim), has the following options, and respective defaults: ===> The following configuration options are available for vim-8.2.3081: CSCOPE=on: cscope support DEFAULT_VIMRC=on: Install bundled vimrc as default setting MAKE_JOBS=off: Enable parallel build NLS=on: Native Language Support XTERM_SAVE=off: Restore xterm screen after exit ====> Optional language bindings LUA=off: Lua scripting language support PERL=on: Perl scripting language support PYTHON=on: Python bindings or support RUBY=on: Ruby bindings or support SCHEME=off: MzScheme (Racket) bindings TCL=off: Tcl scripting language support ====> Options available for the single CTAGS: you have to select exactly one of them CTAGS_BASE=off: Use system ctags CTAGS_EXUBERANT=on: Use exctags instead of ctags CTAGS_UNIVERSAL=off: Use uctags instead of ctags ====> User interface: you have to select exactly one of them ATHENA=off: Athena GUI toolkit CONSOLE=off: Console/terminal mode GTK2=off: GTK+ 2 GUI toolkit support GTK3=on: GTK+ 3 GUI toolkit support MOTIF=off: Motif widget library support X11=off: X11 (graphics) support ===> Use 'make config' to modify these settings Many of these optional features have their own dependencies. While this is not a support forum, i'll describe a short summary of options: Alternative vim ports, with much smaller dependency sets: - editors/vim-lite - editors/vim-console If you use ports, disable any or all of the features that aren't desired. If you find however there are specific 'spurious' (incorrect, inaccurate) dependencies, please re-open this issue with additional details
BTW, the specific answers are: tpm-emulator and trousers are dependencies of gnutls, which is a dependency of cups, which is a dependency of gtk30; spidermonkey78 is a dependency of polkit, which is a dependency of colord, which is a dependency of gtk30; sqlite3 is a dependency of colord, which is a dependency of gtk30. (If building from ports, turning off gtk30's COLORD option, or colord's POLKIT option will save a noticable amount of effort if spidermonkey is not also being pulled in by something else.)
The decision to make GUI vim the default was made back when you maintained the port. I inherited that decision, and I'm obligated to stick with it. Personally, I think that the vim port should be console-only, and GUIs should be an optional addition package. POLA, though, requires me to stick with the most common GUI toolkit for the default package. So, yes, GTK3 has an absurd number of dependencies, and of course gvim uses only a small fraction of those. There is, however, nothing I can do about it. GTK3 brings in those dependencies. Personally I build with the X11 option for desktop machines, and console-only installations should absolutely be using the vim-console package instead.
(In reply to Adam Weinberger from comment #4) I believe there's been sufficient user support requests, user confusion, and support costs paid over the years associated with the current setup that considering ways we could improve the situation would not be rejected out of hand by the community. Things change and POLA is not a universal, particularly if there's quality communication. I would also argue that the current state has an element of POLA to it, given the surprise of many users around how big the vim port is. Question: Do what extent is it possible to 'sub package' vim, such that ports/packages can be cumulatively installed to add features/modules, rather than each port being mutually exclusive?
(In reply to Kubilay Kocak from comment #5) With vim, very little. gvim is a soft link to the vim binary, and that binary is linked with the UI toolkit. We could second-guess that and make gvim its own binary, but that will break `vim -g` and is itself a POLA problem. When I took over the port, there was vim (+gtk2) and vim-lite (TUI only). I changed it to vim, vim-console, and vim-tiny, as that made much more sense to me. I got angry emails for MONTHS about it. Making the default vim be console-only makes so much more sense to me, but I'm pretty hesitant to change things unless there's a whole lot of buy-in from our user base. In an ideal world, vim would install console vim, and vim-gtk3 would install a gtk3-linked gvim. We could make vim be console, and vim-gtk3 a separate (and conflicting) package, but I'd predict an equal number of people in a panic over their GUI vim disappearing. I'm not sure how to resolve it.