This is a tracking bug for Change: Make nano the default editor
For more details, see: https://fedoraproject.org/wiki/Changes/UseNanoByDefault
Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use.
Branching F33 Change Tracker bugs.
Today is the code complete (testable) deadline. All bugs should be at least in MODIFIED state by now to indicate they are testable.
(In reply to Ben Cotton from comment #0)
> This is a tracking bug for Change: Make nano the default editor
> For more details, see:
> Let's make Fedora more approachable, by having a default editor that doesn't
> require specialist knowledge to use.
From the above website:
Create a new subpackage of nano, called nano-default-editor.
nano-default-editor will include /etc/profile.d/nano.(sh|csh), which sets $EDITOR to nano.
nano-default-editor will be added to both @standard and @workstation-product in comps, so it gets installed by default everywhere.
This is not the best way to approach this.
On existing systems, installing nano-default-editor would also affect existing users.
This is not acceptable. The installation of nano-default-editor should only affect
new users, not already exsting ones.
Therefore a good solution would only add an entry for EDITOR or VISUAL to
/etc/defaults, so that only new users are affected, no?
I'm just messenger. You should take this up with the listed proposal owners.
(In reply to Ben Cotton from comment #3)
> I'm just messenger. You should take this up with the listed proposal owners.
That's Chris then, right?
(In reply to Corinna Vinschen from comment #2)
> On existing systems, installing nano-default-editor would also affect
> existing users.
> This is not acceptable. The installation of nano-default-editor should only
> new users, not already exsting ones.
I don't understand the question. What about "Will not apply to upgrades" is unclear or incorrect?
The problem I'm seeing is, you can't be sure that this package will never
be installed on existing systems by dependency or by accident. So the
package should go the least intrusive way in terms of existing systems.
Corinna, what is the /etc/defaults file you refer to? There is no such file on my system. Do you mean the /etc/default directory?
Could you please better describe your proposal? Ideally as a patch please.
Kamil, actually I thought about a change to the files in /etc/skel,
not in /etc/default. I'm sorry for any confusion here.
Given the default shell is bash, adding `export EDITOR=/usr/bin/nano'
to /etc/skel/.bashrc would probably be most helpful to default to
nano for new users only. This would also allow to add this seemlessly
to existing installations, I think.
The downside of this approach is that this requires to change the bash
Corinna, thank you for clarifying it! Now it is clear to me what you are proposing.
With the approach being used, if you have your own EDITOR variable set in your user profile, the system-wide one doesn't take effect.
Moreover, the nano-default-editor package makes it apply across the board with Bourne shells, C shells, and fish, while permitting a trivial user override.
If you don't want it, uninstalling the package reverts it back to "POSIX defaults" by unsetting EDITOR systemwide unless you've got your own setting locally.
This is all nice and well, but it doesn't address the problem I'm pointing out.
If this package makes it accidentally onto an already installed system you're
using at home, then you're the one and only affected user.
If this package makes it accidentally onto an already installed system with
300 accounts, the change affects up to 300 accounts, and you're forcing
up to 300 users to change their EDITOR setting in a single strike. You
also probably drive an administrator to insanity considering the number
of complaints. Yes, she could deinstall the package, but the productivity
damage is done.
What I'm trying to say is that the approach, even if being well-intentioned,
can have unforseen effects.
That's why I think an approach which only actually affects *new* users, in
contrast to *all* users on a system would be preferrable because it avoids
I'm not too worried that someone will accidentally install a package that no other packages should ever depend on....
Closing tracking bugs for F33. If your change didn't make it into F33 for some reason, please reopen this and NEEDINFO me.