Bug 264098

Comment 1 Kubilay Kocak 2022-05-21 02:21:57 UTC

I believe this is "works as intended" after ports 620f205539a4 ... quoting:

This commit completely rewires the vim ports. It includes the following:

* `vim' is now a TUI-only package. It is what the `vim-console' port
  was.

* `vim-gtk3' includes the TUI binary (vim) and a GTk3-backed GUI. It is
  what the `vim' port was.

* Each GUI toolkit has a separate package. There is vim-gtk3, -gtk2,
  -motif, -athena, and -x11.

Regarding the X11 (-x11) flavour, from ports f3da483a6b84 ...

Remove x11 flavor. It adds xclip support but doesn't contain a GUI,
making it more confusing than helpful.

and later ports de02b1a9d209 ...

As requested by many (and based on a patch from scf), restore the x11
flavor. The x11 flavor is a bit odd; it doesn't actually include an X
GUI. As a result, when Vim got flavorized I dropped it as I thought
it was vestigial. What the x11 flavor actually provides is support for
some X interaction (mainly xclipboard), and is highly useful to people
who run console Vim within X.

Vim GUI options are available in and via the following ports/packages:

* Each GUI toolkit has a separate package. There is vim-gtk3, -gtk2,
  -motif, -athena, and -x11.

@Adam If there's something not fully understood here, please re-open and re-assign as appropriate.

Comment 2 Kubilay Kocak 2022-05-21 02:23:59 UTC

See also: UPDATING entry for all vim users via ports 6e6d25870c13

A) FreeBSD used to have a POLA (or something similar) policy where changes were supposed to be limited to the least affect (of change on the user).

B) vim-x11 has for years has been able to create a suitable GUI (gvim) application

C) stating that there are now various "flavors" of (FBSD) vim does not explicitly state that "vim-x11" will no longer be able to produce a GUI version (as before) and that one of the other "flavors" must be explicitly used instead

D) knowing that there are/were other "gui" options (ie; gtk2/gtk3, etc.) was never an issue before with vim-x11 when wanting to obtain "gvim"

E) these changes, as they are, have broken a very long and well established expectation of what "vim-x11" was able to produce

F) breaking out the different VIM GUI versions may make sense in many ways, 
but it would be nice, and polite, if the port listing, UPDATING file, the Makefile, and "pkg-descr" should all explicily state that "vim-x11" will no longer produce a GUI version (gtk2/gkt3, whatever) as it did in the past

Comment 4 Adam Weinberger 2022-06-04 07:44:48 UTC

(In reply to Jim D. from comment #3)

vim-x11 not providing a GUI wasn't my choice. The vim codebase itself no longer includes an x11 GUI. For a while now, vim GUI=x11 has essentially just been xclipboard support. That's actually why I removed the x11 flavor entirely, because I figured nobody would want to use it now that the GUI was no longer included. Turns out many people counted on the xclipboard support, so I added the flavor back.

Regarding POLA, I sent emails to ports@FreeBSD.org (with a request for comments which generated a lengthy thread) about 2 months before I made the change, sent emails to ports@ and ports-announce@ when I made the change, put an entry about it in UPDATING, and changed the pkg-descr to describe exactly what the x11 flavor does. I'm not sure what else I could have done.

Comment 5 Adam Weinberger 2022-06-04 07:47:36 UTC

I forgot to mention this: when upstream vim removed all the X11 GUI code from the codebase, they also removed the Athena GUI. The Motif GUI (the vim-motif package, or editors/vim@motif flavor) is the best basic X11 GUI we have now.

Comment 6 Kubilay Kocak 2022-06-04 08:31:53 UTC

(In reply to Adam Weinberger from comment #4)

Perhaps a contributing factor is the naming of this port/flavor, with X11 implying (all over the tree, as a defacto thing), some GUI'ness, when this is not the case.

Can we perhaps improve the user experience and risk of POLA violation here by changing the name? If a name change is not suitable, can we think of any other ways to improve the situation? Could the bits provided by -x11 live elsewhere without compromising on the benefits/aims of the recent refactor?

^Triage: Re-open and re-assign post comment 3 and this comment for consideration.

Comment 7 Adam Weinberger 2022-06-04 11:39:42 UTC

(In reply to Kubilay Kocak from comment #6)

x11 is what vim calls it. It's completely not in keeping with what we use -x11 packages for, but vim users who compile with GUI=x11, this is what they expect to get.

(In reply to Adam Weinberger from comment #7)

I think that the simplest thing about this vim/x11 "stuff" is to clearly state in the various places mentioned before that "vim-x11" should no longer be used to obtain a VIM GUI application and that users wanting a VIM GUI then MUST select one of the .... VIM ports. Then "vim-x11" can be left for whomever wants or needs the X11 specific functions/features.

So keep the package/ports changes made for FBSD VIM but help us 'old timers' over the hump of making the changeover by explicitly stating: "use vim-gtk2, or ..., instead of vim-x11 if you want a VIM GUI". Just saying that there (now) are other "flavors" of VIM doesn't make that clear by itself.

I use gvim thousands of times over a period of several months, so this changeover is a big deal for me, but now I have a better understanding that I didn't have when I started up FBSD-13.1.

Comment 9 Adam Weinberger 2022-10-16 15:53:36 UTC

Closing this out. I've received no further reports of confusion, so I think I'll let the descriptions stand as they are.

Just as a frame-of-reference, "Linux" automatically searches for "vim-x11" when yum/dnf/apt is used to install "gvim". Even in Linux 9 versions.

I have been using FreeBSD much, much, longer than Linux.

I would just like to see a more "declartive/assertive" statement about having to choose one of the specific vim-gui packages rather than just blithely stating that they exist. That to me always indicated an option - one that I could follow or ignore. Now - it is no longer an option if one wants a (traditional?) vim gui from FBSD.