Hi, Zdenek Dohnal wrote: > To be honest, I'm sad about the change.
It is just a default though, and I'll certainly change it on
my systems. But like many others, I too can still recall
(decades ago) being dumped into vi and having no clue how to
do anything -- including just exiting.
> I'm not sure if which other applications use the default editor, I know
> only git from those. So let's say I will talk about the editor which
> git-commit spawns during committing a change.
Anywhere EDITOR or VISUAL isn't set, plenty of tools default
to /bin/vi. It's much, much more than just git -- even if
that is a fairly common way for users to end up in vi these
days.
> What about this - Git could generate a message within the comments
> during commit:
>
> 'Using editor: {message}'
>
> In case of Vi:
>
> 'Using editor: Vi , for more info type :help'
>
>
> Or nano:
>
> 'Using editor: nano'
>
> CCing Git maintainer to see whether it can be implemented or not.
Doing this would clutter the instructions for making the
commit itself and would be a distraction IMO. I would also
be very hesitant to make such an adjustment to the default
git commit template anywhere but upstream.
While I very much prefer vim to nano myself, it's hard for
me to argue that dropping someone who's never used vi into
it is a great default. It's not nearly as convenient or
useful as it could be for a new user. It's wonderful and
powerful once you know it, but I don't think that makes it a
good default.
Since git is far from the only place a user might find
themselves in the default $EDITOR, we'd end up having to add
similar instructions for all (or many) of those tools.
(At that point, we'd be better off adding it to vi in some
manner -- and dealing with the inevatible fallout of what
that breaks. That all seems like far more work than it's
worth.)
I think the fact that we'd even need to include such
instructions for how to use the editor is a sign that the
editor might not be a great _default_.
With this change adding a nano-default or such subpackage,
perhaps other editor packages will eventually offer a
similar subpackage to make them the default? (Effectively
what Debian's got with the 'editor' alternative.)
Then users/admins who want to quickly deploy a different
system-wide default could do so (in a manner consistent with
how we're setting nano as the default)?
If the result is that more users learn about the wide
variety of useful and powerful editors available in Fedora,
that's a good outcome.
--
Todd
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
