We ship with vi installed by default, which is provided by the vim-minimal package. It works, but it's annoying and harder to use than normal vim.
vim is provided by the vim-enhanced package (3.3 MB installed), which depends on vim-common (29 MB installed). So this would add 32 MB total to the installed system.
Why don't we ship a more user-friendly editor by default on Workstation? For example, the Debian/Ubuntu family defaults to nano, which is a lot easier for most people to use.
nano
I would ship both.
Discussed today in the WG meeting.
Proposal 1: include vim-enhanced+vim-common, +7.8M, +32M installed Proposal 2: include nano, keep vim-minimal, +640K, +2.4M installed
Consider the Live media is "installed" but then is squashfs'd so it's probably close to the first size in terms of ISO impact.
Also consider, in the recovery use case, what we want to do is make sure we provide the user something they're reasonably familiar with. They can always install something else. I see a greater bang for the "buck" to include nano, since it has a way more user friendly interface than vim. So I'm +1 for Proposal 2. And -1 for Proposal 1.
Proposal 1: -1
Proposal 2: +1
At the meeting we rejected the proposal to install vim by default.
We agreed to install nano by default and make it our default terminal editor. I guess we should do that in the same way that Ubuntu does so (perhaps by setting $EDITOR someplace convenient).
What we don't have is someone to implement. I can update comps (that's easy) but figuring out the right place to set the EDITOR variable is harder as there are many places that could be done. Also, we need to consider that it could be disruptive to upgraded systems. Only newly-installed systems can be expected to have nano anyway.
@catanzaro, I think you misread what was decided at the meeting. If I counted it right, we had +4 votes and one 0 to add nano to the default install in addition to vim-minimal, but no vote was done to change $EDITOR default.
Until someone explains why it's a good idea to install nano but not make it the default, I'm -1.
In general I'm enthusiastic about investigating nano (or another editor) by default, but I think it needs a bit more time and consultation before we make a decision.
I could get on board with nano as the default editor. But perhaps the issue needs some visibility on desktop@ or even on devel@ and see if that's a big no go or not? Including nano on the ISO but not made the default editor, is a fairly risk free yet friendly move.
OK, so after failing to reach consensus last time, we spent all of today's Workstation WG meeting discussing this. We split it up into three distinct votes, of which vote 1 and vote 3 passed:
AGREED: Add nano to Workstation default install in addition to vi (without changing $EDITOR) (+1:5, 0:1, -1:1) (kalev, 14:54:57) AGREED: Proposal to change Workstation $EDITOR to nano does not pass (+1:3, 0:2, -1:1) (kalev, 14:56:03) AGREED: Workstation WG would like to change Fedora default editor from /usr/bin/vi to /usr/bin/nano (+1:5, 0:1, -1:0) (kalev, 14:57:05) ACTION: Son_Goku to submit a system wide proposal to change the default installed editor from vi to nano (kalev, 15:00:34) ACTION: mcatanzaro to add nano to workstation-product comps (mcatanzaro, 15:02:14)
This means that we move forward with adding nano to Workstation default comps. We do not change the $EDITOR just for Workstation (so that there's consistency between Fedora editors), but instead Workstation WG supports changing the system wide default (across all Fedora Editions) to swap out /usr/bin/vi with nano. Son_Goku is going to propose the system wide proposal.
Meeting logs: https://meetbot.fedoraproject.org/fedora-meeting-2/2019-11-18/workstation.2019-11-18-14.00.log.html
Metadata Update from @kalev: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
When editing comps, I discovered that nano is already present in standard, meaning it's already installed in other products, just not in Workstation. We still need a change proposal to make it $EDITOR though.
Comps PR: https://pagure.io/fedora-comps/pull-request/432
In case its unclear, Son_Goku is me (@ngompa). :smile:
Son_Goku
micro is more user friendly, with familiar, modern key bindings and more powerful then nano. It is already packaged in Fedora. But unfortunately package size is 15 M which is not suitable probably for default shipping.
micro
Metadata Update from @catanzaro: - Issue untagged with: meeting
I found one more interesting Vim-like editor in Rust but it is not packaged yet in official Fedora repos. Just for testing/fun: https://copr.fedorainfracloud.org/coprs/atim/amp/
Package size: 1.7 M Installed size: 4.7 M
As for features something in between Vi and Vim. Have syntax highlighting.
Change proposal for Fedora 33 https://fedoraproject.org/wiki/Changes/UseNanoByDefault
So nano is already included in comps, albeit not Fedora-wide.
The proposal to create /usr/bin/editor is likely to be as controversial (or more controversial) as the switch to nano, so I would mention that in the title of the change proposal.
Anyone can edit the wiki, so by all means go ahead. I was just trying to get the ball rolling on the change. I don't understand what's required to make it work, either generally or specifically.
I also don't care who is the feature owner - but it probably should be someone who can answer questions about it, and defend the various bits. I'm happy to tech edit the thing and make it look pretty, maybe at that point I'll grok enough details.
The change proposal has evolved a bit and now involves creating a nano subpackage that installs a conf file into /usr/lib/environment.d. Since this now involves changes to the nano package, we should talk to the nano maintainers and get them on board.
Metadata Update from @aday: - Issue status updated to: Open (was: Closed)
We proposed this as a F33 change, which was approved by FESCo. I'm reviving this issue so we can track implementing the change.
PR submitted to the nano package: https://src.fedoraproject.org/rpms/nano/pull-request/1
PR submitted to comps: https://pagure.io/fedora-comps/pull-request/516
Looks like this got fixed! Thanks @ngompa !
Metadata Update from @aday: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.