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 wrote: > > 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 this, > > > 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 > vimdiff. 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. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
