On Mon, Jun 29, 2020 at 06:11:58AM -0400, Pavel Valena wrote:
TL;DR please, +1 for nano, as "trial by fire" is not a good
experience for someone who just wants to get something done.
This is not "trial by fire", it is just a different interface than
people are used from notepad.exe. Vi may be not a good first experience
for someone who needs to edit a file once during the whole lifetime of
that os installation, but it is useful to those who have to do it lots
and lots of times or even if it is just "regularly".
I don't think this should be matter of preference of current
users or developers. Instead it's all about first impressions with a
Linux distro (or second..) for fresh users.
It should. I'm willing to argue that new users for Fedora try it,
because they got it recommended by someone who uses *and* likes it.
If you ignore the preferences of the current users you're cutting off
new users before they even try it.
A developer/poweruser can later change EDITOR to something their
familiar with, on purpose.
This is easy for one machine, but not if you have to maintain lots of
That is why I'm proposing to put that into the gnome-welcome-screen that
it adds EDITOR=… to the .bashrc only for that user. That way a regular
user has it set, while users created via useradd/adduser, kickstart, …
by more experienced users can have useful defaults for them.
Invoking vi for fresh user is like deciding for them they need to
learn vim <right now>, although they're learning how to use git f.e.,
and therefore worsens the experience they'll have IMO.
Well, they also have to learn that they can't copy and paste via
Ctrl+c/Ctrl+v in the commandline, but that is no reason for anyone to
change terminal behavior there.
(lots of git tutorials mention 'git commit -m "message"' anyway, so you
don't see an editor, and don't need to learn vim <right now>)
Btw. nano is just simple by the looks, but has lots of improvements
under the hood. With options like f.e. -xAFEGHuiBPUWzw it's a
completely different editor I use for my everyday work for years
that is fine, but none of those options will be enabled by default if
you have to work as sysadmin on a machine which isn't your primary one.
For "mostly unconfigured" machines we need a default which doesn't stand
in the way of fixing systems but enables working efficiently.
Unfortunately I think this arguing is moot, as the issue seems to have
been decided already anyway. I only remember one change "proposal" to
actually being pulled back in the last year, and I'm really disappointed
about having fake discussions on devel@ whilst the decision has already
been made. There are some where the Change proposal owner actually
considers other options which come up in the discussion, but for a few
of them there is not even an answer, and for some of them the only
Change proposal owner response is "but it is the best option".
All the best,