On Fri, Jul 03, 2020 at 11:08:01AM +0200, Till Maas wrote:
On Tue, Jun 30, 2020 at 09:01:21AM +0000, Zbigniew Jędrzejewski-Szmek
> On Mon, Jun 29, 2020 at 05:52:07PM +0200, Till Maas wrote:
> > On Mon, Jun 29, 2020 at 08:16:29AM -0400, Gerald Henriksen wrote:
> > > While it may be worth vim making themselves better, it really doesn't
> > > change the argument.
> > >
> > > Even a friendlier vim is still going to be far to strange and
> > > confusing to somebody just looking to quickly change a setting and get
> > > on with Fedora.
> > The argument in the change proposal is that users might not know what is
> > going on when they run `git commit` and vi instead of nano is opened. It
> > does not mention "quickly changing a setting". Thinking more about
> > if someone has to use "git commit", they have probably changed
> > something with a tool. If this is a developer, they are probably using a
> > graphical IDE or a text editor on the console (or maybe a GUI text
> > editor).
> > But I guess the IDEs usually have git integration, so the user
> > would then not use "git commit".
> Plenty of people use graphical editors without git integration. But
> even if the editor has integration, people will often have been taught
> or have learnt themselves to use a git from the command line and will
> continue doing that. In many ways the cli is more convenient, so if you
> once learnt that, you're unlikely to switch away.
IT seems that the persona that is targeted by this change is changing a
lot. Initially, it was about newcomers but someone who already learned
git from the command-line does not seem to be a newcomer.
In my experience, some basic familiarity with git is nowadays fairly common.
Many people do some kind of data processing as students, and it may be
done using python or ipython notebook or R and open source libraries. Such
people will be using the terminal for this as a tool, without spending too
much time on bash or shell or other basic tools that we take for granted.
Another group is people who open the terminal based on some instructions
on the web. "Open a terminal, run 'systemctl edit foo.service', and add
So yeah, as I understand this, there is no one well defined target, but
rather various heterogeneous partially overlapping groups.
> > If they already use a console editor,
> > would it be typical that they do not set the EDITOR variable?
> In my experience, people set $EDITOR very rarely.
So all those people are happy with vi? IMHO an argument for changing
this would be that a lot of people are already changing EDITOR to nano,
so it makes sense to make it a default. If this is actually not the
case it is not very convincing to change this.
I think people may not be happy with something, but if it's not trivial to change
(and knowing that EDITOR may be set in bash configuration, but the
variable has to be exported, and then you need to reload the shell config because
the change does not take effect immediately is not trivial), they will
continue to use the default as long as they are able to get by.
> > And if they are using a graphical Editor, shouldn't
maybe that one be
> > defaulted to in graphical environments?
> I replied to that earlier — short summary is that having the editor pop
> outside of the terminal window is confusing. We want the default editor
> to be in-terminal and block the terminal until the edit is done.
There can also be some text in the console that explains that the user
should look at the window for the GUI editor and the editor helper could
block the console until the edit is done. git-mergetool works just fine
with meld, for example. Also I know people using gvimdiff instead of
This would be a possibility. But it's rather complicated, and requires
us to change the default anyway... And we'd need to do something
different for ssh connections. I like the original simple proposal better.