https://fedoraproject.org/wiki/Changes/UseNanoByDefault
== Summary ==
Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use.
== Owner == * Name: [[User:chrismurphy| Chris Murphy]] * Email: chrismurphy@fedoraproject.org
== Detailed Description ==
Users are exposed to the default editor when they use commands that call it. The main example here is something like <code>git commit</code>.
Fedora does not currently have a default terminal text editor, because the $EDITOR environment variable is unset by default. But a common scenario where users wind up in a terminal text editor is when using 'git commit'. By default, git picks vi. You need to spend time learning how to use it, for even basic editing tasks. This increases the barrier to entry for those who are switching to Fedora and don't know how to use vi. It also makes things hard for those who don't particularly want to learn how to use vi. (These arguments would apply just as well if git picked Vim. vi is like hard mode for Vim, with fewer features, missing syntax highlighting, and no indication of what mode you are in. Even Vim users may feel lost and bewildered when using vi.)
In contrast, Nano offers the kind of graphical text editing experience that people are used to, and therefore doesn't require specialist knowledge to use. It is already installed across most Fedora Editions and Spins. This proposal will make Nano the default editor, while continuing to install <code>vim-minimal</code> (which provides vi, but not Vim). People will still be able to call <code>vi</code> if they want to edit a file. It will also obviously be possible to change the default editor to vi or Vim, for those who want it.
Why make Nano default and vi optional, rather than the other way round? Because Nano is the option that everyone can use.
== Feedback ==
Pending ...
== Benefit to Fedora ==
* Makes the default editor across all of Fedora more approachable. * Nano is also mostly self-documenting, by displaying common keyboard shortcuts on-screen. * More in line with the default editor of other distributions.
== Scope == * Proposal owners: ** Modify comps to include nano Fedora wide. ** Create a new subpackage of <code>nano</code>, called <code>nano-editor</code>. ** <code>nano-editor</code> to include <code>/usr/lib/environment.d/10-nano.conf</code>, which sets <code>$EDITOR</code> to <code>nano</code>.
With this approach, if <code>nano</code> is uninstalled, the configuration will be removed with it. At the same time, installing nano on its own won't install the conf.
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/9522 #9522]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Will not apply to upgrades.
== How To Test ==
Run <code>export EDITOR="/usr/bin/nano"</code>.
== User Experience ==
Users running <code>git commit</code> will be able to just type their commit message, rather than having to learn about insert mode, and they'll be able to cut and paste without having to learn special shortcuts.
== Dependencies ==
No additional dependencies are required.
== Contingency Plan == The contingency plan is to revert the change by removing the <code>nano-editor</code> package.
* Contingency deadline: probably the beta? It's an easy change to revert. * Blocks release? If the change breaks the redirection to an editor, it should block the release. However, this is unlikely. * Blocks product? Potentially all.
== Documentation == As part of this change, it would be good to add instructions for changing the default editor to the [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs].
On 6/25/20 1:18 PM, Ben Cotton wrote:
Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use.
I would like to counter propose that we make ed the default editor :P
On 6/25/20 1:54 PM, Randy Barlow wrote:
I would like to counter propose that we make ed the default editor :P
Just in case it wasn't clear, I was joking here. I support nano as a default. Let's make Fedora easier for new users, especially those who are new to the command line and/or Linux.
On Thu, Jun 25, 2020 at 7:20 PM Ben Cotton bcotton@redhat.com wrote:
Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use.
One could argue that this adds to the experience!
(These arguments would apply just as well if git picked Vim. vi is like hard mode for Vim, with fewer features, missing syntax highlighting, and no indication of what mode you are in. Even Vim users may feel lost and bewildered when using vi.)
Not really and that's because we ship vim-minimal with sane defaults, unlike other distros.
In contrast, Nano offers the kind of graphical text editing experience that people are used to, and therefore doesn't require specialist knowledge to use.
Who are these people?
It is already installed across most Fedora Editions and Spins.
<shock />
- More in line with the default editor of other distributions.
It has been a nice and welcome point of difference.
Oh, well.
On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
In contrast, Nano offers the kind of graphical text editing experience that people are used to,
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers. As Fedora will never be used by end-users as it conflicts with Fedora's foundation Freedom. With each such step it takes more and more effort to make a new Fedora installation usable by a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).
Jan
On Thu, Jun 25, 2020 at 08:50:23PM +0200, Jan Kratochvil wrote:
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers. As Fedora will never be used by
How does changing the default editor make Fedora hostile to developers?
(I suspect you have a rather narrow definition of "developer" here...)
such step it takes more and more effort to make a new Fedora installation usable by a developer (setenforce 0, dnf remove bash-completion
That's an odd position to take; bash-completion is quite useful, far more so for "developers" than "normal" folks whose command line interaction is limited to pasting things in from random web pages or "curl | bash" invocations.
- Solomon
Hello,
On Thursday, June 25, 2020 12:50:23 PM MDT Jan Kratochvil wrote:
On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
In contrast, Nano offers the kind of graphical text editing experience that people are used to,
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers.
I'm a developer who has written, amongst other things, Fedora's implementation of pkg-config, the IRC software powering the IRC network Fedora uses to coordinate its efforts, various patches to software shipping in Fedora.
I use nano to write these programs. I use nano, quite happily, as my editor of choice since it was first released. Before that, I used pico and FreeBSD's ee editor.
I suspect many new developers are using graphical editors such as VS Code and gedit. Using vi or emacs does not imply any sense of development skill or authority -- if you like those editors, that is your choice, but that does not mean that they are a sensible choice for users new to the system who did not originally learn with them. I learned how to program using Borland TurboC on MS-DOS back in the 90s, and nano is a much closer match to that workflow than a modal editor such as vim, which is why I happily use nano.
Ariadne
Once upon a time, Jan Kratochvil jan.kratochvil@redhat.com said:
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers.
I've been setting $EDITOR and $VISUAL for ages (since long before Fedora existed, probably since before Red Hat existed).
As Fedora will never be used by end-users as it conflicts with Fedora's foundation Freedom.
I'm not sure why you think end-users can't use a free OS.
With each such step it takes more and more effort to make a new Fedora installation usable by a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).
I've run with SELinux enabled for years, rarely if ever causes problems for typical stuff.
I have no idea why you'd remove a useful tool like bash-completion. It has lots of things useful for developers.
Unless you are doing kernel development, why do you care what the kernel messages say? On my systems, they go by too fast to read anyway.
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
I'm not sure why you think end-users can't use a free OS.
First steps of end-users is to install Chrome, Spotify and VirtualBox. So there is left no advantage of a Free OS.
I've run with SELinux enabled for years, rarely if ever causes problems for typical stuff.
Sooner or later something does not work. I do not want to open this can of worms whether SELinux yes or not, it may be a good idea but IMNSHO it is not for a development machine.
I have no idea why you'd remove a useful tool like bash-completion. It has lots of things useful for developers.
I agree the idea of bash-completion is nice. But it is so severly incomplete it is more a burden than help. Unfortunately I no longer remember all the bugs I faced before I started removing it years ago but a simple one is:
$ wget -O somepackage.rpm https://... $ dnf install som<tab> <wait for a few minutes> $ dnf install sombok-
Unless you are doing kernel development, why do you care what the kernel messages say? On my systems, they go by too fast to read anyway.
When it locks up (during updating firmware on my Athlon machine) I see just a black screen. When I reboot without rhgb/quiet the problem is not reproducible as it happens only rarely. There are many reasons why kernels sometimes fail to boot, why to give up on troubleshooting?
Jan
On Thu, Jun 25, 2020 at 3:38 PM Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
I'm not sure why you think end-users can't use a free OS.
First steps of end-users is to install Chrome, Spotify and VirtualBox. So there is left no advantage of a Free OS.
They are popular but by no means universal. I don't install any of those three things.
I agree the idea of bash-completion is nice. But it is so severly incomplete it is more a burden than help. Unfortunately I no longer remember all the bugs I faced before I started removing it years ago but a simple one is:
$ wget -O somepackage.rpm https://... $ dnf install som<tab>
<wait for a few minutes> $ dnf install sombok-
You're right this is bad - i mistype things all the time and yet hit tab and it just stalls out and is faster to command C three times and start over.
Unless you are doing kernel development, why do you care what the kernel messages say? On my systems, they go by too fast to read anyway.
When it locks up (during updating firmware on my Athlon machine) I see just a black screen. When I reboot without rhgb/quiet the problem is not reproducible as it happens only rarely. There are many reasons why kernels sometimes fail to boot, why to give up on troubleshooting?
I think we need more complete bug reports about these kinds of problems, and fix them, rather than default to showing startup scroll. I don't have this problem very often and I use rawhide kernels. And where I run stable kernels I can't even remember the last time I needed to see the startup scroll for troubleshooting. It's easy to get it unhidden though - hit Esc.
On 6/25/20 4:11 PM, Chris Murphy wrote:
On Thu, Jun 25, 2020 at 3:38 PM Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
Unless you are doing kernel development, why do you care what the kernel messages say? On my systems, they go by too fast to read anyway.
When it locks up (during updating firmware on my Athlon machine) I see just a black screen. When I reboot without rhgb/quiet the problem is not reproducible as it happens only rarely. There are many reasons why kernels sometimes fail to boot, why to give up on troubleshooting?
I think we need more complete bug reports about these kinds of problems, and fix them, rather than default to showing startup scroll. I don't have this problem very often and I use rawhide kernels. And where I run stable kernels I can't even remember the last time I needed to see the startup scroll for troubleshooting. It's easy to get it unhidden though - hit Esc.
I agree with your points, but pressing ESC only reverses the "rhgb" part, the kernel output is still "quiet".
On Fri, 26 Jun 2020 01:34:19 +0200, Samuel Sieb wrote:
I agree with your points, but pressing ESC only reverses the "rhgb" part, the kernel output is still "quiet".
If the kernel really locks up it is locked up and no keys work anymore. Without "rhgb quiet" one can make a photo of the screen.
A better solution would be to use serial console all the time but the ethernet one does not work during crashes and physical serial hardware is no longer available in modern computers.
Jan
On 6/26/20 12:30 AM, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 01:34:19 +0200, Samuel Sieb wrote:
I agree with your points, but pressing ESC only reverses the "rhgb" part, the kernel output is still "quiet".
If the kernel really locks up it is locked up and no keys work anymore. Without "rhgb quiet" one can make a photo of the screen.
Is this something that happens to you often? The only very rare times that I've had to deal with this, it's been a consistent lockup, so I just need to remove the "quiet" on the next boot. No need to be spammed for the 99.999% of boots that have no problem. That's a terrible thing for users to see.
On Fri, 26 Jun 2020 09:36:05 +0200, Samuel Sieb wrote:
Is this something that happens to you often?
It was happening often on an Athlon computer which I retired recently. So no longer.
Or rather it still happens for me (X1 carbon 6th with docking station) but during switching to X when the screen remains black even when I am not using "rhgb quiet".
No need to be spammed for the 99.999% of boots that have no problem. That's a terrible thing for users to see.
I feel blind when I do not see what is happening and I feel scared it will lock up again and I will be unable to debug it. Besides that it is much more pretty to see what is happening and it makes the waiting time shorter.
All pros and no con. Yes, it is a personal preference. Yes, I understand most of computer users prefer "rhgb quiet". I have some doubts most of _Fedora_ users really prefer it.
Jan
On Friday, June 26, 2020 12:51:32 AM MST Jan Kratochvil wrote:
I feel blind when I do not see what is happening and I feel scared it will lock up again and I will be unable to debug it. Besides that it is much more pretty to see what is happening and it makes the waiting time shorter. All pros and no con. Yes, it is a personal preference. Yes, I understand most of computer users prefer "rhgb quiet". I have some doubts most of _Fedora_ users really prefer it.
There are lots of Fedora users, not just developers or "power users". Not many of them have any interest or knowledge of kernel or dracut debugging, especially now that systemd is part of the boot process. Those users who know how to debug that also know how to disable those cmdline options.
I agree with your points, but pressing ESC only reverses the "rhgb" part, the kernel output is still "quiet".
If the kernel really locks up it is locked up and no keys work anymore. Without "rhgb quiet" one can make a photo of the screen.
A better solution would be to use serial console all the time but the ethernet one does not work during crashes and physical serial hardware is no longer available in modern computers.
While I use a serial console all the time, after all low level Arm early boot process practically mandates it, I don't see what this has to do with this thread.
On Thu, Jun 25, 2020 at 11:38:13PM +0200, Jan Kratochvil wrote:
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
I'm not sure why you think end-users can't use a free OS.
First steps of end-users is to install Chrome, Spotify and VirtualBox. So there is left no advantage of a Free OS.
I've run with SELinux enabled for years, rarely if ever causes problems for typical stuff.
Sooner or later something does not work. I do not want to open this can of worms whether SELinux yes or not, it may be a good idea but IMNSHO it is not for a development machine.
I have no idea why you'd remove a useful tool like bash-completion. It has lots of things useful for developers.
I agree the idea of bash-completion is nice. But it is so severly incomplete it is more a burden than help. Unfortunately I no longer remember all the bugs I faced before I started removing it years ago but a simple one is:
$ wget -O somepackage.rpm https://... $ dnf install som<tab>
<wait for a few minutes> $ dnf install sombok-
disclaimer: I'm using zsh, not bash but it has the same issue. But IMO you can't really blame it - how is the completion to know that you want to install an RPM in the current directory? The correct way would be dnf install ./some<tab> and that completes immediately (on zsh). Does that work on bash?
Cheers, Peter
Unless you are doing kernel development, why do you care what the kernel messages say? On my systems, they go by too fast to read anyway.
When it locks up (during updating firmware on my Athlon machine) I see just a black screen. When I reboot without rhgb/quiet the problem is not reproducible as it happens only rarely. There are many reasons why kernels sometimes fail to boot, why to give up on troubleshooting?
Jan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, Jun 26, 2020 at 1:40 AM Peter Hutterer peter.hutterer@who-t.net wrote:
disclaimer: I'm using zsh, not bash but it has the same issue. But IMO you can't really blame it - how is the completion to know that you want to install an RPM in the current directory? The correct way would be dnf install ./some<tab> and that completes immediately (on zsh). Does that work on bash?
It does. However, if you're trying to avoid typing a path for dnf, you always get a space right after the folder name when you hit <tab> and you need to delete it if you want to move further down the tree. For me that's one of the most annoying things with bash completion for dnf.
On 6/25/20 4:48 PM, Alexander Ploumistos wrote:
On Fri, Jun 26, 2020 at 1:40 AM Peter Hutterer peter.hutterer@who-t.net wrote:
disclaimer: I'm using zsh, not bash but it has the same issue. But IMO you can't really blame it - how is the completion to know that you want to install an RPM in the current directory? The correct way would be dnf install ./some<tab> and that completes immediately (on zsh). Does that work on bash?
It does. However, if you're trying to avoid typing a path for dnf, you always get a space right after the folder name when you hit <tab> and you need to delete it if you want to move further down the tree. For me that's one of the most annoying things with bash completion for dnf.
But regardless, that's something to fix in the dnf bash completion scripts, not a reason to completely disable completion as the earlier poster said.
On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:
But regardless, that's something to fix in the dnf bash completion scripts, not a reason to completely disable completion as the earlier poster said.
TL;DR it regresses the original bash completion feature.
This will be always a catch up play. To make it working each completion script would need to be part of the package it is implementing completion for. Additionally it would need to be integrated into the program's commandline parsing as otherwise it will never be 100% matching. There were efforts to unify commandline parsing between programs but that never happened: GNU getopt_long, glib GOption, https://en.wikipedia.org/wiki/Getopt#In_other_languages
I have shown just 'dnf' but if you really want I can find arbitrary number of other such programs and bugs where the completion script implements things differently than the program itself.
This is why IMHO bash-completion is only an experimental unfinished feature and it should not be the default.
Jan
On 6/26/20 12:42 AM, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:
But regardless, that's something to fix in the dnf bash completion scripts, not a reason to completely disable completion as the earlier poster said.
TL;DR it regresses the original bash completion feature.
This will be always a catch up play. To make it working each completion script would need to be part of the package it is implementing completion for. Additionally it would need to be integrated into the program's commandline parsing as otherwise it will never be 100% matching. There were efforts to
I have no idea what you're talking about. The bash completion scripts are generally supplied by the package that they are for: # rpm -qf /usr/share/bash-completion/completions/dnf dnf-4.2.21-1.fc31.noarch
I have shown just 'dnf' but if you really want I can find arbitrary number of other such programs and bugs where the completion script implements things differently than the program itself.
The dnf one works fine. But if you don't like how specific ones work, then file bugs.
This is why IMHO bash-completion is only an experimental unfinished feature and it should not be the default.
It's a very useful feature for most people. If you don't like it, then uninstall it.
Btw, in the case of dnf or similar situations, you can force file completion by pressing ALT-/
On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:
On 6/26/20 12:42 AM, Jan Kratochvil wrote:
This will be always a catch up play. To make it working each completion script would need to be part of the package it is implementing completion for. Additionally it would need to be integrated into the program's commandline parsing as otherwise it will never be 100% matching. There were efforts to
I have no idea what you're talking about. The bash completion scripts are generally supplied by the package that they are for: # rpm -qf /usr/share/bash-completion/completions/dnf dnf-4.2.21-1.fc31.noarch
$ rpm -qlp bash-completion-2.8-8.fc32.noarch.rpm|grep ^/usr/share/bash-completion/completions/|wc -l 652
The dnf one works fine.
It does not as I have shown. Moreover it takes so much time to do dnf command completion and one always has to ctrl-c it anyway. That is because dnf should use cached results updated by cron and do not contact network during interactive cache queries. If one really wants most fresh data there is --refresh for that.
But if you don't like how specific ones work, then file bugs.
The bug is bash-completion itself, I do not see what does it try to solve, the best fix is just to remove it.
Jan
On 26/06/20 10:19 +0200, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:
The dnf one works fine.
It does not as I have shown. Moreover it takes so much time to do dnf command completion and one always has to ctrl-c it anyway. That is because dnf should use cached results updated by cron and do not contact network during interactive cache queries. If one really wants most fresh data there is --refresh for that.
That sounds like a good idea, and could be filed as a bug against dnf. I'd prefer if it's optional though, because for me 'sudo dnf install foo<TAB><TAB>' only takes seven seconds, not minutes, and that seems reasonable to me.
But if you don't like how specific ones work, then file bugs.
The bug is bash-completion itself, I do not see what does it try to solve, the best fix is just to remove it.
And you have that choice. Please don't claim to speak for all developers when you say the entire package is a bug or makes Fedora hostile to developers.
On Fri, Jun 26, 2020 at 12:27:39PM +0100, Jonathan Wakely wrote:
On 26/06/20 10:19 +0200, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:
The dnf one works fine.
It does not as I have shown. Moreover it takes so much time to do dnf command completion and one always has to ctrl-c it anyway. That is because dnf should use cached results updated by cron and do not contact network during interactive cache queries. If one really wants most fresh data there is --refresh for that.
That sounds like a good idea, and could be filed as a bug against dnf. I'd prefer if it's optional though, because for me 'sudo dnf install foo<TAB><TAB>' only takes seven seconds, not minutes, and that seems reasonable to me.
Seven seconds sounds like a horrible user experience. I would lose patience and start hitting ^C after around 3s.
On 26/06/20 14:59 +0200, Tomasz Torcz wrote:
On Fri, Jun 26, 2020 at 12:27:39PM +0100, Jonathan Wakely wrote:
On 26/06/20 10:19 +0200, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:
The dnf one works fine.
It does not as I have shown. Moreover it takes so much time to do dnf command completion and one always has to ctrl-c it anyway. That is because dnf should use cached results updated by cron and do not contact network during interactive cache queries. If one really wants most fresh data there is --refresh for that.
That sounds like a good idea, and could be filed as a bug against dnf. I'd prefer if it's optional though, because for me 'sudo dnf install foo<TAB><TAB>' only takes seven seconds, not minutes, and that seems reasonable to me.
Seven seconds sounds like a horrible user experience. I would lose patience and start hitting ^C after around 3s.
It depends what you're trying to do. If you want install something in the local directory, sure, it's awful. If you really do want dnf to query the repo and tell you all the packages that match 'foo*' then it's useful to be able to do that.
It only takes about 3s the second time, so maybe a lot of the time is getting the results into the disk cache, not the network operation.
On Friday, June 26, 2020 1:19:45 AM MST Jan Kratochvil wrote:
It does not as I have shown. Moreover it takes so much time to do dnf command completion and one always has to ctrl-c it anyway. That is because dnf should use cached results updated by cron and do not contact network during interactive cache queries. If one really wants most fresh data there is --refresh for that.
This used to be the case, and then something broke it a few releases ago. 3-4 releases ago, you even had to explicitly install sqlite to get dnf completion to work, but that has been fixed as far as I'm aware.
For me, dnf completion went from taking a few seconds to several minutes.
On 26/06/20 00:57 -0700, Samuel Sieb wrote:
On 6/26/20 12:42 AM, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:
But regardless, that's something to fix in the dnf bash completion scripts, not a reason to completely disable completion as the earlier poster said.
TL;DR it regresses the original bash completion feature.
This will be always a catch up play. To make it working each completion script would need to be part of the package it is implementing completion for. Additionally it would need to be integrated into the program's commandline parsing as otherwise it will never be 100% matching. There were efforts to
I have no idea what you're talking about. The bash completion scripts are generally supplied by the package that they are for: # rpm -qf /usr/share/bash-completion/completions/dnf dnf-4.2.21-1.fc31.noarch
I have shown just 'dnf' but if you really want I can find arbitrary number of other such programs and bugs where the completion script implements things differently than the program itself.
The dnf one works fine. But if you don't like how specific ones work, then file bugs.
Right, poor completion experiences are just bugs, and can be fixed, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1398373
On Fri, 26 Jun 2020 at 09:50, Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:
But regardless, that's something to fix in the dnf bash completion scripts, not a reason to completely disable completion as the earlier poster said.
TL;DR it regresses the original bash completion feature.
This will be always a catch up play. To make it working each completion script would need to be part of the package it is implementing completion for. Additionally it would need to be integrated into the program's commandline parsing as otherwise it will never be 100% matching. There were efforts to unify commandline parsing between programs but that never happened: GNU getopt_long, glib GOption, https://en.wikipedia.org/wiki/Getopt#In_other_languages
I have shown just 'dnf' but if you really want I can find arbitrary number of other such programs and bugs where the completion script implements things differently than the program itself.
This is why IMHO bash-completion is only an experimental unfinished feature and it should not be the default.
This is completely off-topic. But anyway, try sending messages over D-Bus using dbus-send. Then try using busctl with bash-completion, and you tell me which one you prefer. Are there some quirks and issues? Of course. Sometimes annoying, such as the dnf example. But also solvable, as the dnf example with ./, as someone pointed out. And overall it's muuuch much more useful than annoying, and for some tools you simply cannot do any useful work without it (see my initial example).
On Thu, Jun 25, 2020 23:38:13 +0200, Jan Kratochvil wrote:
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
I'm not sure why you think end-users can't use a free OS.
First steps of end-users is to install Chrome, Spotify and VirtualBox. So there is left no advantage of a Free OS.
That's anecdotal generalisation at best. I know enough people to disprove this statement using my set of anecdotal evidence---and it won't get us any where.
We are a FOSS community and we will keep promoting FOSS as much as we can. It is our First Foundation: https://docs.fedoraproject.org/en-US/project/
So, let's keep the discussion on topic: about the default editor.
El vie., 26 jun. 2020 a las 8:10, Ankur Sinha (sanjay.ankur@gmail.com) escribió:
On Thu, Jun 25, 2020 23:38:13 +0200, Jan Kratochvil wrote:
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
I'm not sure why you think end-users can't use a free OS.
First steps of end-users is to install Chrome, Spotify and VirtualBox. So there is left no advantage of a Free OS.
That's anecdotal generalisation at best. I know enough people to disprove this statement using my set of anecdotal evidence---and it won't get us any where.
We are a FOSS community and we will keep promoting FOSS as much as we can. It is our First Foundation: https://docs.fedoraproject.org/en-US/project/
So, let's keep the discussion on topic: about the default editor.
-- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Again, I'm not against the proposal, but I would prefer a better and sane discussion. Honestly most end users dislike the CLI. However I understand that discussion is not about "what is my preferred editor?". I understand that discussion is "if by chance an end user has to use CLI, he/she will not know what/how to do with vim". In such a case nano is easier (regardless that the argument about how hard is quitting vim is exaggerated, Ctrl+o is not easier that ZZ). A better for a newcomer that faces cli would be something like mcedit, but sadly it is not a standalone editor. But please, again, most end users prefer to use a gui editor. Is not about that a newcomer has to know **what** is KWrite/Kate/Gedit/etc, it's about that choices are of easy access through KDE/GNOME/MATE/XFce/etc graphical environments.
On Fri, Jun 26, 2020 at 08:39:46AM -0300, Sergio Belkin wrote:
In such a case nano is easier (regardless that the argument about how hard is quitting vim is exaggerated, Ctrl+o is not easier that ZZ).
I disagree, for the simple reason that ^O is discoverable (indeed, it and other hotkeys are displayed on-screen) whereas the user has no way to know that 'esc-ZZ' is the magic incantation that will get them back out.
(Or what to do should they have mashed some keys and got into an edit mode, and don't want to save their changes)
vi is quite powerful, but friendly to n00bs it is very much not.
- Solomon
On 26 June 2020 13:39:46 CEST, Sergio Belkin sebelk@gmail.com wrote:
El vie., 26 jun. 2020 a las 8:10, Ankur Sinha (sanjay.ankur@gmail.com) escribió:
On Thu, Jun 25, 2020 23:38:13 +0200, Jan Kratochvil wrote:
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
I'm not sure why you think end-users can't use a free OS.
First steps of end-users is to install Chrome, Spotify and VirtualBox. So there is left no advantage of a Free OS.
That's anecdotal generalisation at best. I know enough people to disprove this statement using my set of anecdotal evidence---and it won't get us any where.
We are a FOSS community and we will keep promoting FOSS as much as we can. It is our First Foundation: https://docs.fedoraproject.org/en-US/project/
So, let's keep the discussion on topic: about the default editor.
-- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Again, I'm not against the proposal, but I would prefer a better and sane discussion. Honestly most end users dislike the CLI. However I understand that discussion is not about "what is my preferred editor?". I understand that discussion is "if by chance an end user has to use CLI, he/she will not know what/how to do with vim". In such a case nano is easier (regardless that the argument about how hard is quitting vim is exaggerated, Ctrl+o is not easier that ZZ). A better for a newcomer that faces cli would be something like mcedit, but sadly it is not a standalone editor. But please, again, most end users prefer to use a gui editor. Is not about that a newcomer has to know **what** is KWrite/Kate/Gedit/etc, it's about that choices are of easy access through KDE/GNOME/MATE/XFce/etc graphical environments.
I think this is more a discussion about target groups. As far as I understand Fedora is aimed at everyone end users, devs, sysadmins and others alike. While I recognize that helping new users onboard is a good thing it seems that more often than not it is at the inconvenience of the not new. This particular issue is very small but part of a trend, it seems. The workstation installer, gnome and other seems to be arguing in the same way. The needs of new hypothetical users why does not want to learn and/or despises having to use a CLI is more important than the needs of the existing userbase. I think we can find a much better way of being welcoming to new users. One that fits those who just wants to edit some text and those who care about what they use. I like to think that I am part of everyone and I would love if we could deliver smart solutions that doesn't needlessly change default behaviour under the guise "advanced users will know how to configure this".
BR Markus
On Friday, June 26, 2020 5:50:01 AM MST Markus Larsson wrote:
I like to think that I am part of everyone and I would love if we could deliver smart solutions that doesn't needlessly change default behaviour under the guise "advanced users will know how to configure this".
We're getting to the point where there are so many things that "advanced users will know how to configure", it's absolutely absurd. You spend the first week with a fresh install customizing all the little things that used to be defaults, back when defaults were sane.
On Fri, Jun 26, 2020 at 08:39:46AM -0300, Sergio Belkin wrote:
Again, I'm not against the proposal, but I would prefer a better and sane discussion. Honestly most end users dislike the CLI. However I understand that discussion is not about "what is my preferred editor?". I understand that discussion is "if by chance an end user has to use CLI, he/she will not know what/how to do with vim". In such a case nano is easier (regardless that the argument about how hard is quitting vim is exaggerated, Ctrl+o is not easier that ZZ).
...
But please, again, most end users prefer to use a gui editor. Is not about that a newcomer has to know **what** is KWrite/Kate/Gedit/etc, it's about that choices are of easy access through KDE/GNOME/MATE/XFce/etc graphical environments.
Hi,
While users do prefer graphical editors, they fact that the editor window is completely separate from the terminal (non-modal) creates a big usability issue for the usecase of git. The problem is not so bad if a new editor window is spawned, because then it is clear to the user that the new window is in response to the terminal action. But when the user already has the editor open, most editors will simply pop up a new tab. The way I have seen this work in practice is that newbies see their git prompt "hang" and are oblivious to fact they they should switch to the editor. But even if they do switch, they will often just try to save the document, and not exit the editor. When you have someone at hand to explain it to you, it's not so bad, but without assistance, people get confused.
(More generally: for the edit command to work properly, git requires that command not exit until after the file has been edited and saved. This is trivial with any in-terminal editor, but guis most often operate in the fashion where the command either goes into the background to unblock the terminal, or sends a message to the already-running instance to open another file and exits. All this can usually be worked-around with specific options to the editor command, but is certainly confusing to newbies.)
Because of this additional complexity with gui editors, I'm very much convinced that a text editor is a better default. (And nano is good choice among text editors...).
Zbyszek
On Fri, 2020-06-26 at 08:39 -0300, Sergio Belkin wrote:
In such a case nano is easier (regardless that the argument about how hard is quitting vim is exaggerated, Ctrl+o is not easier that ZZ).
But nano *tells you* about ctrl+o.
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
But nano *tells you* about ctrl+o.
Well, it tells you about ^O - but when I hit SHIFT+6 O it doesn't do that! :P
On Fri, 2020-06-26 at 12:10 -0500, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
But nano *tells you* about ctrl+o.
Well, it tells you about ^O - but when I hit SHIFT+6 O it doesn't do that! :P
Sure. It's not perfect. But it gives you a fighting chance. And it at least tells you what it *is*. :P
On Thursday, June 25, 2020 2:38:13 PM MST Jan Kratochvil wrote:
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
I'm not sure why you think end-users can't use a free OS.
First steps of end-users is to install Chrome, Spotify and VirtualBox. So there is left no advantage of a Free OS.
I've run with SELinux enabled for years, rarely if ever causes problems for typical stuff.
Sooner or later something does not work. I do not want to open this can of worms whether SELinux yes or not, it may be a good idea but IMNSHO it is not for a development machine.
I definitely agree on taking out "rhgb quiet", that's annoying as all hell, not knowing what's going on during the boot process.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote:
On Thursday, June 25, 2020 2:38:13 PM MST Jan Kratochvil wrote:
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
I'm not sure why you think end-users can't use a free OS.
First steps of end-users is to install Chrome, Spotify and VirtualBox. So there is left no advantage of a Free OS.
I've run with SELinux enabled for years, rarely if ever causes problems for typical stuff.
Sooner or later something does not work. I do not want to open this can of worms whether SELinux yes or not, it may be a good idea but IMNSHO it is not for a development machine.
I definitely agree on taking out "rhgb quiet", that's annoying as all hell, not knowing what's going on during the boot process.
Why does the user need to know what's happening when system boots?
-- John M. Harris, Jr.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Saturday, June 27, 2020 1:06:01 PM MST Igor Raits wrote:
On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote:
I definitely agree on taking out "rhgb quiet", that's annoying as all hell, not knowing what's going on during the boot process.
Why does the user need to know what's happening when system boots?
So that they know what goes wrong, when something goes wrong.
On 2020-06-29 03:03, John M. Harris Jr wrote:
On Saturday, June 27, 2020 1:06:01 PM MST Igor Raits wrote:
On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote:
I definitely agree on taking out "rhgb quiet", that's annoying as all hell, not knowing what's going on during the boot process.
Why does the user need to know what's happening when system boots?
So that they know what goes wrong, when something goes wrong.
+1
- I have been routinely getting rid of "rhgb quiet" for as long as it has been around - but it is become much less simple to do in recent years . .
P.
On 6/28/20 10:03 AM, John M. Harris Jr wrote:
On Saturday, June 27, 2020 1:06:01 PM MST Igor Raits wrote:
On Sat, 2020-06-27 at 09:58 -0700, John M. Harris Jr wrote:
I definitely agree on taking out "rhgb quiet", that's annoying as all hell, not knowing what's going on during the boot process.
Why does the user need to know what's happening when system boots?
So that they know what goes wrong, when something goes wrong.
I don't know what users you have, but 95% of the people I've setup with Fedora would be confused or disturbed by the kernel spew during boot and wouldn't have any idea what to do with it if something went wrong. The other 5% (including me) would not want it by default and would be able to enable it if necessary.
On Thu, Jun 25, 2020 at 8:50 PM Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
In contrast, Nano offers the kind of graphical text editing experience that people are used to,
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers. As Fedora will never be used by end-users as it conflicts with Fedora's foundation Freedom. With each such step it takes more and more effort to make a new Fedora installation usable by a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).
I must be a very weird (fedora) developer. I have never done any of those three things :)
FWIW, I embrace the "EDITOR=nano by default" change so hard that I need to be careful not to squeeze too hard.
Setting nano as default editor (or installing it on Server Edition) is the first thing I do on every fresh fedora install. Still, every time vi(m) opens for some reason, I feel like being thrown into cold water (or into an exam situation, unprepared) - I still don't know any vi commands other than :q, :q!, and :wq after more than a decade of using as my primary OS.
Once a FESCo ticket exists for this Change, it'll have my +1 vote. Fabio
On Thu, Jun 25, 2020 at 12:50 PM Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
In contrast, Nano offers the kind of graphical text editing experience that people are used to,
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers.
This is hyperbole. All of the working group members are developers and the change was approved +9 to -1. The idea the vast majority of the working group wants to make Fedora hostile to themselves is nonsense.
I use vi out of habit (I learned it when I was young and in college ... and I'll skip the rest of the story) not because I like it. It's almost a comedy show if you haven't already been indoctrinated. I never recommend it. It would be like recommending teletype, which by the way is a neat skill to have, but to make it the default everywhere? Come on.
A better strategy is to appeal to the broader community that in fact vim users really need it to be the default editor because changing the default is harder than figuring out how to quit vim.
As Fedora will never be used by> end-users as it conflicts with Fedora's foundation Freedom. With each such step it takes more and more effort to make a new Fedora installation usable by a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).
dnf remove bash-completion makes Fedora *more* usable? :head explodes:
On Thu, Jun 25, 2020 at 01:34:33PM -0600, Chris Murphy wrote:
On Thu, Jun 25, 2020 at 12:50 PM Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
In contrast, Nano offers the kind of graphical text editing experience that people are used to,
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers.
This is hyperbole. All of the working group members are developers and the change was approved +9 to -1. The idea the vast majority of the working group wants to make Fedora hostile to themselves is nonsense.
They are not true Scotsmen^Wdevelopers.
On 25/06/20 13:34 -0600, Chris Murphy wrote:
On Thu, Jun 25, 2020 at 12:50 PM Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
In contrast, Nano offers the kind of graphical text editing experience that people are used to,
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers.
This is hyperbole. All of the working group members are developers and the change was approved +9 to -1. The idea the vast majority of the working group wants to make Fedora hostile to themselves is nonsense.
I use vi out of habit (I learned it when I was young and in college ... and I'll skip the rest of the story) not because I like it. It's almost a comedy show if you haven't already been indoctrinated. I never recommend it. It would be like recommending teletype, which by the way is a neat skill to have, but to make it the default everywhere? Come on.
A better strategy is to appeal to the broader community that in fact vim users really need it to be the default editor because changing the default is harder than figuring out how to quit vim.
As Fedora will never be used by> end-users as it conflicts with Fedora's foundation Freedom. With each such step it takes more and more effort to make a new Fedora installation usable by a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).
dnf remove bash-completion makes Fedora *more* usable? :head explodes:
dnf remove bash-c<TAB>
On 25/06/20 20:50 +0200, Jan Kratochvil wrote:
On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
In contrast, Nano offers the kind of graphical text editing experience that people are used to,
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers. As Fedora will never be used by end-users as it conflicts with Fedora's foundation Freedom. With each such step it takes more and more effort to make a new Fedora installation usable by a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).
As a developer, I don't disable any of those.
Bash's own built-in completion causes me more issues than bash-completion does, try 'ls $HOME/<TAB>' without the direxpand option set, and tell me what on earth that is for.
Apart from sshd settings (which can now be set in /etc/ssh/ssh_config.d - hoorah!) the only thing I absolutely insist on changing on a new Fedora install is to disable abrt. No, I don't want to report it to bugzilla every time a unit test or quick hacked together piece of code terminates abnormally.
Anyway, I find it hard to believe that serious developers are unable/unwilling to set their own choice of EDITOR. A systemwide default EDITOR=nano shouldn't cause them any real difficulty.
On Thu, 25 Jun 2020 21:58:28 +0200, Jonathan Wakely wrote:
try 'ls $HOME/<TAB>' without the direxpand option set, and tell me what on earth that is for.
It works as expected, what is the problem? Using ctrl-e instead of direxpand but keeping there $HOME/ may be what one wants.
the only thing I absolutely insist on changing on a new Fedora install is to disable abrt. No, I don't want to report it to bugzilla every time a unit test or quick hacked together piece of code terminates abnormally.
ABRT primarily crashes machine used for development. I gave up on reopening the Bug after it always gets EOL-closed unfixed: -fsanitize=address locks up abrt-hook-ccpp https://bugzilla.redhat.com/show_bug.cgi?id=1164548
Jan
On 6/25/20 12:58 PM, Jonathan Wakely wrote:
Anyway, I find it hard to believe that serious developers are unable/unwilling to set their own choice of EDITOR. A systemwide default EDITOR=nano shouldn't cause them any real difficulty.
I second that. I'm the guy who gets annoyed at non-vi editors because I tend to fill files in them with hjkl's due to muscle memory of 40 years of vi usage. You'll pull vi out of my cold dead hands. I'm still quite capable of setting $EDITOR in my own startup files. Pretty much anyone that has figured out and prefers vi (or emacs or whatever) knows how to set $EDITOR.
bob
On 26 June 2020 20:08:53 CEST, Robert Relyea rrelyea@REDHAT.COM wrote:
On 6/25/20 12:58 PM, Jonathan Wakely wrote:
Anyway, I find it hard to believe that serious developers are unable/unwilling to set their own choice of EDITOR. A systemwide default EDITOR=nano shouldn't cause them any real difficulty.
I second that. I'm the guy who gets annoyed at non-vi editors because I tend to fill files in them with hjkl's due to muscle memory of 40 years of vi usage. You'll pull vi out of my cold dead hands. I'm still quite capable of setting $EDITOR in my own startup files. Pretty much anyone that has figured out and prefers vi (or emacs or whatever) knows how to set $EDITOR.
That's not really the point. The point is that yet again more or less fictional future users needs comes before the needs of current actual users. As time goes by it seems the list of configuration changes needed to make a system usable (subjectively yes) grows. What was default was changed and since doing it the easy way only annoyed current users the easy way was chosen. I'm getting tired of this but I guess it's time to accept that I'm just one of those grumpy old neckbeard now.
Markus
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Thu, Jun 25, 2020 at 08:50:23PM +0200, Jan Kratochvil wrote:
This is another step trying to make Fedora end-user friendly while the only effect is making it hostile to developers. As Fedora will never be used by end-users as it conflicts with Fedora's foundation Freedom. With each such step it takes more and more effort to make a new Fedora installation usable by a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).
Fedora, the Project, has a lot of developers involved. Some of us are interested in making things just for our own use -- that's fine. Others are very interested in making solutions that are actually used by these end-users -- and it turns out they're reasonably successful, because we actually *have* plenty of non-developer end users.
But, if you don't like our offerings that are targetted that way, I suggest you make a spin or remix that has all of defaults _you_ want. Make it appeal to the specific developer audience you have in mind with the things that make sense to you, and see who else is interested in collaborating on it.
On Fri, 26 Jun 2020 02:25:24 +0200, Matthew Miller wrote:
But, if you don't like our offerings that are targetted that way, I suggest you make a spin or remix that has all of defaults _you_ want.
So FESCo has decided and there is no point of discussing this Change, that is how it will be and any resistance is futile? The subject even says it is a "Change _proposal_".
Some replies also do not like this change, I am not alone. Still it looks like there area really more votes for this change than against it. Fine with me.
BTW this change (contrary to other ones I mentioned) is not such a problem as it is overridable in $HOME/.bashrc so it does not really need a distro spin.
Jan
On 6/26/20 12:27 AM, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 02:25:24 +0200, Matthew Miller wrote:
But, if you don't like our offerings that are targetted that way, I suggest you make a spin or remix that has all of defaults _you_ want.
So FESCo has decided and there is no point of discussing this Change, that is how it will be and any resistance is futile? The subject even says it is a "Change _proposal_".
Some replies also do not like this change, I am not alone. Still it looks like there area really more votes for this change than against it. Fine with me.
From all the replies here, yours is the only one I've seen that's really against it.
BTW this change (contrary to other ones I mentioned) is not such a problem as it is overridable in $HOME/.bashrc so it does not really need a distro spin.
It's even easier than that. If you read the details, there will be a specific package that you can uninstall to remove the config.
On Fri, 26 Jun 2020 09:38:06 +0200, Samuel Sieb wrote:
On 6/26/20 12:27 AM, Jan Kratochvil wrote:
Some replies also do not like this change, I am not alone. Still it looks like there area really more votes for this change than against it. Fine with me.
From all the replies here, yours is the only one I've seen that's really against it.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On 6/26/20 12:44 AM, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 09:38:06 +0200, Samuel Sieb wrote:
On 6/26/20 12:27 AM, Jan Kratochvil wrote:
Some replies also do not like this change, I am not alone. Still it looks like there area really more votes for this change than against it. Fine with me.
From all the replies here, yours is the only one I've seen that's really against it.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
That was a pretty mild one, but yes, I see there was another much stronger one against it. But still, there are far more that approve of this change, even the vim users.
On Fri, Jun 26, 2020 at 8:30 AM Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Fri, 26 Jun 2020 02:25:24 +0200, Matthew Miller wrote:
But, if you don't like our offerings that are targetted that way, I suggest you make a spin or remix that has all of defaults _you_ want.
So FESCo has decided and there is no point of discussing this Change, that is how it will be and any resistance is futile? The subject even says it is a "Change _proposal_".
I don't see where Matthew suggested that FESCo was being subverted in that reply. The process for changes is they're sent to the list for discussion, and that's what's happening right now, and then FESCo allegedly takes this discussion into account when they vote for the feature in a (I think it's 2 weeks) meeting post the allotted time. Matthew was simply pointing out that if you don't like the change there's alternative options you can follow by making the vim4EVAH Fedora spin or remix or what ever you like!
Some replies also do not like this change, I am not alone. Still it looks like there area really more votes for this change than against it. Fine with me.
And I see a lot of replies that are very positive for the change.
BTW this change (contrary to other ones I mentioned) is not such a problem as it is overridable in $HOME/.bashrc so it does not really need a distro spin.
There's numerous ways to change the default editor, this is purely for the default so new users have a more positive experience. While I am personally a vim user I can fully understand the change. I'm sure regular vim users can work out how to change the default back, emacs users are unaffected, they're use to having to change the default ;-)
I am reading this thread and seeing a lot of "this will make it easy on end users" and "this will piss developers off." How many? Who? Without data to back those statements they are just examples of hyperbole built upon personal beliefs.
It should really be no more effort than running your puppet agent or an ansible job. Those are minor configuration changes and are easily automated.
Also, stopdisablingselinux.com ;)
On 6/25/2020 2:50 PM, Jan Kratochvil wrote:
With each such step it takes more and more effort to make a new Fedora installation usable by a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).
On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/UseNanoByDefault
== Summary ==
Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use.
My only regret is that I have but one +1 to give to this proposal!
On Thu, Jun 25, 2020 at 1:21 PM Adam Williamson adamwill@fedoraproject.org wrote:
My only regret is that I have but one +1 to give to this proposal!
Wait, wait, wait. Aren't you Canadian?
I don't really care much one way or the other about the proposal. I've learned enough vi to get by. I'll give nano a try and change the default if I don't like it.
On Thu, Jun 25, 2020 at 9:21 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/UseNanoByDefault
== Summary ==
Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use.
My only regret is that I have but one +1 to give to this proposal!
Here's another one. +1
On 6/25/20 10:18 AM, Ben Cotton wrote:
** Modify comps to include nano Fedora wide.
"nano" is already included by default. Did you mean this to say you'll include the new "nano-editor" package by default?
** Create a new subpackage of <code>nano</code>, called <code>nano-editor</code>. ** <code>nano-editor</code> to include <code>/usr/lib/environment.d/10-nano.conf</code>, which sets <code>$EDITOR</code> to <code>nano</code>.
With this approach, if <code>nano</code> is uninstalled, the configuration will be removed with it. At the same time, installing nano on its own won't install the conf.
I understand that lots of people prefer a simple editor, so I'm fine with this change given that I can revert it by removing that one extra package.
On Thu, Jun 25, 2020 at 12:40 pm, Samuel Sieb samuel@sieb.net wrote:
"nano" is already included by default. Did you mean this to say you'll include the new "nano-editor" package by default?
Yes. I already fixed the wiki page to clarify that we don't need to install nano, but I forgot to clarify that we will install nano-editor by default.
On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro mcatanzaro@gnome.org wrote:
Yes. I already fixed the wiki page to clarify that we don't need to install nano, but I forgot to clarify that we will install nano-editor by default.
BTW maybe nano-editor is not the best name for the subpackage, considering it will not include the nano text editor, but rather a conf snippet to set $EDITOR. Any alternative naming proposals?
On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro mcatanzaro@gnome.org wrote:
Yes. I already fixed the wiki page to clarify that we don't need to install nano, but I forgot to clarify that we will install nano-editor by default.
BTW maybe nano-editor is not the best name for the subpackage, considering it will not include the nano text editor, but rather a conf snippet to set $EDITOR. Any alternative naming proposals?
nano-default ?
On Thu, Jun 25, 2020 at 1:58 PM Chris Murphy lists@colorremedies.com wrote:
On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro mcatanzaro@gnome.org wrote:
Yes. I already fixed the wiki page to clarify that we don't need to install nano, but I forgot to clarify that we will install nano-editor by default.
BTW maybe nano-editor is not the best name for the subpackage, considering it will not include the nano text editor, but rather a conf snippet to set $EDITOR. Any alternative naming proposals?
nano-default ?
We're using zram-generator-defaults for this. https://koji.fedoraproject.org/koji/buildinfo?buildID=1527737
Which is better? default or defaults? I don't have a preference.
On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
On Thu, Jun 25, 2020 at 1:58 PM Chris Murphy lists@colorremedies.com wrote:
On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro mcatanzaro@gnome.org wrote:
Yes. I already fixed the wiki page to clarify that we don't need to install nano, but I forgot to clarify that we will install nano-editor by default.
BTW maybe nano-editor is not the best name for the subpackage, considering it will not include the nano text editor, but rather a conf snippet to set $EDITOR. Any alternative naming proposals?
nano-default ?
We're using zram-generator-defaults for this. https://koji.fedoraproject.org/koji/buildinfo?buildID=1527737
Which is better? default or defaults? I don't have a preference.
I went with "-defaults" in this case because the package provides "the default configuration", i.e. "defaults".
This doesn't translate exactly to the nano case, which is about making the program the default "plugin" in another program (git).
Zbyszek
On Fri, Jun 26, 2020 at 9:14 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
Which is better? default or defaults? I don't have a preference.
I went with "-defaults" in this case because the package provides "the default configuration", i.e. "defaults".
This doesn't translate exactly to the nano case, which is about making the program the default "plugin" in another program (git).
What about something like "default-editor"? That way it's more obvious from the name what it actually does. If we later decide to change the default editor, we update that package (and spins/labs, power users, etc can exclude that package in kickstarts if they don't want it)
Dne 26. 06. 20 v 15:17 Ben Cotton napsal(a):
On Fri, Jun 26, 2020 at 9:14 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
Which is better? default or defaults? I don't have a preference.
I went with "-defaults" in this case because the package provides "the default configuration", i.e. "defaults".
This doesn't translate exactly to the nano case, which is about making the program the default "plugin" in another program (git).
What about something like "default-editor"?
Shouldn't it be independent package then? Or shouldn't all editors have subpackage like this?
Vít
That way it's more obvious from the name what it actually does. If we later decide to change the default editor, we update that package (and spins/labs, power users, etc can exclude that package in kickstarts if they don't want it)
On 26/06/20 13:11 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
On Thu, Jun 25, 2020 at 1:58 PM Chris Murphy lists@colorremedies.com wrote:
On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro mcatanzaro@gnome.org wrote:
Yes. I already fixed the wiki page to clarify that we don't need to install nano, but I forgot to clarify that we will install nano-editor by default.
BTW maybe nano-editor is not the best name for the subpackage, considering it will not include the nano text editor, but rather a conf snippet to set $EDITOR. Any alternative naming proposals?
nano-default ?
We're using zram-generator-defaults for this. https://koji.fedoraproject.org/koji/buildinfo?buildID=1527737
Which is better? default or defaults? I don't have a preference.
I went with "-defaults" in this case because the package provides "the default configuration", i.e. "defaults".
This doesn't translate exactly to the nano case, which is about making the program the default "plugin" in another program (git).
This is not really about Git, and it's certainly not a "plugin".
Obeying EDITOR is required by POSIX e.g. see https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_...
Note that POSIX says "The default editor shall be vi." But that means when EDITOR isn't set. If the system or a user sets EDITOR to something else, it's still POSIX-conforming.
On Fri, Jun 26, 2020 at 03:37:59PM +0100, Jonathan Wakely wrote:
On 26/06/20 13:11 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
On Thu, Jun 25, 2020 at 1:58 PM Chris Murphy lists@colorremedies.com wrote:
On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro mcatanzaro@gnome.org wrote:
Yes. I already fixed the wiki page to clarify that we don't need to install nano, but I forgot to clarify that we will install nano-editor by default.
BTW maybe nano-editor is not the best name for the subpackage, considering it will not include the nano text editor, but rather a conf snippet to set $EDITOR. Any alternative naming proposals?
nano-default ?
We're using zram-generator-defaults for this. https://koji.fedoraproject.org/koji/buildinfo?buildID=1527737
Which is better? default or defaults? I don't have a preference.
I went with "-defaults" in this case because the package provides "the default configuration", i.e. "defaults".
This doesn't translate exactly to the nano case, which is about making the program the default "plugin" in another program (git).
This is not really about Git, and it's certainly not a "plugin".
That's why I put the word in quotes. I think we all know what the relationship between git and editor is in this case and I didn't want to waste words to formulate this more precisely for no benefit.
Obeying EDITOR is required by POSIX e.g. see https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_...
Note that POSIX says "The default editor shall be vi." But that means when EDITOR isn't set. If the system or a user sets EDITOR to something else, it's still POSIX-conforming.
Personally, I don't care so much about what POSIX says. But not to worry: in this case $EDITOR *will* be set, so we're all POSIX-compliant ;)
Zbyszek
On Fri, 26 Jun 2020 at 10:40, Jonathan Wakely wrote:
Obeying EDITOR is required by POSIX e.g. see https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_...
Note that POSIX says "The default editor shall be vi." But that means when EDITOR isn't set. If the system or a user sets EDITOR to something else, it's still POSIX-conforming.
Thank you for the clarification and the reference. Clearly the POSIX standard is plain wrong. But this is not the right platform to discuss this issue.
Cheers, Orcan
On Thu, 2020-06-25 at 14:47 -0500, Michael Catanzaro wrote:
On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro mcatanzaro@gnome.org wrote:
Yes. I already fixed the wiki page to clarify that we don't need to install nano, but I forgot to clarify that we will install nano-editor by default.
BTW maybe nano-editor is not the best name for the subpackage, considering it will not include the nano text editor, but rather a conf snippet to set $EDITOR. Any alternative naming proposals?
nano-make-systemwide-default
does what it says on the tin!
...snip... == Scope ==
- Proposal owners:
** Modify comps to include nano Fedora wide. ** Create a new subpackage of <code>nano</code>, called <code>nano-editor</code>. ** <code>nano-editor</code> to include <code>/usr/lib/environment.d/10-nano.conf</code>, which sets <code>$EDITOR</code> to <code>nano</code>.
With this approach, if <code>nano</code> is uninstalled, the configuration will be removed with it. At the same time, installing nano on its own won't install the conf.
Are you sure this will work? I just ran a test, and putting a new config file inside /usr/lib/environment.d only works for Gnome, and doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal in the respective session and examining the environment variables). From what I gather in [1], systemd is not a standard way of interacting with the user's environment variables, and only Gnome has decided to use it. So this method of implementing this change seems to be making the default editor for Gnome be nano and not changing the defaults for anyone else.
-Ian
On Thu, Jun 25, 2020 at 3:41 PM Ian McInerney Ian.S.McInerney@ieee.org wrote:
...snip... == Scope ==
- Proposal owners:
** Modify comps to include nano Fedora wide. ** Create a new subpackage of <code>nano</code>, called <code>nano-editor</code>. ** <code>nano-editor</code> to include <code>/usr/lib/environment.d/10-nano.conf</code>, which sets <code>$EDITOR</code> to <code>nano</code>.
With this approach, if <code>nano</code> is uninstalled, the configuration will be removed with it. At the same time, installing nano on its own won't install the conf.
Are you sure this will work? I just ran a test, and putting a new config file inside /usr/lib/environment.d only works for Gnome, and doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal in the respective session and examining the environment variables). From what I gather in [1], systemd is not a standard way of interacting with the user's environment variables, and only Gnome has decided to use it. So this method of implementing this change seems to be making the default editor for Gnome be nano and not changing the defaults for anyone else.
We might want to do this as a profile.d snippet for all the major shells: bash/ksh, zsh, csh, and fish. That should work basically everywhere, afaik.
On Thu, Jun 25, 2020 at 9:04 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jun 25, 2020 at 3:41 PM Ian McInerney Ian.S.McInerney@ieee.org wrote:
...snip... == Scope ==
- Proposal owners:
** Modify comps to include nano Fedora wide. ** Create a new subpackage of <code>nano</code>, called <code>nano-editor</code>. ** <code>nano-editor</code> to include <code>/usr/lib/environment.d/10-nano.conf</code>, which sets <code>$EDITOR</code> to <code>nano</code>.
With this approach, if <code>nano</code> is uninstalled, the configuration will be removed with it. At the same time, installing nano on its own won't install the conf.
Are you sure this will work? I just ran a test, and putting a new config
file inside /usr/lib/environment.d only works for Gnome, and doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal in the respective session and examining the environment variables). From what I gather in [1], systemd is not a standard way of interacting with the user's environment variables, and only Gnome has decided to use it. So this method of implementing this change seems to be making the default editor for Gnome be nano and not changing the defaults for anyone else.
We might want to do this as a profile.d snippet for all the major shells: bash/ksh, zsh, csh, and fish. That should work basically everywhere, afaik.
Yes, that sounds like a better plan. I think that is also where most people would think to look for this first.
-Ian
On Thu, Jun 25, 2020, at 4:03 PM, Neal Gompa wrote:
On Thu, Jun 25, 2020 at 3:41 PM Ian McInerney Ian.S.McInerney@ieee.org wrote:
...snip... == Scope ==
- Proposal owners:
** Modify comps to include nano Fedora wide. ** Create a new subpackage of <code>nano</code>, called <code>nano-editor</code>. ** <code>nano-editor</code> to include <code>/usr/lib/environment.d/10-nano.conf</code>, which sets <code>$EDITOR</code> to <code>nano</code>.
With this approach, if <code>nano</code> is uninstalled, the configuration will be removed with it. At the same time, installing nano on its own won't install the conf.
Are you sure this will work? I just ran a test, and putting a new config file inside /usr/lib/environment.d only works for Gnome, and doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal in the respective session and examining the environment variables). From what I gather in [1], systemd is not a standard way of interacting with the user's environment variables, and only Gnome has decided to use it. So this method of implementing this change seems to be making the default editor for Gnome be nano and not changing the defaults for anyone else.
We might want to do this as a profile.d snippet for all the major shells: bash/ksh, zsh, csh, and fish. That should work basically everywhere, afaik.
I'd be -1 on the change, but if it's going to happen anyway, it should absolutely be done via an /etc/profile.d entry. Most likely would be sufficient to have /etc/profile.d/nano.{sh,csh} to cover most or all the shells out there, IIUC. I'd have never looked for this in /usr/lib/environment.d -- in fact, today is the first time I'd heard of this directory!
V/r, James Cassell
On Thu, Jun 25, 2020 at 8:40 pm, Ian McInerney Ian.S.McInerney@ieee.org wrote:
Are you sure this will work? I just ran a test, and putting a new config file inside /usr/lib/environment.d only works for Gnome, and doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal in the respective session and examining the environment variables). From what I gather in [1], systemd is not a standard way of interacting with the user's environment variables, and only Gnome has decided to use it. So this method of implementing this change seems to be making the default editor for Gnome be nano and not changing the defaults for anyone else.
Erm... well, no. Plan foiled?
The goal of using /usr/lib/environment.d was to avoid setting more environment variables in random places in various shell scripts. But if that only works in GNOME, I guess it's not a great solution after all.
On Thursday, June 25, 2020 10:27:06 PM CEST Michael Catanzaro wrote:
On Thu, Jun 25, 2020 at 8:40 pm, Ian McInerney Ian.S.McInerney@ieee.org wrote:
Are you sure this will work? I just ran a test, and putting a new config file inside /usr/lib/environment.d only works for Gnome, and doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal in the respective session and examining the environment variables). From what I gather in [1], systemd is not a standard way of interacting with the user's environment variables, and only Gnome has decided to use it. So this method of implementing this change seems to be making the default editor for Gnome be nano and not changing the defaults for anyone else.
Erm... well, no. Plan foiled?
The goal of using /usr/lib/environment.d was to avoid setting more environment variables in random places in various shell scripts. But if that only works in GNOME, I guess it's not a great solution after all.
Gentoo Linux uses the /etc/env.d tree to globally set environment variables:
https://devmanual.gentoo.org/tasks-reference/environment/index.html
It worked there long time before systemd was invented. But clearing this up in Fedora would ask for a separate system-wide change I guess...
Kamil
On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka kdudka@redhat.com wrote:
...snip...
Gentoo Linux uses the /etc/env.d tree to globally set environment variables:
https://devmanual.gentoo.org/tasks-reference/environment/index.htmlIt worked there long time before systemd was invented. But clearing this up in Fedora would ask for a separate system-wide change I guess...
Kamil
Isn't /etc/profile.d more inline with the FHS though? The FHS calls out /etc/profile as being the "systemwide initialization file for sh shell logins," so the profile.d directory would be the natural extension to that. I don't see a mention of an env or evn.d in the FHS at all.
-Ian
On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote:
On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka kdudka@redhat.com wrote:
...snip...
Gentoo Linux uses the /etc/env.d tree to globally set environment
variables: https://devmanual.gentoo.org/tasks-reference/environment/index.html
It worked there long time before systemd was invented. But clearing this up in Fedora would ask for a separate system-wide change I guess...
Kamil
Isn't /etc/profile.d more inline with the FHS though?
Could you please provide any reference?
The FHS calls out /etc/profile as being the "systemwide initialization file for sh shell logins," so the profile.d directory would be the natural extension to that. I don't see a mention of an env or evn.d in the FHS at all.
I see no mention of profile.d in FHS 3.0 either.
Kamil
-Ian
On Fri, Jun 26, 2020 at 10:49 AM Kamil Dudka kdudka@redhat.com wrote:
On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote:
On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka kdudka@redhat.com wrote:
...snip...
Gentoo Linux uses the /etc/env.d tree to globally set environment
variables:
https://devmanual.gentoo.org/tasks-reference/environment/index.html
It worked there long time before systemd was invented. But clearing
this
up in Fedora would ask for a separate system-wide change I guess...
Kamil
Isn't /etc/profile.d more inline with the FHS though?
Could you please provide any reference?
As I mentioned, the FHS calls out the "profile" file in /etc as being the "Systemwide initialization file for sh shell logins" [1]. While not in the FHS, it is custom to append ".d" to directories containing multiple configuration files to parse (as you have even suggested with env.d). That is why I said it would be /more inline/ with the FHS (I never said it was in the FHS currently), since it would then gather the files used by the "profile" script into the directory "profile.d".
The FHS calls out
/etc/profile as being the "systemwide initialization file for sh shell logins," so the profile.d directory would be the natural extension to
that.
I don't see a mention of an env or evn.d in the FHS at all.
I see no mention of profile.d in FHS 3.0 either.
But there is no mention of an "env" file that is a systemwide environment file either. So where does the initial "env" name fit into the FHS better than the "profile" name?
-Ian
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcHostspecificSys...
On Friday, June 26, 2020 12:07:46 PM CEST Ian McInerney wrote:
On Fri, Jun 26, 2020 at 10:49 AM Kamil Dudka kdudka@redhat.com wrote:
On Thursday, June 25, 2020 11:44:06 PM CEST Ian McInerney wrote:
On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka kdudka@redhat.com wrote:
...snip...
Gentoo Linux uses the /etc/env.d tree to globally set environment
variables:
https://devmanual.gentoo.org/tasks-reference/environment/index.html
It worked there long time before systemd was invented. But clearing
this
up in Fedora would ask for a separate system-wide change I guess...
Kamil
Isn't /etc/profile.d more inline with the FHS though?
Could you please provide any reference?
As I mentioned, the FHS calls out the "profile" file in /etc as being the "Systemwide initialization file for sh shell logins" [1].
/etc/profile may in general contain arbitrary shell code that conditionally sources other configuration files etc. whereas /etc/env.d on Gentoo is used solely to initialize environment variables.
While not in the FHS, it is custom to append ".d" to directories containing multiple configuration files to parse (as you have even suggested with env.d).
I did not suggest it for Fedora really. I just mentioned that the problem that _this_ change proposal is facing was already solved in another distro 10+ years ago.
That is why I said it would be /more inline/ with the FHS (I never said it was in the FHS currently), since it would then gather the files used by the "profile" script into the directory "profile.d".
That is what you say. But the specification itself does not say it at all.
Kamil
The FHS calls out
/etc/profile as being the "systemwide initialization file for sh shell logins," so the profile.d directory would be the natural extension to
that.
I don't see a mention of an env or evn.d in the FHS at all.
I see no mention of profile.d in FHS 3.0 either.
But there is no mention of an "env" file that is a systemwide environment file either. So where does the initial "env" name fit into the FHS better than the "profile" name?
-Ian
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcHostspecificSys temConfiguration
On Thursday, June 25, 2020 1:27:06 PM MST Michael Catanzaro wrote:
On Thu, Jun 25, 2020 at 8:40 pm, Ian McInerney Ian.S.McInerney@ieee.org wrote:
Are you sure this will work? I just ran a test, and putting a new config file inside /usr/lib/environment.d only works for Gnome, and doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal in the respective session and examining the environment variables). From what I gather in [1], systemd is not a standard way of interacting with the user's environment variables, and only Gnome has decided to use it. So this method of implementing this change seems to be making the default editor for Gnome be nano and not changing the defaults for anyone else.
Erm... well, no. Plan foiled?
The goal of using /usr/lib/environment.d was to avoid setting more environment variables in random places in various shell scripts. But if that only works in GNOME, I guess it's not a great solution after all.
Actually, that may be the perfect solution.. This way, it'd be a self contained change to the GNOME spin, and wouldn't affect the rest of Fedora. I'd be +1 on that.
On Thu, Jun 25, 2020 at 3:27 pm, Michael Catanzaro mcatanzaro@gnome.org wrote:
Erm... well, no. Plan foiled?
The goal of using /usr/lib/environment.d was to avoid setting more environment variables in random places in various shell scripts. But if that only works in GNOME, I guess it's not a great solution after all.
Since you noticed the original proposal doesn't actually work except in GNOME, the change proposal has been modified a bit. New proposal is:
nano-default-editor will include /etc/profile.d/nano.(sh|csh), which sets $EDITOR to nano
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user.
El jue., 25 jun. 2020 a las 21:45, Qiyu Yan (yanqiyu@fedoraproject.org) escribió:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Well, I strongy disagree whit this move. In fact on of the things that I hate of Debian/Ubuntu is the choice of nano and the poor version that they offer by default of vi. More friendly for end-users? Really? Please thinking so, the end-user use GUI's. Nano has no any significative advantage over vi and even lesser over vim. What's the wrong with vim? Really I don't understand. If one end-user wants to use a text editor, he will find kate, gedit and the like better options. If you don't like a modal editor, propose a better option not a mediocre one. For example, micro is a non-modal editor but more powerful that nano. If has no real benefit, please could you reconsider it and let the community give his voice? Thanks in advance. SB
On Thu, 2020-06-25 at 22:30 -0300, Sergio Belkin wrote:
Well, I strongy disagree whit this move. In fact on of the things that I hate of Debian/Ubuntu is the choice of nano and the poor version that they offer by default of vi. More friendly for end-users? Really? Please thinking so, the end-user use GUI's. Nano has no any significative advantage over vi and even lesser over vim. What's the wrong with vim? Really I don't understand. If one end-user wants to use a text editor, he will find kate, gedit and the like better options. If you don't like a modal editor, propose a better option not a mediocre one. For example, micro is a non-modal editor but more powerful that nano. If has no real benefit, please could you reconsider it and let the community give his voice? Thanks in advance. SB
This isn't about an editor someone *chooses* to use.
It's about that moment quite soon after you start using Linux, when you're puzzling your way through something at a console, and something you do triggers the default editor.
If you are unfortunate enough that the default editor is vi, what happens next is you spend half an hour trying to figure out what the *hell* is going on, followed by - depending how much you've learned about Linux so far, and whether you're at a VT or a desktop terminal - killing or closing the terminal from somewhere else, or just hard rebooting the system. (I had literally exactly this experience myself, back in the year 2000 or so.)
Nothing in vi's default view (if launched with a file, which is what happens in this case) tells you you need to press 'insert' in order to actually edit anything. Nothing in vi's default view tells you you have to type the entirely cryptic sequence ":wq" to save and exit (or gives you any clue how to exit at all). Nothing in vi's default view even *tells you that what you're looking at is a text editor called vi*. vi's intro page tells you a lot of this stuff, but in this scenario you don't *see* its intro page.
nano's default view:
1. tells you you are in an app called 'GNU nano' 2. actually intuitively works as a text editor - you can move around the file and use the backspace and delete keys and type stuff 3. provides a handy reference of key combos you can use to get help, save the file, and exit. Yes, you have to know that ^O means "ctrl+O", but figuring that out is a lot easier than working out how to drive vi from scratch.
On 6/25/20 6:48 PM, Adam Williamson wrote:
Nothing in vi's default view (if launched with a file, which is what happens in this case) tells you you need to press 'insert' in order to actually edit anything. Nothing in vi's default view tells you you have to type the entirely cryptic sequence ":wq" to save and exit (or gives you any clue how to exit at all). Nothing in vi's default view even *tells you that what you're looking at is a text editor called vi*. vi's intro page tells you a lot of this stuff, but in this scenario you don't *see* its intro page.
As much as I personally love using vim, I dread having someone accidentally end up in it. And if I'm trying to help someone remotely, there's no way I want that to happen. I always tell them to use nano because they can figure out how to do simple editing in it. If someone wants to do more advanced editing, then I will introduce them to vim. At work we have these big vim keyboard charts on our walls.
On Fri, 26 Jun 2020 03:48:56 +0200, Adam Williamson wrote:
- provides a handy reference of key combos you can use to get help,
save the file, and exit. Yes, you have to know that ^O means "ctrl+O", but figuring that out is a lot easier than working out how to drive vi from scratch.
After starting 'vi' there is: ~ type :help<Enter> or <F1> for on-line help
And after :help<Enter> there is: Close this window: Use ":q<Enter>". Get out of Vim: Use ":qa!<Enter>" (careful, all changes are lost!). WHAT PREPEND EXAMPLE Normal mode command :help x Visual mode command v_ :help v_u Insert mode command i_ :help i_<Esc>
Isn't that even more helpful than the '^' means 'ctrl' magic?
Jan
On 6/26/20 12:20 AM, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 03:48:56 +0200, Adam Williamson wrote:
- provides a handy reference of key combos you can use to get help,
save the file, and exit. Yes, you have to know that ^O means "ctrl+O", but figuring that out is a lot easier than working out how to drive vi from scratch.
After starting 'vi' there is: ~ type :help<Enter> or <F1> for on-line help
That's only if you start vi without a file. Otherwise, you just get the text of the file on the screen and the bottom line with the filename and cursor position. No info at all about what just happened.
On Fri, 26 Jun 2020 09:40:32 +0200, Samuel Sieb wrote:
That's only if you start vi without a file. Otherwise, you just get the text of the file on the screen and the bottom line with the filename and cursor position. No info at all about what just happened.
OK, I agree. So what about instead of nano to do:
cat >>~/.vimrc <<EOH set laststatus=2 set statusline=Press\ 'i'\ to\ start\ typing,\ '<escape>:x'\ to\ save\ file,\ '<escape>:q!'\ to\ quit. EOH
It is the most user friendly solution (plus the system still remains to be a UNIX!).
Jan
On 6/26/20 1:13 AM, Jan Kratochvil wrote:
On Fri, 26 Jun 2020 09:40:32 +0200, Samuel Sieb wrote:
That's only if you start vi without a file. Otherwise, you just get the text of the file on the screen and the bottom line with the filename and cursor position. No info at all about what just happened.
OK, I agree. So what about instead of nano to do:
cat >>~/.vimrc <<EOH set laststatus=2 set statusline=Press\ 'i'\ to\ start\ typing,\ '<escape>:x'\ to\ save\ file,\ '<escape>:q!'\ to\ quit. EOH
It is the most user friendly solution (plus the system still remains to be a UNIX!).
If you're going to say that you have to use vim for it to be unix, you're going to start another war with the emacs users. :-)
The most user friendly solution is to have nano by default with a very easy way to revert to vim for anyone that knows what they are doing.
On Fri, Jun 26, 2020 at 01:15:58AM -0700, Samuel Sieb wrote:
The most user friendly solution is to have nano by default with a very easy way to revert to vim for anyone that knows what they are doing.
No, it is not. It is user friendly to the users only using the command line a few times or the users who prefer nano.
For users having to edit files on a lot of different systems this is actually harmful and leads to bad behavior.
On a lot of systems I manage new users don't get a default shell - which is reasonable for service users - which led to the behavior that I only edit files as root - I think the reason is that switching to a service user ends up in /bin/sh and tab completion often does not work anymore.
Maybe it is an option to limit this change to Fedora Workstation and non-root accounts only? Or even better to put it as default only for users created via GUI? This could be achieved by appending 'alias EDITOR="nano"' to the .bashrc from /etc/skel.
I'm fine with configuring it on my machine, but as I administer a lot of machines (both Workstation and Server) I think the default for admins should stay vi.
So it is a -1 from me for the current variant of the proposal.
All the best, David
Is this a vote? If so -1.
Don't pave the jungle, put on some boots!
On Fri, 26 Jun 2020 at 12:33, David Kaufmann astra@ionic.at wrote:
On Fri, Jun 26, 2020 at 01:15:58AM -0700, Samuel Sieb wrote:
The most user friendly solution is to have nano by default with a very
easy
way to revert to vim for anyone that knows what they are doing.
No, it is not. It is user friendly to the users only using the command line a few times or the users who prefer nano.
For users having to edit files on a lot of different systems this is actually harmful and leads to bad behavior.
On a lot of systems I manage new users don't get a default shell - which is reasonable for service users - which led to the behavior that I only edit files as root - I think the reason is that switching to a service user ends up in /bin/sh and tab completion often does not work anymore.
Maybe it is an option to limit this change to Fedora Workstation and non-root accounts only? Or even better to put it as default only for users created via GUI? This could be achieved by appending 'alias EDITOR="nano"' to the .bashrc from /etc/skel.
I'm fine with configuring it on my machine, but as I administer a lot of machines (both Workstation and Server) I think the default for admins should stay vi.
So it is a -1 from me for the current variant of the proposal.
All the best, David _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 26/06/20 13:32 +0200, David Kaufmann wrote:
On Fri, Jun 26, 2020 at 01:15:58AM -0700, Samuel Sieb wrote:
The most user friendly solution is to have nano by default with a very easy way to revert to vim for anyone that knows what they are doing.
No, it is not. It is user friendly to the users only using the command line a few times or the users who prefer nano.
For users having to edit files on a lot of different systems this is actually harmful and leads to bad behavior.
On a lot of systems I manage new users don't get a default shell - which is reasonable for service users - which led to the behavior that I only edit files as root - I think the reason is that switching to a service user ends up in /bin/sh and tab completion often does not work anymore.
Maybe it is an option to limit this change to Fedora Workstation and non-root accounts only? Or even better to put it as default only for users created via GUI? This could be achieved by appending 'alias EDITOR="nano"' to the .bashrc from /etc/skel.
I'm fine with configuring it on my machine, but as I administer a lot of machines (both Workstation and Server) I think the default for admins should stay vi.
Only doing it for non-root users seems OK to me. Alternatively, just add EDITOR=vi to root's profile.
On Fri, 26 Jun 2020 at 04:16, Samuel Sieb wrote:
If you're going to say that you have to use vim for it to be unix, you're going to start another war with the emacs users. :-)
I came here with peace. Let's face it. It's always between the two. I respect vim and I learned quite some things in vim. But I'm an emacs user and I find the original decision between vim and emacs for 'git commit' unfair. The decision made the experience inconsistent with bash, to begin with (e.g. default bash shortcuts are pretty much default emacs shortcuts)...
This proposal changes the default to a neutral light-weight editor. Although the proposal doesn't fix the inconsistency, it's fair for both sides. +1
I came here with peace. Let's face it. It's always between the two. I respect vim and I learned quite some things in vim. But I'm an emacs user and I find the original decision between vim and emacs for 'git commit' unfair.
Git doesn't use vim by default, it uses vi, and it's got nothing to do with fairness. vi is specified by the POSIX standard, emacs is not. Using vi as the default when EDITOR is not set is consistent with POSIX utilities like crontab, using emacs is not.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
But this isn't about your preference (emacs) or my preference (vim), or what POSIX can portably assume is present. Fedora can assume nano is present, because Fedora controls that and already makes it present.
On Fri, 26 Jun 2020 at 10:55, Jonathan Wakely wrote:
I came here with peace. Let's face it. It's always between the two. I respect vim and I learned quite some things in vim. But I'm an emacs user and I find the original decision between vim and emacs for 'git commit' unfair.
Git doesn't use vim by default, it uses vi, and it's got nothing to do with fairness. vi is specified by the POSIX standard, emacs is not. Using vi as the default when EDITOR is not set is consistent with POSIX utilities like crontab, using emacs is not.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
But this isn't about your preference (emacs) or my preference (vim), or what POSIX can portably assume is present. Fedora can assume nano is present, because Fedora controls that and already makes it present.
Thank you again for the reference. vi and vim are the same thing for most people.
I think it's best if POSIX stays away from taking sides on a deep religious dilemma.
Make it neutral (e.g. nano). Both sides get hurt the same amount.
Best, Orcan
The ship on POSIX mandating vi (and defining it's behavior) sailed years ago.
On Fri, Jun 26, 2020, 4:11 PM Orcan Ogetbil oget.fedora@gmail.com wrote:
On Fri, 26 Jun 2020 at 10:55, Jonathan Wakely wrote:
I came here with peace. Let's face it. It's always between the two. I respect vim and I learned quite some things in vim. But I'm an emacs user and I find the original decision between vim and emacs for 'git commit' unfair.
Git doesn't use vim by default, it uses vi, and it's got nothing to do
with fairness. vi is specified by the POSIX standard, emacs is not. Using vi as the default when EDITOR is not set is consistent with POSIX utilities like crontab, using emacs is not.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
But this isn't about your preference (emacs) or my preference (vim), or
what POSIX can portably assume is present. Fedora can assume nano is present, because Fedora controls that and already makes it present.
Thank you again for the reference. vi and vim are the same thing for most people.
I think it's best if POSIX stays away from taking sides on a deep religious dilemma.
Make it neutral (e.g. nano). Both sides get hurt the same amount.
Best, Orcan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 25/06/20 18:48 -0700, Adam Williamson wrote:
On Thu, 2020-06-25 at 22:30 -0300, Sergio Belkin wrote:
Well, I strongy disagree whit this move. In fact on of the things that I hate of Debian/Ubuntu is the choice of nano and the poor version that they offer by default of vi. More friendly for end-users? Really? Please thinking so, the end-user use GUI's. Nano has no any significative advantage over vi and even lesser over vim. What's the wrong with vim? Really I don't understand. If one end-user wants to use a text editor, he will find kate, gedit and the like better options. If you don't like a modal editor, propose a better option not a mediocre one. For example, micro is a non-modal editor but more powerful that nano. If has no real benefit, please could you reconsider it and let the community give his voice? Thanks in advance. SB
This isn't about an editor someone *chooses* to use.
It's about that moment quite soon after you start using Linux, when you're puzzling your way through something at a console, and something you do triggers the default editor.
If you are unfortunate enough that the default editor is vi, what happens next is you spend half an hour trying to figure out what the *hell* is going on, followed by - depending how much you've learned about Linux so far, and whether you're at a VT or a desktop terminal - killing or closing the terminal from somewhere else, or just hard rebooting the system. (I had literally exactly this experience myself, back in the year 2000 or so.)
Back in 2000 maybe, but these days I'm surprised it can take half an hour for somebody with **any** unix/linux experience to try Ctrl-C, and in normal mode that makes vim say:
Type :qa and press <Enter> to exit Vim 0,0-1 All
And if you've somehow got into insert mode and type Ctrl-C Ctrl-C it says:
Type :qa! and press <Enter> to abandon all changes and exit Vim 1,0-1 All
That's been there for years, so I think the "stuck in vim" meme is outdated.
Nothing in vi's default view (if launched with a file, which is what happens in this case) tells you you need to press 'insert' in order to actually edit anything. Nothing in vi's default view tells you you have to type the entirely cryptic sequence ":wq" to save and exit (or gives you any clue how to exit at all).
Nothing says that if you just sit there staring at it for half an hour, but Ctrl-C does tell you what to do.
Nothing in vi's default view even *tells you that what you're looking at is a text editor called vi*.
Yes, the fact you don't even know which editor you're in, so don't know how to search the web for clues, is the main reason I'm in favour of the change.
Some actual numbers (from 2017), which are missing from this thread: https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-dev...
"In the last year, How to exit the Vim editor has made up about .005% of question traffic: that is, one out of every 20,000 visits to Stack Overflow questions. That means during peak traffic hours on weekdays, there are about 80 people per hour that need help getting out of Vim."
And that's Stack Overflow, a website **for developers**, and those numbers are for people who actually know they're in Vim and know what to search for!
That's been there for years, so I think the "stuck in vim" meme is outdated.
I agree is a funny meme, but even unreal. Sift+zz is not hard that Ctrl-o. Perhaps vim needs a footer such as nano :)
Once upon a time, Sergio Belkin sebelk@gmail.com said:
I agree is a funny meme, but even unreal. Sift+zz is not hard that Ctrl-o. Perhaps vim needs a footer such as nano :)
vim does respond to the common ^C invocation with:
Type :quit<Enter> to exit Vim
On Fri, 2020-06-26 at 13:03 +0100, Jonathan Wakely wrote:
On 25/06/20 18:48 -0700, Adam Williamson wrote:
If you are unfortunate enough that the default editor is vi, what happens next is you spend half an hour trying to figure out what the *hell* is going on, followed by - depending how much you've learned about Linux so far, and whether you're at a VT or a desktop terminal - killing or closing the terminal from somewhere else, or just hard rebooting the system. (I had literally exactly this experience myself, back in the year 2000 or so.)
Back in 2000 maybe, but these days I'm surprised it can take half an hour for somebody with **any** unix/linux experience to try Ctrl-C, and in normal mode that makes vim say:
Type :qa and press <Enter> to exit Vim 0,0-1 All
And if you've somehow got into insert mode and type Ctrl-C Ctrl-C it says:
Type :qa! and press <Enter> to abandon all changes and exit Vim 1,0-1 All
That's been there for years, so I think the "stuck in vim" meme is outdated.
That does sound like a slight improvement, but someone earlier in the thread still said they have heard this 'meme' from multiple people.
Also, that teaches you how to quit, but it still doesn't teach you how to actually do any editing or save the file...
Nothing in vi's default view even *tells you that what you're looking at is a text editor called vi*.
Yes, the fact you don't even know which editor you're in, so don't know how to search the web for clues, is the main reason I'm in favour of the change.
Some actual numbers (from 2017), which are missing from this thread: https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-dev...
"In the last year, How to exit the Vim editor has made up about .005% of question traffic: that is, one out of every 20,000 visits to Stack Overflow questions. That means during peak traffic hours on weekdays, there are about 80 people per hour that need help getting out of Vim."
And that's Stack Overflow, a website **for developers**, and those numbers are for people who actually know they're in Vim and know what to search for!
Right, so, maybe still not just a meme? :) Thanks for finding that, though, it's great info.
Hi,
On Thu, Jun 25, 2020 at 06:48:56PM -0700, Adam Williamson wrote:
Nothing in vi's default view (if launched with a file, which is what happens in this case) tells you you need to press 'insert' in order to actually edit anything. Nothing in vi's default view tells you you have to type the entirely cryptic sequence ":wq" to save and exit (or gives
since vim addresses this when opened without a file and it is open source, it seems to me to be a good idea to propose to adjust vim behaviour to show the help overview when opening a file as well. For example if there is no ~/.vimrc or some other indicator that shows the user does not know vim, yet.
Did someone discuss improving the novice user experience with the vim developers, yet? What was the outcome?
Thanks Till
Hi Till,
I sent a question to Vim mailing list:
https://groups.google.com/g/vim_dev/c/931nvz1TKyg
On 6/29/20 10:47 AM, Till Maas wrote:
Hi,
On Thu, Jun 25, 2020 at 06:48:56PM -0700, Adam Williamson wrote:
Nothing in vi's default view (if launched with a file, which is what happens in this case) tells you you need to press 'insert' in order to actually edit anything. Nothing in vi's default view tells you you have to type the entirely cryptic sequence ":wq" to save and exit (or gives
since vim addresses this when opened without a file and it is open source, it seems to me to be a good idea to propose to adjust vim behaviour to show the help overview when opening a file as well. For example if there is no ~/.vimrc or some other indicator that shows the user does not know vim, yet.
Did someone discuss improving the novice user experience with the vim developers, yet? What was the outcome?
Thanks Till _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
----- Original Message -----
From: "Till Maas" opensource@till.name To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Monday, June 29, 2020 10:47:58 AM Subject: Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Hi,
On Thu, Jun 25, 2020 at 06:48:56PM -0700, Adam Williamson wrote:
Nothing in vi's default view (if launched with a file, which is what happens in this case) tells you you need to press 'insert' in order to actually edit anything. Nothing in vi's default view tells you you have to type the entirely cryptic sequence ":wq" to save and exit (or gives
since vim addresses this when opened without a file and it is open source, it seems to me to be a good idea to propose to adjust vim behaviour to show the help overview when opening a file as well. For example if there is no ~/.vimrc or some other indicator that shows the user does not know vim, yet.
Did someone discuss improving the novice user experience with the vim developers, yet? What was the outcome?
Hello,
TL;DR please, +1 for nano, as "trial by fire" is not a good first experience for someone who just wants to get something done.
I don't think this should be matter of preference of current Fedora users or developers. Instead it's all about first impressions with a Linux distro (or second..) for fresh users. If it's hard "on first look", some people will consider it too hard to use generally, and will rather not use it at all. Having the same default as Debian/Ubuntu would certainly help, as well as the simplicity of nano, for someone who sees commandline editor for the first time. Running a "vim guided tour", or showing some hints, wouldn't compare in this case.
A developer/poweruser can later change EDITOR to something their familiar with, on purpose. 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.
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 now...
Regards, Pavel
Thanks Till
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 first 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 Fedora 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 them. 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 now...
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, David
On 6/29/20 7:59 AM, David Kaufmann wrote:
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".
I would like to respectfully disagree---my recollection is that when there was a vigorous opposition, the proposals were changed/retracted. In this particular case, it feels to me that the responses are mostly in favor, so it may be that this proposal is going against your preference, but this is good--it's how the system is supposed to work.
I am always always impressed by the discussion's high caliber and information content--I tend to learn a lot. My recollection is that proposals are being changed as a result.
I hope you can see it in a different light--as an opportunity to improve, not as an imposition. I am certainly glad that those proposals are in our workflow---thanks Ben, and the proposal authors!
Very Respectfully
p.
On Mon, Jun 29, 2020 at 1:48 pm, Przemek Klosowski via devel devel@lists.fedoraproject.org wrote:
I would like to respectfully disagree---my recollection is that when there was a vigorous opposition, the proposals were changed/retracted. In this particular case, it feels to me that the responses are mostly in favor, so it may be that this proposal is going against your preference, but this is good--it's how the system is supposed to work.
I am always always impressed by the discussion's high caliber and information content--I tend to learn a lot. My recollection is that proposals are being changed as a result.
In this case, the implementation proposal using /usr/lib/environment.d has been pretty thoroughly rejected, so this proposal is really going to have to be modified.
On Mon, Jun 29, 2020 at 8:01 AM David Kaufmann astra@ionic.at wrote:
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.
It is incorrect to assume this change is a done deal. Community feedback is critical to the Changes process (and is one of the key factors behind why we replaced the Features process).
To wit, five change proposals were rejected by FESCo for Fedora 32 alone:
1. https://pagure.io/fesco/issue/2323#comment-624955 2. https://pagure.io/fesco/issue/2291#comment-615815 3. https://pagure.io/fesco/issue/2268#comment-611948 4. https://pagure.io/fesco/issue/2241#comment-609153 5. https://pagure.io/fesco/issue/2198#comment-587826
In addition, change proposals can be withdrawn by the owner before being submitted to FESCo, as happened last week: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Changes are often updated based on community feedback (which is why we recently added a section to the proposal explicitly to record some of that feedback). One example is the proposal to improve the counting in DNF. The original[1] received a lot of feedback about the privacy implications, so it was withdrawn and reworked to take that feedback into account[2].
[1] https://fedoraproject.org/w/index.php?title=Changes/DNF_UUID&oldid=53144... [2] https://fedoraproject.org/wiki/Changes/DNF_Better_Counting
On Mon, 29 Jun 2020 10:47:58 +0200, you wrote:
since vim addresses this when opened without a file and it is open source, it seems to me to be a good idea to propose to adjust vim behaviour to show the help overview when opening a file as well. For example if there is no ~/.vimrc or some other indicator that shows the user does not know vim, yet.
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.
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". If they already use a console editor, would it be typical that they do not set the EDITOR variable? And if they are using a graphical Editor, shouldn't maybe that one be defaulted to in graphical environments?
Thanks Till
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.
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.
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.
Zbyszek
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.
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.
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.
Thanks Till
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
On Fri, Jul 3, 2020 at 1:18 PM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
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.
Or they just try Fedora and immediately mark it as a distro not for them. Because when they do "git commit" in Ubuntu, it opens up a reasonably user friendly editor (nano). When they do it in Fedora, it opens up a screen they don't even know how to exit (vi). If I were a new user to Linux, it would be clear to me which distribution is for me and which one is definitely not.
On Fri, 26 Jun 2020 at 03:40, Sergio Belkin sebelk@gmail.com wrote:
Well, I strongy disagree whit this move. In fact on of the things that I hate of Debian/Ubuntu is the choice of nano and the poor version that they offer by default of vi. More friendly for end-users? Really? Please thinking so, the end-user use GUI's. Nano has no any significative advantage over vi and even lesser over vim. What's the wrong with vim? Really I don't understand. If one end-user wants to use a text editor, he will find kate, gedit and the like better options.
Your argument works best the other way around: if a developer wants to use another text editor, they'll know the options, they'll know how to change it much better than an end-user.
As a vim user for many years, my +1000 to this change proposal.
On 6/26/20 4:30 AM, Sergio Belkin wrote:
Well, I strongy disagree whit this move. In fact on of the things that I hate of Debian/Ubuntu is the choice of nano and the poor version that they offer by default of vi. More friendly for end-users? Really? Please thinking so, the end-user use GUI's. Nano has no any significative advantage over vi and even lesser over vim. What's the wrong with vim? Really I don't understand.
For the uninitiated, nano has the very distinctive benefit over vi(m) that you have prayer of a chance of successfully making changes and exiting the thing gracefully ;)
- Panu -
----- Original Message -----
El jue., 25 jun. 2020 a las 21:45, Qiyu Yan (< yanqiyu@fedoraproject.org >) escribió:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Well, I strongy disagree whit this move. In fact on of the things that I hate of Debian/Ubuntu is the choice of nano and the poor version that they offer by default of vi. More friendly for end-users? Really? Please thinking so, the end-user use GUI's. Nano has no any significative advantage over vi and even lesser over vim. What's the wrong with vim? Really I don't understand. If one end-user wants to use a text editor, he will find kate, gedit and the like better options. If you don't like a modal editor, propose a better option not a mediocre one. For example, micro is a non-modal editor but more powerful that nano. If has no real benefit, please could you reconsider it and let the community give his voice? Thanks in advance. SB
--
Sergio Belkin LPIC-2 Certified - http://www.lpi.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
-1 for the change. If the so called 'end-user' (whatever does it mean) can learn git, she or he can also learn 'vi' or at least how to enable the preferred editor. Personally, I can see nothing special on the nano, for me it qualifies as very poor editor
thanks & regards
Jaroslav
-1 for the change. If the so called 'end-user' (whatever does it mean) can learn git, she or he can also learn 'vi' or at least how to enable the preferred editor. Personally, I can see nothing special on the nano, for me it qualifies as very poor editor
I feel you're completely missing the point, it's about a straight foward to understand editor by default so they aren't scared away before they even learn what an environment variable is, it's not about being the best most special editor. They may well have learned how to use git on windows or Mac before moving to Linux. I would flip this around and say anyone who knows vim enough should know how to change their default editor.
Peter
----- Original Message -----
-1 for the change. If the so called 'end-user' (whatever does it mean) can learn git, she or he can also learn 'vi' or at least how to enable the preferred editor. Personally, I can see nothing special on the nano, for me it qualifies as very poor editor
I feel you're completely missing the point, it's about a straight foward to understand editor by default so they aren't scared away before they even learn what an environment variable is, it's not about being the best most special editor. They may well have learned how to use git on windows or Mac before moving to Linux. I would flip this around and say anyone who knows vim enough should know how to change their default editor.
Yes, of course, but it will cost me time to find out where to revert the change (the right way).
I just wanted to point out how absurd the arguments in the proposal are. Somebody using the complex git CLI (which was never meant to be to highlevel CLI) is usually skilled enough not to be stopped by the different default editor (especially if the editor gives hints on wrong usage). Unskilled people will usually use GUI so they do not care
Jaroslav
Peter _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, Jun 26, 2020 at 02:55:01PM +0100, Peter Robinson wrote:
I feel you're completely missing the point, it's about a straight foward to understand editor by default so they aren't scared away before they even learn what an environment variable is, it's not about being the best most special editor. They may well have learned how to use git on windows or Mac before moving to Linux. I would flip this around and say anyone who knows vim enough should know how to change their default editor.
And it really isn't just git, although that may the most common tool people run into it with. "crontab -e" is another example off the top of my head.
Once upon a time, Matthew Miller mattdm@fedoraproject.org said:
And it really isn't just git, although that may the most common tool people run into it with. "crontab -e" is another example off the top of my head.
And visudo/sudoedit, systemctl edit, bash ^X^E, mysql \e, virsh edit, less v, mutt, edquota, and a number of bug-report type things like perlbug.
That's just things off the top of my head, I'm sure there's more.
On 26/06/20 09:24 -0500, Chris Adams wrote:
Once upon a time, Matthew Miller mattdm@fedoraproject.org said:
And it really isn't just git, although that may the most common tool people run into it with. "crontab -e" is another example off the top of my head.
And visudo/sudoedit, systemctl edit, bash ^X^E, mysql \e, virsh edit, less v, mutt, edquota, and a number of bug-report type things like perlbug.
That's just things off the top of my head, I'm sure there's more.
POSIX specifies the EDITOR env var and requires 'crontab', 'mailx', and 'more' to use it. The decision for other non-POSIX utilities like git to use it is an obvious choice, for consistency with standard utilities.
Amusingly, the fc utility requires "If FCEDIT is null or unset, ed shall be used as the editor." Yikes ;-)
On Fri, Jun 26, 2020 at 09:24:44AM -0500, Chris Adams wrote:
And visudo/sudoedit, systemctl edit, bash ^X^E, mysql \e, virsh edit, less v, mutt, edquota, and a number of bug-report type things like perlbug.
Less already has obscure vi-like keybindings, so that may not be the best example.
Hmmm. Time to switch $PAGER to `most`? :)
On Fri, 2020-06-26 at 11:58 -0400, Matthew Miller wrote:
On Fri, Jun 26, 2020 at 09:24:44AM -0500, Chris Adams wrote:
And visudo/sudoedit, systemctl edit, bash ^X^E, mysql \e, virsh edit, less v, mutt, edquota, and a number of bug-report type things like perlbug.
Less already has obscure vi-like keybindings, so that may not be the best example.
quit from less is at least is a single key, which gives you a fighting chance. I think it only took me about five minutes to figure out how to quit less, the first time. :P
I actually hadn't tried most before so I just did - the 'help' bar is a definitely improvement, but its search behaviour seems awful.
clearly we need to patch a help bar into less =)
On 26 June 2020 18:11:09 CEST, Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2020-06-26 at 11:58 -0400, Matthew Miller wrote:
On Fri, Jun 26, 2020 at 09:24:44AM -0500, Chris Adams wrote:
And visudo/sudoedit, systemctl edit, bash ^X^E, mysql \e, virsh edit, less v, mutt, edquota, and a number of bug-report type things like perlbug.
Less already has obscure vi-like keybindings, so that may not be the best example.
quit from less is at least is a single key, which gives you a fighting chance. I think it only took me about five minutes to figure out how to quit less, the first time. :P
I actually hadn't tried most before so I just did - the 'help' bar is a definitely improvement, but its search behaviour seems awful.
clearly we need to patch a help bar into less =)
Please stop. I know you are joking but people will take you seriously. Fast forward 2 years and there will be a whole little novel taking up screen space when using less. This never fails to happen.
On Fri, Jun 26, 2020 at 09:11:09AM -0700, Adam Williamson wrote:
clearly we need to patch a help bar into less =)
... that would actually be really easy to do, since a patch isn't necessary.
export LESS='-MPM?f%f .?n?m(%T %i of %m) ..?ltlines %lt-%lb?L/%L. :byte %bB?s/%s. .?e(END) ?x- Next: %x.:?pB%pB%..%t (h for help or q to quit)'
But let's not get ahead of ourselves. :)
On Fri, Jun 26, 2020 at 1:00 pm, Matthew Miller mattdm@fedoraproject.org wrote:
... that would actually be really easy to do, since a patch isn't necessary.
export LESS='-MPM?f%f .?n?m(%T %i of %m) ..?ltlines %lt-%lb?L/%L. :byte %bB?s/%s. .?e(END) ?x- Next: %x.:?pB%pB%..%t (h for help or q to quit)'
But let's not get ahead of ourselves. :)
That actually works really well, and we should seriously consider doing it. Or at least suggesting it to upstream.
It doesn't even take extra space. Only uses the bottom row that would otherwise be empty.
On Fri, Jun 26, 2020 at 12:50:52PM -0500, Michael Catanzaro wrote:
That actually works really well, and we should seriously consider doing it. Or at least suggesting it to upstream.
It doesn't even take extra space. Only uses the bottom row that would otherwise be empty.
Fine :) https://github.com/gwsw/less/issues/72
On Friday, June 26, 2020 11:09:31 AM MST Matthew Miller wrote:
On Fri, Jun 26, 2020 at 12:50:52PM -0500, Michael Catanzaro wrote:
That actually works really well, and we should seriously consider doing it. Or at least suggesting it to upstream.
It doesn't even take extra space. Only uses the bottom row that would otherwise be empty.
See Markus Larsson's comment on this above...
On Sun, Jun 28, 2020 at 10:32:34AM -0700, John M. Harris Jr wrote:
See Markus Larsson's comment on this above...
Yeah, but as Michael points out, that doesn't really apply: it takes up literally zero additional screen space.
On Sunday, June 28, 2020 7:51:40 PM MST Matthew Miller wrote:
On Sun, Jun 28, 2020 at 10:32:34AM -0700, John M. Harris Jr wrote:
See Markus Larsson's comment on this above...
Yeah, but as Michael points out, that doesn't really apply: it takes up literally zero additional screen space.
The bottom row is normally just as large as the file name, or is even just blank, in the case of streams, and doesn't distract from the file/stream content. Adding that text is unnecessary clutter.
On 29 June 2020 04:51:40 CEST, Matthew Miller mattdm@fedoraproject.org wrote:
On Sun, Jun 28, 2020 at 10:32:34AM -0700, John M. Harris Jr wrote:
See Markus Larsson's comment on this above...
Yeah, but as Michael points out, that doesn't really apply: it takes up literally zero additional screen space.
Yeah, looks like a slippery slope to me. Yes I'm mostly joking but these things has a tendency to grow.
On Friday, June 26, 2020 3:55:01 PM CEST Peter Robinson wrote:
-1 for the change. If the so called 'end-user' (whatever does it mean) can learn git, she or he can also learn 'vi' or at least how to enable the preferred editor. Personally, I can see nothing special on the nano, for me it qualifies as very poor editor
I feel you're completely missing the point, it's about a straight foward to understand editor by default so they aren't scared away before they even learn what an environment variable is, it's not about being the best most special editor. They may well have learned how to use git on windows or Mac before moving to Linux.
The distribution of git I use on Windows defaults to vi, too.
Kamil
I would flip this around and say anyone who knows vim enough should know how to change their default editor.
Peter
On Fri, 2020-06-26 at 07:05 -0400, Jaroslav Skarvada wrote:
-1 for the change. If the so called 'end-user' (whatever does it mean) can learn git, she or he can also learn 'vi' or at least how to enable the preferred editor. Personally, I can see nothing special on the nano, for me it qualifies as very poor editor
git's an example. There are various other things that trigger the default $EDITOR.
As I said, this *literally happened to me*. I don't remember what it was I did that triggered $EDITOR, but as it was 19 years ago, it definitely wasn't git. =)
Yes, I was trying to learn and figure things out. But if you are trying to learn X, suddenly being forced to learn Y *unexpectedly* - you were not working on text editors today! - with no documentation and not even knowing what Y *is* exactly, is not a pleasant learning experience. It is a frustrating roadblock.
On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user.
It's a nice idea, but the problem with things like this is they *always* introduce bugs, and often wind up being unmaintained, because keeping them working is kind of a thankless task.
IMHO it's better to keep things simple and just pick a default. And the default should definitely be nano. :D
Adam Williamson adamwill@fedoraproject.org 于 2020年6月26日周五 上午9:32写道：
On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user.
It's a nice idea, but the problem with things like this is they *always* introduce bugs, and often wind up being unmaintained, because keeping them working is kind of a thankless task.
IMHO it's better to keep things simple and just pick a default. And the default should definitely be nano. :D
Then I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
I has been asked "how to exit this hell?" multiple times by my new-to-Linux friends, that time I would always suggest them to set nano as default. Vim is great though, it is not for beginners.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 6/26/20 1:30 PM, Qiyu Yan wrote:
Adam Williamson <adamwill@fedoraproject.org mailto:adamwill@fedoraproject.org> 于 2020年6月26日周五 上午9:32写道：
On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote: > What about to provide a prompt to the user telling them the difference > between editors? > For example, when a new user to fedora first invokes git commit > without $EDITOR set, a program named fedora-default-editor comes up > and asks: Which editor do you like? > User can do his or hers choice and the choice will be remembered by > setting $EDITOR in his or hers ~/.bashrc > > The fedora-default-editor can be a small script that shows user all > the difference and set $EDITOR for the user. It's a nice idea, but the problem with things like this is they *always* introduce bugs, and often wind up being unmaintained, because keeping them working is kind of a thankless task. IMHO it's better to keep things simple and just pick a default. And the default should definitely be nano. :DThen I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
This seems the best approach in my opinion. I totally agree that having something simple is important for new users. My only fear (and it applies to any default editor choice) is that the default will be changed only by a minority of new-users, or after many months.
Thus having an educational approach which tells the user how to configure his environment properly (and eventually doing it for him from a list of choices) seems the most friendly approach.
I must add that nano feels like an old VT100 editor. Not very appealing to new users (but indeed very clear on how to operate). My guess is that an average user will hope to see an editor application with icons and everything to popup (call it notepad and you will fill all his/her expectations ;-) )... Of course, this will not work in a linux terminal, but most new users don't even know the concept of a terminal...
On 26/06/20 14:03 +0200, Theodore Papadopoulo wrote:
On 6/26/20 1:30 PM, Qiyu Yan wrote:
Adam Williamson <adamwill@fedoraproject.org mailto:adamwill@fedoraproject.org> 于 2020年6月26日周五 上午9:32写道：
On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote: > What about to provide a prompt to the user telling them the difference > between editors? > For example, when a new user to fedora first invokes git commit > without $EDITOR set, a program named fedora-default-editor comes up > and asks: Which editor do you like? > User can do his or hers choice and the choice will be remembered by > setting $EDITOR in his or hers ~/.bashrc > > The fedora-default-editor can be a small script that shows user all > the difference and set $EDITOR for the user. It's a nice idea, but the problem with things like this is they *always* introduce bugs, and often wind up being unmaintained, because keeping them working is kind of a thankless task. IMHO it's better to keep things simple and just pick a default. And the default should definitely be nano. :DThen I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
This seems the best approach in my opinion. I totally agree that having something simple is important for new users. My only fear (and it applies to any default editor choice) is that the default will be changed only by a minority of new-users, or after many months.
Thus having an educational approach which tells the user how to configure his environment properly (and eventually doing it for him from a list of choices) seems the most friendly approach.
I must add that nano feels like an old VT100 editor. Not very appealing to new users (but indeed very clear on how to operate). My guess is that an average user will hope to see an editor application with icons and everything to popup (call it notepad and you will fill all his/her expectations ;-) )... Of course, this will not work in a linux terminal, but most new users don't even know the concept of a terminal...
Why would $EDITOR even matter if they're not using the terminal?
Why would $EDITOR even matter if they're not using the terminal? _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
I agree with you. And it's funny because people that support the use of nano over vi/vim say "don't talk about personal beliefs" and come to talk about meme's and how vim is hard to our grandmothers :)
Really do we believe that setting nano as a default editor will attract new users to Linux? How many end users in last years use Debian because of the default editor change? A newbie generally does know nothing about vi/vim, cron, git, etc...
On 26/06/20 09:22 -0300, Sergio Belkin wrote:
Really do we believe that setting nano as a default editor will attract new users to Linux? How many end users in last years use Debian because of the default editor change? A newbie generally does know nothing about vi/vim, cron, git, etc...
The proposal doesn't say it will *attract* new users. I think the point is to not frustrate users who have already decided to try Fedora.
On Fri, Jun 26, 2020 at 01:27:54PM +0100, Jonathan Wakely wrote:
On 26/06/20 09:22 -0300, Sergio Belkin wrote:
Really do we believe that setting nano as a default editor will attract new users to Linux? How many end users in last years use Debian because of the default editor change? A newbie generally does know nothing about vi/vim, cron, git, etc...
The proposal doesn't say it will *attract* new users. I think the point is to not frustrate users who have already decided to try Fedora.
Do we have real stasitics on this (somthing in the form of bz reports or comments on a list) indicating that users actually are frustrated with being confronted with vi unexpectedly? Given the initially presented use case (having git-commit or git-rebase pop up vi as the default editor), I'm struggling with the notion that an individual user is sufficiently skilled to use git on the command line, yet struggles to find information on the editor git uses by default. It seems somewhat inconsistent to me. Thats not to say its not a real problem, but it feels a bit like we're taking action on an issue that may not be a problem, at the expense of existing users that like the environment the way it is.
Neil (who, in full disclosure, likes vi as the default editor)
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
Do we have real stasitics on this (somthing in the form of bz reports or comments on a list) indicating that users actually are frustrated with being confronted with vi unexpectedly?
Why would one file a bugzilla ticket over this? vi, and the system default, is working as intended. "That's just the way Linux is," say the folks having to answer "how to quit vi" for the umpteenth time.
I'm struggling with the notion that an individual user is sufficiently skilled to use git on the command line,
They actually aren't skilled on the cmdline. At most they'll just cut-n-paste something they found on stack overflow. Instead, GUI git frontends are the norm, generally embedded within IDEs.
(FFS most of the folks I work with use the github web frontend to commit things. Because git is just short for github!)
- Solomon [who greatly prefers emacs]
On Fri, Jun 26, 2020 at 09:00:58AM -0400, Solomon Peachy wrote:
On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
Do we have real stasitics on this (somthing in the form of bz reports or comments on a list) indicating that users actually are frustrated with being confronted with vi unexpectedly?
Why would one file a bugzilla ticket over this? vi, and the system default, is working as intended. "That's just the way Linux is," say the folks having to answer "how to quit vi" for the umpteenth time.
Ok, perhaps bugzilla is the wrong venue, but the point stands. Are people actually asking how to quit vi (or some simmilar questions) somewhere? If I google how to quit vi, I see a full 10 pages of the answer to the question documented in detail (which suggests lots of people had the question at some point in time), but what I don't see are stackoverflow (or other message board posts) asking the question currently. Clearly there was a time when this was a problem (and access to all the online resources we have today wasn't available), but now? I'm just asking us not to make this decision by proxy. Are there users out there today that are complaining somewhere that vi is hard to use, and can't either figure it out, or figure out how to use a different editor
I'm struggling with the notion that an individual user is sufficiently skilled to use git on the command line,
They actually aren't skilled on the cmdline. At most they'll just cut-n-paste something they found on stack overflow. Instead, GUI git frontends are the norm, generally embedded within IDEs.
This just confuses me further. For integrated IDEs, the selection of a default editor for terminal usage is largely irrelevant, as the IDE typically provides an editor built in (basing this assertion on eclipse behvior, but I'd be suprised if an ide forks a terminal just to run the git default editor)
So the user you are describing
1) Isn't skilled in command line usage 2) Chose to use the command line anyway, despite having a littany of IDE's available 3) Was sufficiently well versed in development process to chose to use an SCM, and to search for commands to work with it (setting asside their lack of understanding of what they were doing) 4) But wasn't sufficiently well versed enough to go back and find out how to use the editor that their scm choice chose to default to
I just don't see that that person really exists.
Note I'm not saying we shouldn't make this change, I'm just saying that I don't like the idea of making it based on our assumption of what our end users are struggling with. If we have references to end users that legitimately have this problem, I'd love it to see them, and that would satisfy me.
Neil
(FFS most of the folks I work with use the github web frontend to commit things. Because git is just short for github!)
- Solomon [who greatly prefers emacs]
-- Solomon Peachy pizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode)
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 26/06/20 10:33 -0400, Neil Horman wrote:
On Fri, Jun 26, 2020 at 09:00:58AM -0400, Solomon Peachy wrote:
On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
Do we have real stasitics on this (somthing in the form of bz reports or comments on a list) indicating that users actually are frustrated with being confronted with vi unexpectedly?
Why would one file a bugzilla ticket over this? vi, and the system default, is working as intended. "That's just the way Linux is," say the folks having to answer "how to quit vi" for the umpteenth time.
Ok, perhaps bugzilla is the wrong venue, but the point stands. Are people actually asking how to quit vi (or some simmilar questions) somewhere? If I google how to quit vi, I see a full 10 pages of the answer to the question documented in detail (which suggests lots of people had the question at some point in time), but what I don't see are stackoverflow (or other message board posts) asking the question currently.
For the third time: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Three years ago they said:
"In the last year, How to exit the Vim editor has made up about .005% of question traffic: that is, one out of every 20,000 visits to Stack Overflow questions. That means during peak traffic hours on weekdays, there are about 80 people per hour that need help getting out of Vim."
Note I'm not saying we shouldn't make this change, I'm just saying that I don't like the idea of making it based on our assumption of what our end users are struggling with. If we have references to end users that legitimately have this problem, I'd love it to see them, and that would satisfy me.
See above. I find it surprising, but the numbers are there, and while I think things have changed a lot in 20 years, I don't think they've changed much since 2017.
On Fri, Jun 26, 2020 at 03:42:39PM +0100, Jonathan Wakely wrote:
On 26/06/20 10:33 -0400, Neil Horman wrote:
On Fri, Jun 26, 2020 at 09:00:58AM -0400, Solomon Peachy wrote:
On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
Do we have real stasitics on this (somthing in the form of bz reports or comments on a list) indicating that users actually are frustrated with being confronted with vi unexpectedly?
Why would one file a bugzilla ticket over this? vi, and the system default, is working as intended. "That's just the way Linux is," say the folks having to answer "how to quit vi" for the umpteenth time.
Ok, perhaps bugzilla is the wrong venue, but the point stands. Are people actually asking how to quit vi (or some simmilar questions) somewhere? If I google how to quit vi, I see a full 10 pages of the answer to the question documented in detail (which suggests lots of people had the question at some point in time), but what I don't see are stackoverflow (or other message board posts) asking the question currently.
For the third time: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Three years ago they said:
"In the last year, How to exit the Vim editor has made up about .005% of question traffic: that is, one out of every 20,000 visits to Stack Overflow questions. That means during peak traffic hours on weekdays, there are about 80 people per hour that need help getting out of Vim."
Yes, I read that, and I'd make two observations: 1) .005% is small. Searches tagged with git in stack overflow dwarf that number, but we're not looking at making the use of git more self discoverable (not that we shouldnt). But it seems the relative impact of this change is worth noting, both in terms of the benefit to those it would help, and to the frustration of those it might otherwise hinder.
2) Ostensibly, those people got the answer they were looking for. Just because people have a question, doesn't in my mind translate to something being "hard", it just means they had to go look something up. I do that all the time for things I'm just starting to work with, and it doesn't imply that I find that new thing hard, only that I have to learn a bit about it, and once I do, I'm good.
I think the question we should be asking isn't "Is vi hard to use?" but rather "Is our default editor something our users are having trouble learning about?"
put another way, According to stackoverflow, there are about 26,000 questions there tagged with vi/vim, 19,000 tagged with emacs, and only 222 questions tagged with nano. Nano may be more self-discoverable than vi, I'll gladly stipulate to that, but if a user does have a question, it seems they would be far less able to find the answer to their questions than if they were using a more popular editor. Not that that can't change (I would expect querys about nano to go up if we were to switch), but if the goal is good user experience, I would think theres an argument to be made for there being answers to common question being readily available.
Best Neil
Note I'm not saying we shouldn't make this change, I'm just saying that I don't like the idea of making it based on our assumption of what our end users are struggling with. If we have references to end users that legitimately have this problem, I'd love it to see them, and that would satisfy me.
See above. I find it surprising, but the numbers are there, and while I think things have changed a lot in 20 years, I don't think they've changed much since 2017. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, Jun 26, 2020 at 03:42:39PM +0100, Jonathan Wakely wrote:
"In the last year, How to exit the Vim editor has made up about .005% of question traffic: that is, one out of every 20,000 visits to Stack Overflow questions. That means during peak traffic hours on weekdays, there are about 80 people per hour that need help getting out of Vim."
Please don't just simply take that number as "number of people trying to exit vim" One of those threads on stackoverflow was a highly popular meme and was featured in quite many webpages. I myself probably visited that thread about 5 to 10 times despite being a vim user for about 10 years now, just because I was provided with the link to that specific thread or because I wanted to show someone that thread.
All the best, David
On 26/06/20 19:15 +0200, David Kaufmann wrote:
On Fri, Jun 26, 2020 at 03:42:39PM +0100, Jonathan Wakely wrote:
"In the last year, How to exit the Vim editor has made up about .005% of question traffic: that is, one out of every 20,000 visits to Stack Overflow questions. That means during peak traffic hours on weekdays, there are about 80 people per hour that need help getting out of Vim."
Please don't just simply take that number as "number of people trying to exit vim" One of those threads on stackoverflow was a highly popular meme and was featured in quite many webpages. I myself probably visited that thread about 5 to 10 times despite being a vim user for about 10 years now, just because I was provided with the link to that specific thread or because I wanted to show someone that thread.
Agreed. I've never tried to use regular expressions to parse XML* but I've visited https://stackoverflow.com/a/1732454/981959 dozens of times.
* ok, maybe once or twice.
On Fri, 2020-06-26 at 10:33 -0400, Neil Horman wrote:
On Fri, Jun 26, 2020 at 09:00:58AM -0400, Solomon Peachy wrote:
On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
Do we have real stasitics on this (somthing in the form of bz reports or comments on a list) indicating that users actually are frustrated with being confronted with vi unexpectedly?
Why would one file a bugzilla ticket over this? vi, and the system default, is working as intended. "That's just the way Linux is," say the folks having to answer "how to quit vi" for the umpteenth time.
Ok, perhaps bugzilla is the wrong venue, but the point stands. Are people actually asking how to quit vi (or some simmilar questions) somewhere? If I google how to quit vi, I see a full 10 pages of the answer to the question documented in detail (which suggests lots of people had the question at some point in time), but what I don't see are stackoverflow (or other message board posts) asking the question currently.
In order to ask "how do I quit vi?" you have to know you're in vi. Which you don't (again, from personal experience).
I believe the question I eventually asked on IRC (later, because this was still in the days when you didn't connect to the internet until it was after 6pm and the phone call was cheaper :>) was something like "I did X and this weird screen popped up where I could kinda type stuff but some keys didn't work and I think maybe it was for editing text but I couldn't figure out how to do it properly or save anything or quit, what the hell was that?" or something along those lines.
If you can figure out how to search the internet for questions like that...=)
But Jonathan did in fact post a link to a detailed Stack Overflow
Clearly there was a time when this was a problem (and access to all the online resources we have today wasn't available),
I'd agree it's likely to be less of a roadblock today as you're much more likely to be online 24/7 and have another device (phone!) you can ask the question from. But it's still an unnecessary pain point. (And *some* poor person on the internet has to explain this problem for the sixteen billionth collective time). Why not fix it?
but now? I'm just asking us not to make this decision by proxy. Are there users out there today that are complaining somewhere that vi is hard to use, and can't either figure it out, or figure out how to use a different editor
I'm struggling with the notion that an individual user is sufficiently skilled to use git on the command line,
They actually aren't skilled on the cmdline. At most they'll just cut-n-paste something they found on stack overflow. Instead, GUI git frontends are the norm, generally embedded within IDEs.
This just confuses me further. For integrated IDEs, the selection of a default editor for terminal usage is largely irrelevant, as the IDE typically provides an editor built in (basing this assertion on eclipse behvior, but I'd be suprised if an ide forks a terminal just to run the git default editor)
Don't focus on git. It's not just about git. git was just a convenient example of something that launches the default text editor.
So the user you are describing
- Isn't skilled in command line usage
- Chose to use the command line anyway, despite having a littany of IDE's
available 3) Was sufficiently well versed in development process to chose to use an SCM, and to search for commands to work with it (setting asside their lack of understanding of what they were doing) 4) But wasn't sufficiently well versed enough to go back and find out how to use the editor that their scm choice chose to default to
I just don't see that that person really exists.
There are literally multiple people in the thread telling you this literally happened to them or to people they know who asked them for help. I am one of them.
On Fri, Jun 26, 2020 at 08:50:09AM -0700, Adam Williamson wrote:
On Fri, 2020-06-26 at 10:33 -0400, Neil Horman wrote:
On Fri, Jun 26, 2020 at 09:00:58AM -0400, Solomon Peachy wrote:
On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
Do we have real stasitics on this (somthing in the form of bz reports or comments on a list) indicating that users actually are frustrated with being confronted with vi unexpectedly?
Why would one file a bugzilla ticket over this? vi, and the system default, is working as intended. "That's just the way Linux is," say the folks having to answer "how to quit vi" for the umpteenth time.
Ok, perhaps bugzilla is the wrong venue, but the point stands. Are people actually asking how to quit vi (or some simmilar questions) somewhere? If I google how to quit vi, I see a full 10 pages of the answer to the question documented in detail (which suggests lots of people had the question at some point in time), but what I don't see are stackoverflow (or other message board posts) asking the question currently.
In order to ask "how do I quit vi?" you have to know you're in vi. Which you don't (again, from personal experience).
I believe the question I eventually asked on IRC (later, because this was still in the days when you didn't connect to the internet until it was after 6pm and the phone call was cheaper :>) was something like "I did X and this weird screen popped up where I could kinda type stuff but some keys didn't work and I think maybe it was for editing text but I couldn't figure out how to do it properly or save anything or quit, what the hell was that?" or something along those lines.
If you can figure out how to search the internet for questions like that...=)
Thats a funny example :) https://www.google.com/search?q=I+did+git+commit+and+this+wierd+screen+poppe...
The first result that pops up is a stack overflow thread explaining that the wierd screen is vi, and how to work in it (as well as how to change it if you would rather use something else)
But Jonathan did in fact post a link to a detailed Stack Overflow
Yeah, he did, I commented on it somewhere else in this thread.
Clearly there was a time when this was a problem (and access to all the online resources we have today wasn't available),
I'd agree it's likely to be less of a roadblock today as you're much more likely to be online 24/7 and have another device (phone!) you can ask the question from. But it's still an unnecessary pain point. (And *some* poor person on the internet has to explain this problem for the sixteen billionth collective time). Why not fix it?
Oh, I completely agree with fixing it. Somewhere else in this thread you mentioned that the 10000000 searches for exiting vim meant 10^6 people had to needlessly search for the answer to that. Thats probably an indicator that vi could be improved to make it more discoverable (lots of opportunity there), but I don't think its cause to change the default editor, because those 10^6 people asked the question, and (I have to assume) kept using vi, so for whatever questions they're asking, they don't (seem) to be rising to the level of departing Fedora for another distro that offers something else as the default.
Also, have we asked the question, what default editor are other distros setting? I've honestly never looked.
but now? I'm just asking us not to make this decision by proxy. Are there users out there today that are complaining somewhere that vi is hard to use, and can't either figure it out, or figure out how to use a different editor
I'm struggling with the notion that an individual user is sufficiently skilled to use git on the command line,
They actually aren't skilled on the cmdline. At most they'll just cut-n-paste something they found on stack overflow. Instead, GUI git frontends are the norm, generally embedded within IDEs.
This just confuses me further. For integrated IDEs, the selection of a default editor for terminal usage is largely irrelevant, as the IDE typically provides an editor built in (basing this assertion on eclipse behvior, but I'd be suprised if an ide forks a terminal just to run the git default editor)
Don't focus on git. It's not just about git. git was just a convenient example of something that launches the default text editor.
Sure, we can substitue any other tool here that has to fork an editor from the command line, and some of those will be far more in line with what a novice non-developer might use. I just think for those users, nano likely isn't going to move the needle much, and I'm not sure how many of those users Fedora gets, or looses on this point. I know we can't really get that data, but it sure would be great to have.
So the user you are describing
- Isn't skilled in command line usage
- Chose to use the command line anyway, despite having a littany of IDE's
available 3) Was sufficiently well versed in development process to chose to use an SCM, and to search for commands to work with it (setting asside their lack of understanding of what they were doing) 4) But wasn't sufficiently well versed enough to go back and find out how to use the editor that their scm choice chose to default to
I just don't see that that person really exists.
There are literally multiple people in the thread telling you this literally happened to them or to people they know who asked them for help. I am one of them.
I think thats an overstatement. If it isnt, I apologize, but I really have a hard time believing that they comply with 1-3 (those are entirely believable), but then threw their hands up in the air when confronted with a window that they could sort of edit text in. As shown above, typing "I typed <x> in and this wierd screen poped up that I could kind of edit" into google answered that question in the top result.
I grant you that vi could be more discoverable, but even though vi presents you with an interface that can be hard to understand, finding the answers to how to use it isn't hard (even if you don't know its vi).
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, 2020-06-26 at 12:39 -0400, Neil Horman wrote:
Also, have we asked the question, what default editor are other distros setting? I've honestly never looked.
The Change page says "More in line with the default editor of other distributions." But it doesn't give more detail, so I did a bit of research!
Ubuntu's default is nano, per various search results.
openSUSE's (I tested the Leap 15.1 GNOME live image) is...mostly vi, though this is implemented some other way than $EDITOR, because `echo $EDITOR` shows nothing. `visudo` and `git commit` run vi, but `systemctl edit` runs nano. Not sure what's going on there.
At least as of 2015, Arch considered changing to nano but stuck with vi, though one of their key arguments at the time was "everyone else uses vi", and it seems the issue was slightly complicated by the question of what packages would or wouldn't be in their 'core': https://lists.archlinux.org/pipermail/arch-dev-public/2015-April/027133.html As of 2019 it still seems to be vi: https://bbs.archlinux.org/viewtopic.php?id=245675
Mint's default seems to be nano, though like openSUSE, it is doing this some way other than by setting $EDITOR.
So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using nano is pretty significant.
Don't focus on git. It's not just about git. git was just a convenient example of something that launches the default text editor.
Sure, we can substitue any other tool here that has to fork an editor from the command line, and some of those will be far more in line with what a novice non-developer might use. I just think for those users, nano likely isn't going to move the needle much, and I'm not sure how many of those users Fedora gets, or looses on this point. I know we can't really get that data, but it sure would be great to have.
So the user you are describing
- Isn't skilled in command line usage
- Chose to use the command line anyway, despite having a littany of IDE's
available 3) Was sufficiently well versed in development process to chose to use an SCM, and to search for commands to work with it (setting asside their lack of understanding of what they were doing) 4) But wasn't sufficiently well versed enough to go back and find out how to use the editor that their scm choice chose to default to
I just don't see that that person really exists.
There are literally multiple people in the thread telling you this literally happened to them or to people they know who asked them for help. I am one of them.
I think thats an overstatement. If it isnt, I apologize, but I really have a hard time believing that they comply with 1-3 (those are entirely believable), but then threw their hands up in the air when confronted with a window that they could sort of edit text in. As shown above, typing "I typed <x> in and this wierd screen poped up that I could kind of edit" into google answered that question in the top result.
Sure, like I wrote elsewhere in the thread, it's probably less of a complete roadblock than it used to be. But it's still an unnecessary pain point. Yes, people can probably get through it in fifteen minutes these days, but it's still unnecessarily annoying. Why cause them the trouble?
On Fri, Jun 26, 2020 at 1:16 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2020-06-26 at 12:39 -0400, Neil Horman wrote:
Also, have we asked the question, what default editor are other distros setting? I've honestly never looked.
The Change page says "More in line with the default editor of other distributions." But it doesn't give more detail, so I did a bit of research!
Ubuntu's default is nano, per various search results.
Debian's default is nano as well. Ubuntu inherits this setting from Debian.
On Fri, Jun 26, 2020 at 10:15:45AM -0700, Adam Williamson wrote:
On Fri, 2020-06-26 at 12:39 -0400, Neil Horman wrote:
Also, have we asked the question, what default editor are other distros setting? I've honestly never looked.
The Change page says "More in line with the default editor of other distributions." But it doesn't give more detail, so I did a bit of research!
Thanks!
Ubuntu's default is nano, per various search results.
openSUSE's (I tested the Leap 15.1 GNOME live image) is...mostly vi, though this is implemented some other way than $EDITOR, because `echo $EDITOR` shows nothing. `visudo` and `git commit` run vi, but `systemctl edit` runs nano. Not sure what's going on there.
I know git hard codes vi as the final default, so that tracks, I'm not sure how visudo and systemctl pick an editor. Etiher way, whatever we pick, we probably shouldn't implement it like this.
At least as of 2015, Arch considered changing to nano but stuck with vi, though one of their key arguments at the time was "everyone else uses vi", and it seems the issue was slightly complicated by the question of what packages would or wouldn't be in their 'core': https://lists.archlinux.org/pipermail/arch-dev-public/2015-April/027133.html As of 2019 it still seems to be vi: https://bbs.archlinux.org/viewtopic.php?id=245675
Mint's default seems to be nano, though like openSUSE, it is doing this some way other than by setting $EDITOR.
Mints just a derivative of openSuse, isn't it? It would make sense that this followed.
So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using nano is pretty significant.
Yeah, but significant in what way? We have two fairly popular distributions using nano, but over 1,000,000 people trying to figure out how to exit vi on stackexchange. Is the user base for other distros defaulting to vi just that much bigger?
Don't focus on git. It's not just about git. git was just a convenient example of something that launches the default text editor.
Sure, we can substitue any other tool here that has to fork an editor from the command line, and some of those will be far more in line with what a novice non-developer might use. I just think for those users, nano likely isn't going to move the needle much, and I'm not sure how many of those users Fedora gets, or looses on this point. I know we can't really get that data, but it sure would be great to have.
So the user you are describing
- Isn't skilled in command line usage
- Chose to use the command line anyway, despite having a littany of IDE's
available 3) Was sufficiently well versed in development process to chose to use an SCM, and to search for commands to work with it (setting asside their lack of understanding of what they were doing) 4) But wasn't sufficiently well versed enough to go back and find out how to use the editor that their scm choice chose to default to
I just don't see that that person really exists.
There are literally multiple people in the thread telling you this literally happened to them or to people they know who asked them for help. I am one of them.
I think thats an overstatement. If it isnt, I apologize, but I really have a hard time believing that they comply with 1-3 (those are entirely believable), but then threw their hands up in the air when confronted with a window that they could sort of edit text in. As shown above, typing "I typed <x> in and this wierd screen poped up that I could kind of edit" into google answered that question in the top result.
Sure, like I wrote elsewhere in the thread, it's probably less of a complete roadblock than it used to be. But it's still an unnecessary pain point. Yes, people can probably get through it in fifteen minutes these days, but it's still unnecessarily annoying. Why cause them the trouble?
Thats a fair question. I thinik the best answer I could give is one of balance. I can't argue that it may be a pain point for new users, but for our existing user base, the change to something else is a hassle (arguably less of a hassle because they have learned how to set the default to what they want, but I never like the idea of our creating more work for our existing users when we don't know that an equally large portion of new users will benefit). I say that keeping in mind that we're assuming that new users will struggle with vi, I think its also possible that new users will have my good experience with this sort of roadblock, as much so as the negative experience you had.
Neil
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, 2020-06-26 at 13:37 -0400, Neil Horman wrote:
Mint's default seems to be nano, though like openSUSE, it is doing this some way other than by setting $EDITOR.
Mints just a derivative of openSuse, isn't it? It would make sense that this followed.
I thought it was a derivative of Debian and/or Ubuntu? Wikipedia has it in the 'Ubuntu derivatives' category. But anyhow, it doesn't behave like openSUSE, it doesn't have the weird mix - for all three tests I used (visudo, git, systemctl edit) I got nano.
So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using nano is pretty significant.
Yeah, but significant in what way? We have two fairly popular distributions using nano, but over 1,000,000 people trying to figure out how to exit vi on stackexchange. Is the user base for other distros defaulting to vi just that much bigger?
Dunno. Maybe if Debian and Ubuntu defaulted to vi there'd be 5,000,000 people? :D
On Fri, Jun 26, 2020 at 1:45 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2020-06-26 at 13:37 -0400, Neil Horman wrote:
Mint's default seems to be nano, though like openSUSE, it is doing this some way other than by setting $EDITOR.
Mints just a derivative of openSuse, isn't it? It would make sense that this followed.
I thought it was a derivative of Debian and/or Ubuntu? Wikipedia has it in the 'Ubuntu derivatives' category. But anyhow, it doesn't behave like openSUSE, it doesn't have the weird mix - for all three tests I used (visudo, git, systemctl edit) I got nano.
Linux Mint is a derivative of Ubuntu, thus is a member of the Debian family.
So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using nano is pretty significant.
Yeah, but significant in what way? We have two fairly popular distributions using nano, but over 1,000,000 people trying to figure out how to exit vi on stackexchange. Is the user base for other distros defaulting to vi just that much bigger?
Dunno. Maybe if Debian and Ubuntu defaulted to vi there'd be 5,000,000 people? :D
Probably! :D
On Fri, Jun 26, 2020 at 10:43:10AM -0700, Adam Williamson wrote:
Mints just a derivative of openSuse, isn't it? It would make sense that this followed.
I thought it was a derivative of Debian and/or Ubuntu? Wikipedia has it in the 'Ubuntu derivatives' category. But anyhow, it doesn't behave like openSUSE, it doesn't have the weird mix - for all three tests I used (visudo, git, systemctl edit) I got nano.
It is an Ubuntu derivative, with a back-up version which pulls directly from Debian.
On Fri, Jun 26, 2020 at 10:43:10AM -0700, Adam Williamson wrote:
On Fri, 2020-06-26 at 13:37 -0400, Neil Horman wrote:
Mint's default seems to be nano, though like openSUSE, it is doing this some way other than by setting $EDITOR.
Mints just a derivative of openSuse, isn't it? It would make sense that this followed.
I thought it was a derivative of Debian and/or Ubuntu? Wikipedia has it in the 'Ubuntu derivatives' category. But anyhow, it doesn't behave like openSUSE, it doesn't have the weird mix - for all three tests I used (visudo, git, systemctl edit) I got nano.
So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using nano is pretty significant.
Yeah, but significant in what way? We have two fairly popular distributions using nano, but over 1,000,000 people trying to figure out how to exit vi on stackexchange. Is the user base for other distros defaulting to vi just that much bigger?
Dunno. Maybe if Debian and Ubuntu defaulted to vi there'd be 5,000,000 people? :D
Possibly :)
I guess the real conclusion we can imply here is that new users just use whatever the default is.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, Jun 26, 2020 at 10:15 am, Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2020-06-26 at 12:39 -0400, Neil Horman wrote:
Also, have we asked the question, what default editor are other distros setting? I've honestly never looked.
I believe no major distro currently sets $EDITOR, so we would be the first.
Debian/Ubuntu/Mint use https://salsa.debian.org/debian/sensible-utils for this. I checked Ubuntu yesterday and they build git with DEFAULT_EDITOR=editor, which chooses nano. (They also use DEFAULT_PAGER=pager, which I guess is how you would allow configuring 'most'.)
An earlier version of the change proposal involved packaging up these Debain tools, but I suggested that setting $EDITOR would be a whole lot easier.
On the other hand, if we were to package sensible-utils, it's likely other independent distros would follow, and we would turn it into a cross-distro standard. So it's worth considering.
Michael
On 6/26/20 10:33 AM, Neil Horman wrote:
If I google how to quit vi, I see a full 10 pages of the answer to the question documented in detail
The fact that people have to google their way out of such a mundane circumstance is in my opinion enough to give this proposal a:
+1
As background, I am well familiar with vi and I rarely change the EDITOR to emacs, even though it's my own preference.
There are two reasons:
* vi starts instantly and emacs doesn't,
* emacs leaves the *~ files around, and most contexts in which 'vi' is being used is simple enough that my knowledge of vi is sufficient and I don't need the backup files.
Nano comes out favorably in both cases, so even though I have never used it before I think it's a better choice than both vi and emacs.
On 26/06/20 08:43 -0400, Neil Horman wrote:
On Fri, Jun 26, 2020 at 01:27:54PM +0100, Jonathan Wakely wrote:
On 26/06/20 09:22 -0300, Sergio Belkin wrote:
Really do we believe that setting nano as a default editor will attract new users to Linux? How many end users in last years use Debian because of the default editor change? A newbie generally does know nothing about vi/vim, cron, git, etc...
The proposal doesn't say it will *attract* new users. I think the point is to not frustrate users who have already decided to try Fedora.
Do we have real stasitics on this (somthing in the form of bz reports or comments on a list) indicating that users actually are frustrated with being
Finding/using Bugzilla or a mailing list are apparently almost as arcane as using vi to many people, even developers.
I can't find any questions about it at ask.fedoraproject.org, but that probably isn't most people's first place to go for help anyway.
confronted with vi unexpectedly? Given the initially presented use case (having git-commit or git-rebase pop up vi as the default editor), I'm struggling with the notion that an individual user is sufficiently skilled to use git on the command line, yet struggles to find information on the editor git uses by
There are thousands of "how to use git" pages describing using the command line TUI. I bet only the better pages think to mention using vi.
Users familiar with version control from another OS might want to try doing it on the command line in Fedora, and stumble when they get to the editor step.
default. It seems somewhat inconsistent to me. Thats not to say its not a real problem, but it feels a bit like we're taking action on an issue that may not be a problem, at the expense of existing users that like the environment the way it is.
See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... for actual numbers, to be taken with a large pinch of salt (we have no way to know how relevant those searches are to Fedora users).
On Fri, Jun 26, 2020 at 02:01:05PM +0100, Jonathan Wakely wrote:
On 26/06/20 08:43 -0400, Neil Horman wrote:
On Fri, Jun 26, 2020 at 01:27:54PM +0100, Jonathan Wakely wrote:
On 26/06/20 09:22 -0300, Sergio Belkin wrote:
Really do we believe that setting nano as a default editor will attract new users to Linux? How many end users in last years use Debian because of the default editor change? A newbie generally does know nothing about vi/vim, cron, git, etc...
The proposal doesn't say it will *attract* new users. I think the point is to not frustrate users who have already decided to try Fedora.
Do we have real stasitics on this (somthing in the form of bz reports or comments on a list) indicating that users actually are frustrated with being
Finding/using Bugzilla or a mailing list are apparently almost as arcane as using vi to many people, even developers.
I can't find any questions about it at ask.fedoraproject.org, but that probably isn't most people's first place to go for help anyway.
And thats fine, I'd stipulate that stackoverflow is probably de rigueur these days for people to ask and answer questions. The goal more was to get feedback "from the horses mouth" so to speak, rather than to presume we fully understand what the pain point is here.
confronted with vi unexpectedly? Given the initially presented use case (having git-commit or git-rebase pop up vi as the default editor), I'm struggling with the notion that an individual user is sufficiently skilled to use git on the command line, yet struggles to find information on the editor git uses by
There are thousands of "how to use git" pages describing using the command line TUI. I bet only the better pages think to mention using vi.
I'd agree with that, but I'd also suggest that there are thousands of "how to use vi" pages describing how to navigate the editor. The only bit that I think is missing is the connection to help people realize what editor they are using.
Users familiar with version control from another OS might want to try doing it on the command line in Fedora, and stumble when they get to the editor step.
Thats fair, and this is actually an interesting point. I think (correct me if I'm wrong), that those users are likely comming from an environment that is graphical in nature, and for those users, the "big step" so to speak is less about the choice of editor, and more about the movement from a gui to a tui or cli. In those cases, nano might help some, but its still going to be a very foreign environment, they're still going to have to figure out that ^x means Ctrl-x, etc, and for that they may still have to go ask a question somewhere.
default. It seems somewhat inconsistent to me. Thats not to say its not a real problem, but it feels a bit like we're taking action on an issue that may not be a problem, at the expense of existing users that like the environment the way it is.
See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... for actual numbers, to be taken with a large pinch of salt (we have no way to know how relevant those searches are to Fedora users).
Yeah, the referenced article: https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-dev...
is interesting, both for the explicit fact that 1,000,000 people had to ask how to exit vi (bad), and for the more subtle implicit fact that, at least 1,000,000 people are using vi, got the answer to the question they were looking for (good), and presumably kept using vi (unknown).
Interesting side note (possibly unrelated), there are almost no questions on stackoverflow related to how to change the default editor (at least that my limited searching skills can find).
Best Neil
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, 2020-06-26 at 11:42 -0400, Neil Horman wrote:
is interesting, both for the explicit fact that 1,000,000 people had to ask how to exit vi (bad), and for the more subtle implicit fact that, at least 1,000,000 people are using vi, got the answer to the question they were looking for (good), and presumably kept using vi (unknown).
Also 1,000,000 people unnecessarily had to answer the same question again (bad).
From this thread you can find at least two people (me and Ben Rosser) who definitely didn't keep using vi (my very next questions were "what's an easier editor to use?" and "how do I change the default editor to something else?"), and are still sufficiently frazzled by the experience that we still refuse to. :P
On Fri, Jun 26, 2020 at 08:54:42AM -0700, Adam Williamson wrote:
On Fri, 2020-06-26 at 11:42 -0400, Neil Horman wrote:
is interesting, both for the explicit fact that 1,000,000 people had to ask how to exit vi (bad), and for the more subtle implicit fact that, at least 1,000,000 people are using vi, got the answer to the question they were looking for (good), and presumably kept using vi (unknown).
Also 1,000,000 people unnecessarily had to answer the same question again (bad).
Not to nitpick, but 1,000,000 asked the question. It only had to be answered once (or only answered N times, where N << 10^6, and equal to the number of recorded unique questions on stackexchange). I only point it out because the effort in answering the question is hard, asking the question is easy, especially when its already been answered, as a quick answer provides, if not a great user experience, a better one than having to answer it 10^6 times, or not being able to find an answer at all.
From this thread you can find at least two people (me and Ben Rosser) who definitely didn't keep using vi (my very next questions were "what's an easier editor to use?" and "how do I change the default editor to something else?"), and are still sufficiently frazzled by the experience that we still refuse to. :P
Right, and I acutally think thats great. You had a problem, you asked the questions you needed answers to, and solved your problem. I personally think the process of identifying whats bothering you, figuring out a solution (by asking questions, getting answers and experimenting), and then implementing your fix is actually a pretty good user experience in and of itself (though that may just be me). :) It suggests that I know what I'm doing, and I am in control of the system that I'm working on. I felt that way the first time that I downloaded slackware around 1996 and had to figure out how to use ppp to establish a dial up connection to my university (side note, in those days, the bits had to travel over the phone line uphill.....both ways) :)
Neil
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
From this thread you can find at least two people (me and Ben Rosser) who definitely didn't keep using vi (my very next questions were "what's an easier editor to use?" and "how do I change the default editor to something else?"), and are still sufficiently frazzled by the experience that we still refuse to. :P
Right, and I acutally think thats great. You had a problem, you asked the questions you needed answers to, and solved your problem. I personally think the process of identifying whats bothering you, figuring out a solution (by asking questions, getting answers and experimenting), and then implementing your fix is actually a pretty good user experience in and of itself (though that may just be me). :)
That is not how it felt at the time :P
It's really the point about Unexpected Forcible Learning. If I sit down at my computer and think "right, I'm going to learn to do X", that's one thing. I am mentally prepared to spend some time stumbling around working out how to do X.
The problem with this experience is that's not how it happens. You don't sit down and thinking "today I'm going to learn how to use vi" or "today I'm going to learn about console text editors and the $EDITOR variable". You were intending to do something else, and you were suddenly sandbagged by this fracking weird thing you have no idea what it is that got in the way of the something else you were trying to do.
Yes, eventually you learn something, but it's not a "pretty good user experience", it is a frustrating and annoying one.
On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote:
On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
From this thread you can find at least two people (me and Ben Rosser) who definitely didn't keep using vi (my very next questions were "what's an easier editor to use?" and "how do I change the default editor to something else?"), and are still sufficiently frazzled by the experience that we still refuse to. :P
Right, and I acutally think thats great. You had a problem, you asked the questions you needed answers to, and solved your problem. I personally think the process of identifying whats bothering you, figuring out a solution (by asking questions, getting answers and experimenting), and then implementing your fix is actually a pretty good user experience in and of itself (though that may just be me). :)
That is not how it felt at the time :P
It's really the point about Unexpected Forcible Learning. If I sit down at my computer and think "right, I'm going to learn to do X", that's one thing. I am mentally prepared to spend some time stumbling around working out how to do X.
The problem with this experience is that's not how it happens. You don't sit down and thinking "today I'm going to learn how to use vi" or "today I'm going to learn about console text editors and the $EDITOR variable". You were intending to do something else, and you were suddenly sandbagged by this fracking weird thing you have no idea what it is that got in the way of the something else you were trying to do.
Yes, eventually you learn something, but it's not a "pretty good user experience", it is a frustrating and annoying one.
But thats more or less the expectation of unix and unix like systems. For all the porcelain and chrome we've put around it, under the covers, its all still a bag of parts, and the expectation is (or should be) when using a bag of parts, you will have to learn how several of those parts work (be it vi or nano when using git, or substitue your tool of choice here). You start with a tool, you relize it relies on another tool, so you have to push it down the stack and figure out the new tool as part of the overall process.
I'll share a simmilar experience to commiserate. During this thread, I went to go confirm that eclipse actually used its own internal git editor for adding commit messages. Thought it was going to be easy. Quickly realized that eclipse didn't come with git integration out of the box, so I had to go figure out how to get git support in, then how to configure it, then how to interface to it. It all felt like kinda the same tool, because it all happened in one of a few related windows, but its really learning several disparate tools, and thats ok. I still don't like using eclipse, but not because it made me go figure out several new tools, I don't like it because it seems nuts to me to have an IDE with a 400M Resident set size to edit ascii text. :)
Heres a thought that I hadn't considered before though, and it might be useful. Apple at one point (and still may), shiped iphones without the itunes (or some common) app on it, and they did so intentionally, because they knew it was an app that people wanted, and it forced them into a sort of 'training mission' in which they had to use the app store on their phone to find and install the itunes app. It gave end users, after their initial disgruntledness, the skills to install new apps on their phone, and explore how some of the system worked.
Would that be a possibility here? I've upgraded my fedora workstation so many times, I'm not sure what our firstboot screens look like anymore, but would it be worthwhile to present users with some text, or a guide wizard, to point out files like their ~/.bashrc file with some commented text that shows clearly what some useful environment variables are, and how they might set them to customize their experience? Its not very 'just press the button to do something you may or may not understand', but it targets new users as part of firstboot, and introduces them in a somewhat friendly way to how things look under the covers, so they can make adjustments as their needs dictate. Even if they don't do it immediately, they will have a reference to something they can recall if they find later that their choice of editor is not something they are comfortable with.
Neil
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, Jun 26, 2020 at 01:23:17PM -0400, Neil Horman wrote:
But thats more or less the expectation of unix and unix like systems. For all the porcelain and chrome we've put around it, under the covers, its all still a bag of parts, and the expectation is (or should be) when using a bag of parts, you will have to learn how several of those parts work (be it vi or nano when using git, or substitue your tool of choice here). You start with a tool, you relize it relies on another tool, so you have to push it down the stack and figure out the new tool as part of the overall process.
So.... *my* expectation is that as a distro, part of the value we add is to take those parts and provide them to users in a coherent way that addresses their problems. We want to provide a "bag of parts" to people _in the Fedora Project_, but we want to enable those groups to provide assembled sets to their users.
Would that be a possibility here? I've upgraded my fedora workstation so many times, I'm not sure what our firstboot screens look like anymore, but would it be worthwhile to present users with some text, or a guide wizard, to point out files like their ~/.bashrc file with some commented text that shows clearly what some useful environment variables are, and how they might set them to customize their experience? Its not very 'just press the button to do something you may or may not understand', but it targets new users as part of firstboot, and introduces them in a somewhat friendly way to how things look under the covers, so they can make adjustments as their needs dictate. Even if they don't do it immediately, they will have a reference to something they can recall if they find later that their choice of editor is not something they are comfortable with.
I don't think this is the experience most Fedora Workstation users are looking for. But I'd totally support the creation of a "Learn Linux!" Fedora spin with this kind of pedagogical self-teaching focus.
On Fri, Jun 26, 2020 at 01:23:17PM -0400, Neil Horman wrote:
On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote:
On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
From this thread you can find at least two people (me and Ben Rosser) who definitely didn't keep using vi (my very next questions were "what's an easier editor to use?" and "how do I change the default editor to something else?"), and are still sufficiently frazzled by the experience that we still refuse to. :P
Right, and I acutally think thats great.ÃÂ You had a problem, you asked the questions you needed answers to, and solved your problem.ÃÂ I personally think the process of identifying whats bothering you, figuring out a solution (by asking questions, getting answers and experimenting), and then implementing your fix is actually a pretty good user experience in and of itself (though that may just be me). :)
That is not how it felt at the time :P
It's really the point about Unexpected Forcible Learning. If I sit down at my computer and think "right, I'm going to learn to do X", that's one thing. I am mentally prepared to spend some time stumbling around working out how to do X.
The problem with this experience is that's not how it happens. You don't sit down and thinking "today I'm going to learn how to use vi" or "today I'm going to learn about console text editors and the $EDITOR variable". You were intending to do something else, and you were suddenly sandbagged by this fracking weird thing you have no idea what it is that got in the way of the something else you were trying to do.
Yes, eventually you learn something, but it's not a "pretty good user experience", it is a frustrating and annoying one.
But thats more or less the expectation of unix and unix like systems. For all the porcelain and chrome we've put around it, under the covers, its all still a bag of parts, and the expectation is (or should be) when using a bag of parts, you will have to learn how several of those parts work (be it vi or nano when using git, or substitue your tool of choice here). You start with a tool, you relize it relies on another tool, so you have to push it down the stack and figure out the new tool as part of the overall process.
I'll share a simmilar experience to commiserate. During this thread, I went to go confirm that eclipse actually used its own internal git editor for adding commit messages. Thought it was going to be easy. Quickly realized that eclipse didn't come with git integration out of the box, so I had to go figure out how to get git support in, then how to configure it, then how to interface to it. It all felt like kinda the same tool, because it all happened in one of a few related windows, but its really learning several disparate tools, and thats ok. I still don't like using eclipse, but not because it made me go figure out several new tools, I don't like it because it seems nuts to me to have an IDE with a 400M Resident set size to edit ascii text. :)
Heres a thought that I hadn't considered before though, and it might be useful. Apple at one point (and still may), shiped iphones without the itunes (or some common) app on it, and they did so intentionally, because they knew it was an app that people wanted, and it forced them into a sort of 'training mission' in which they had to use the app store on their phone to find and install the itunes app. It gave end users, after their initial disgruntledness, the skills to install new apps on their phone, and explore how some of the system worked.
I'm not sure that's a good comparison. Are we trying to force train new vi users or gain new Fedora users and developers? Fedora doesn't have a business interest in users being forced to learn vi like Apple does with users learning to use the App Store.
Would that be a possibility here? I've upgraded my fedora workstation so many times, I'm not sure what our firstboot screens look like anymore, but would it be worthwhile to present users with some text, or a guide wizard, to point out files like their ~/.bashrc file with some commented text that shows clearly what some useful environment variables are, and how they might set them to customize their experience? Its not very 'just press the button to do something you may or may not understand', but it targets new users as part of firstboot, and introduces them in a somewhat friendly way to how things look under the covers, so they can make adjustments as their needs dictate. Even if they don't do it immediately, they will have a reference to something they can recall if they find later that their choice of editor is not something they are comfortable with.
Sounds like something suitable for gnome-initial-setup. I think /etc/motd with that info would be useful on the non-workstation releases. Slackware always installed a "welcome" email to the root user with similar info. OpenBSD has 'man afterboot'. There's a lot we can do here. The common thing appears to be helping guide the user. For text editing, nano does that better by default than other text editors.
Thanks,
On Friday, June 26, 2020 10:53:59 AM MST David Cantrell wrote:
On Fri, Jun 26, 2020 at 01:23:17PM -0400, Neil Horman wrote:
On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote:
On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
From this thread you can find at least two people (me and Ben Rosser) who definitely didn't keep using vi (my very next questions were "what's an easier editor to use?" and "how do I change the default editor to something else?"), and are still sufficiently frazzled by the experience that we still refuse to. :P
Right, and I acutally think thats great.ÃÂ You had a problem, you asked the questions you needed answers to, and solved your problem.ÃÂ I personally think the process of identifying whats bothering you, figuring out a solution (by asking questions, getting answers and experimenting), and then implementing your fix is actually a pretty good user experience in and of itself (though that may just be me). :)
That is not how it felt at the time :P
It's really the point about Unexpected Forcible Learning. If I sit down at my computer and think "right, I'm going to learn to do X", that's one thing. I am mentally prepared to spend some time stumbling around working out how to do X.
The problem with this experience is that's not how it happens. You don't sit down and thinking "today I'm going to learn how to use vi" or "today I'm going to learn about console text editors and the $EDITOR variable". You were intending to do something else, and you were suddenly sandbagged by this fracking weird thing you have no idea what it is that got in the way of the something else you were trying to do.
Yes, eventually you learn something, but it's not a "pretty good user experience", it is a frustrating and annoying one.
But thats more or less the expectation of unix and unix like systems. For all
the porcelain and chrome we've put around it, under the covers, its
all still a bag of parts, and the expectation is (or should be) when using a bag of parts, you will have to learn how several of those parts work (be it vi or nano when using git, or substitue your tool of choice here). You start with a tool, you relize it relies on another tool, so you have to push it down the stack and figure out the new tool as part of the overall process.
I'll share a simmilar experience to commiserate. During this thread, I went to
go confirm that eclipse actually used its own internal git editor
for adding commit messages. Thought it was going to be easy. Quickly realized that eclipse didn't come with git integration out of the box, so I had to go figure out how to get git support in, then how to configure it, then how to interface to it. It all felt like kinda the same tool, because it all happened in one of a few related windows, but its really learning several disparate tools, and thats ok. I still don't like using eclipse, but not because it made me go figure out several new tools, I don't like it because it seems nuts to me to have an IDE with a 400M Resident set size to edit ascii text. :)
Heres a thought that I hadn't considered before though, and it might be useful.
Apple at one point (and still may), shiped iphones without the
itunes (or some common) app on it, and they did so intentionally, because they knew it was an app that people wanted, and it forced them into a sort of 'training mission' in which they had
to use the app store on their phone to find and install the itunes
app. It gave end users, after their initial disgruntledness, the skills to install new apps on their phone, and explore how some of the system worked.
I'm not sure that's a good comparison. Are we trying to force train new vi users or gain new Fedora users and developers? Fedora doesn't have a business interest in users being forced to learn vi like Apple does with users learning to use the App Store.
Would that be a possibility here? I've upgraded my fedora workstation so many times, I'm not sure what our firstboot screens look like anymore, but would it be worthwhile to present users with some text, or a guide wizard, to point out files like their ~/.bashrc file with some commented text that shows clearly what some useful environment variables are, and how they might set them to customize their experience? Its not very 'just press the button to do something you may or may not understand', but it targets new users as part of firstboot, and introduces them in a somewhat friendly way to how things look under the covers, so they can make adjustments as their needs dictate. Even if they don't do it immediately, they will have a reference to something they can recall if they find later that their choice of editor is not something they are comfortable with.
Sounds like something suitable for gnome-initial-setup. I think /etc/motd with that info would be useful on the non-workstation releases. Slackware always installed a "welcome" email to the root user with similar info. OpenBSD has 'man afterboot'. There's a lot we can do here. The common thing appears to be helping guide the user. For text editing, nano does that better by default than other text editors.
Thanks,
-- David Cantrell dcantrell@redhat.com Red Hat, Inc. | Boston, MA | EST5EDT
Please keep in mind that there is more to Fedora desktop than the GNOME Spin. There's nothing like gnome-initial-setup for KDE Spin, or any of the other desktops.
On 26/06/20 13:23 -0400, Neil Horman wrote:
Heres a thought that I hadn't considered before though, and it might be useful. Apple at one point (and still may), shiped iphones without the itunes (or some common) app on it, and they did so intentionally, because they knew it was an app that people wanted, and it forced them into a sort of 'training mission' in which they had to use the app store on their phone to find and install the itunes app. It gave end users, after their initial disgruntledness, the skills to install new apps on their phone, and explore how some of the system worked.
That's not about learning useful life skills, it's about forcing them to visit the money-making machine.
I don't think "I had to learn vi and it never did me any harm, new users should have to as well" is really the right approach for the distro.
Shut up and learn vi, it's for your own good. And eat your vegetables or you won't get dessert.
On Fri, Jun 26, 2020 at 07:04:51PM +0100, Jonathan Wakely wrote:
On 26/06/20 13:23 -0400, Neil Horman wrote:
Heres a thought that I hadn't considered before though, and it might be useful. Apple at one point (and still may), shiped iphones without the itunes (or some common) app on it, and they did so intentionally, because they knew it was an app that people wanted, and it forced them into a sort of 'training mission' in which they had to use the app store on their phone to find and install the itunes app. It gave end users, after their initial disgruntledness, the skills to install new apps on their phone, and explore how some of the system worked.
That's not about learning useful life skills, it's about forcing them to visit the money-making machine.
ulterior motives asside, the goal was still to implicitly teach the end users how to use a central tool in their environment.
I don't think "I had to learn vi and it never did me any harm, new users should have to as well" is really the right approach for the distro.
I'm not sure how you got that out of my comment above, but it certainly wasn't my intent. All I was trying to say was, orthogonal to the choice of default editor, part of the frustration here seems to be not only understanding how vi works but how to go about changing it if it doesn't work for you (as suggested by the large number of searches for vi help, and the relatively non-existant number of searches for "how do I change my default editor in linux". I was suggesting that some sort of introductory guide during install might mitigate that.
Shut up and learn vi, it's for your own good. And eat your vegetables or you won't get dessert.
Ok, that a bit over the line. Please don't twist my words.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri, 26 Jun 2020 13:23:17 -0400, you wrote:
Heres a thought that I hadn't considered before though, and it might be useful. Apple at one point (and still may), shiped iphones without the itunes (or some common) app on it, and they did so intentionally, because they knew it was an app that people wanted, and it forced them into a sort of 'training mission' in which they had to use the app store on their phone to find and install the itunes app. It gave end users, after their initial disgruntledness, the skills to install new apps on their phone, and explore how some of the system worked.
I can't comment if that was ever true, but it certainly hasn't been the case for a very long time - it wasn't an issue on the first iPad.
Would that be a possibility here? I've upgraded my fedora workstation so many times, I'm not sure what our firstboot screens look like anymore, but would it be worthwhile to present users with some text, or a guide wizard, to point out files like their ~/.bashrc file with some commented text that shows clearly what some useful environment variables are, and how they might set them to customize their experience? Its not very 'just press the button to do something you may or may not understand', but it targets new users as part of firstboot, and introduces them in a somewhat friendly way to how things look under the covers, so they can make adjustments as their needs dictate.
At which point they realize choosing Fedora was a mistake, and they go to Ubuntu like all their friends suggested in the first place.
On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote:
On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
From this thread you can find at least two people (me and Ben Rosser) who definitely didn't keep using vi (my very next questions were "what's an easier editor to use?" and "how do I change the default editor to something else?"), and are still sufficiently frazzled by the experience that we still refuse to. :P
Right, and I acutally think thats great. You had a problem, you asked the questions you needed answers to, and solved your problem. I personally think the process of identifying whats bothering you, figuring out a solution (by asking questions, getting answers and experimenting), and then implementing your fix is actually a pretty good user experience in and of itself (though that may just be me). :)
That is not how it felt at the time :P
It's really the point about Unexpected Forcible Learning. If I sit down at my computer and think "right, I'm going to learn to do X", that's one thing. I am mentally prepared to spend some time stumbling around working out how to do X.
The problem with this experience is that's not how it happens. You don't sit down and thinking "today I'm going to learn how to use vi" or "today I'm going to learn about console text editors and the $EDITOR variable". You were intending to do something else, and you were suddenly sandbagged by this fracking weird thing you have no idea what it is that got in the way of the something else you were trying to do.
Yes, eventually you learn something, but it's not a "pretty good user experience", it is a frustrating and annoying one.
/me puts a tinfoil hat on
what if... what IF ... this whole "vi by default" is a huge conspiracy by the emacs people to make new users hate vi from the earliest stages, thus providing a welcoming environment for them to swoop in and save them with promises of strange shortcuts! I knew it all along!
/me completely wraps himself in tinfoil [1]
[1] well, aluminium foil because it's too hard to get decent tinfoil these days, not like back in my days when it was snowing uphill both ways
On Fri, 26 Jun 2020 at 19:06, Neil Horman nhorman@redhat.com wrote:
Right, and I acutally think thats great. You had a problem, you asked the questions you needed answers to, and solved your problem. I personally think the process of identifying whats bothering you, figuring out a solution (by asking questions, getting answers and experimenting), and then implementing your fix is actually a pretty good user experience in and of itself (though that may just be me). :)
And that's why actual UX people are so important. Don't say "user experience" when you mean "nerd experience". :)
El vie., 26 jun. 2020 a las 9:29, Jonathan Wakely (< jwakely@fedoraproject.org>) escribió:
On 26/06/20 09:22 -0300, Sergio Belkin wrote:
Really do we believe that setting nano as a default editor will attract
new
users to Linux? How many end users in last years use Debian because of the default editor change? A newbie generally does know nothing about vi/vim, cron, git, etc...
The proposal doesn't say it will *attract* new users.
Yes, you'right . The problem is not the proposal itself but the "arguments" of their supporters :)
On Fri, 2020-06-26 at 14:03 +0200, Theodore Papadopoulo wrote:
Then I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
This seems the best approach in my opinion. I totally agree that having something simple is important for new users. My only fear (and it applies to any default editor choice) is that the default will be changed only by a minority of new-users, or after many months.
FWIW, I still use nano *precisely because* getting vi thrown at me so unexpectedly was so damn annoying I flat out refuse to learn it. In other words, being the default was *actively harmful* to vi's chances in my case. :P
On Fri, Jun 26, 2020 at 11:27 AM Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2020-06-26 at 14:03 +0200, Theodore Papadopoulo wrote:
Then I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
This seems the best approach in my opinion. I totally agree that having something simple is important for new users. My only fear (and it applies to any default editor choice) is that the default will be changed only by a minority of new-users, or after many months.
FWIW, I still use nano *precisely because* getting vi thrown at me so unexpectedly was so damn annoying I flat out refuse to learn it. In other words, being the default was *actively harmful* to vi's chances in my case. :P
Same here, to be honest. Being dropped into vi when I ran some command (I think it was visudo?) was honestly pretty traumatizing as a new Linux user a ~decade ago, and to this day one of the first things I do on a new Fedora system is set EDITOR=nano in my .bashrc.
I strongly support this change.
Ben Rosser
----- Original Message -----
Adam Williamson < adamwill@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user.
It's a nice idea, but the problem with things like this is they *always* introduce bugs, and often wind up being unmaintained, because keeping them working is kind of a thankless task.
IMHO it's better to keep things simple and just pick a default. And the default should definitely be nano. :D Then I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
I has been asked "how to exit this hell?" multiple times by my new-to-Linux friends, that time I would always suggest them to set nano as default. Vim is great though, it is not for beginners.
Why not just patch vim-minimal to show the hint on the CTRL+C? Problem solved :)
Jaroslav
Jaroslav Skarvada jskarvad@redhat.com 于2020年6月26日周五 下午9:41写道：
----- Original Message -----
Adam Williamson < adamwill@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user.
It's a nice idea, but the problem with things like this is they *always* introduce bugs, and often wind up being unmaintained, because keeping them working is kind of a thankless task.
IMHO it's better to keep things simple and just pick a default. And the default should definitely be nano. :D Then I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
I has been asked "how to exit this hell?" multiple times by my new-to-Linux friends, that time I would always suggest them to set nano as default. Vim is great though, it is not for beginners.
Why not just patch vim-minimal to show the hint on the CTRL+C? Problem solved :)
Ctrl + C in vi will give you a Type :qa and press <Enter> to exit Vim
Jaroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
----- Original Message -----
Jaroslav Skarvada jskarvad@redhat.com 于2020年6月26日周五 下午9:41写道：
----- Original Message -----
Adam Williamson < adamwill@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user.
It's a nice idea, but the problem with things like this is they *always* introduce bugs, and often wind up being unmaintained, because keeping them working is kind of a thankless task.
IMHO it's better to keep things simple and just pick a default. And the default should definitely be nano. :D Then I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
I has been asked "how to exit this hell?" multiple times by my new-to-Linux friends, that time I would always suggest them to set nano as default. Vim is great though, it is not for beginners.
Why not just patch vim-minimal to show the hint on the CTRL+C? Problem solved :)
Ctrl + C in vi will give you a Type :qa and press <Enter> to exit Vim
Thanks for info, I didn't know :) So I can't see any problem there and it's just about the personal preference
thanks & regards
Jaroslav
Spoiler alert :)
It already does.
On 6/26/20 3:41 PM, Jaroslav Skarvada wrote:
----- Original Message -----
Adam Williamson < adamwill@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user.
It's a nice idea, but the problem with things like this is they *always* introduce bugs, and often wind up being unmaintained, because keeping them working is kind of a thankless task.
IMHO it's better to keep things simple and just pick a default. And the default should definitely be nano. :D Then I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
I has been asked "how to exit this hell?" multiple times by my new-to-Linux friends, that time I would always suggest them to set nano as default. Vim is great though, it is not for beginners.
Why not just patch vim-minimal to show the hint on the CTRL+C? Problem solved :)
Jaroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Sorry for duplicate, it was already answered.
On 6/29/20 7:10 AM, Zdenek Dohnal wrote:
Spoiler alert :)
It already does.
On 6/26/20 3:41 PM, Jaroslav Skarvada wrote:
----- Original Message -----
Adam Williamson < adamwill@fedoraproject.org > 于 2020年6月26日周五 上午9:32写道：
On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user.
It's a nice idea, but the problem with things like this is they *always* introduce bugs, and often wind up being unmaintained, because keeping them working is kind of a thankless task.
IMHO it's better to keep things simple and just pick a default. And the default should definitely be nano. :D Then I will +1 for this proposal. Yes, this certainly will make Fedora easier use for beginners. And for those who would like to use vi as default, we should make this as easy as possible.
I has been asked "how to exit this hell?" multiple times by my new-to-Linux friends, that time I would always suggest them to set nano as default. Vim is great though, it is not for beginners.
Why not just patch vim-minimal to show the hint on the CTRL+C? Problem solved :)
Jaroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Fri Jun 26, 2020 at 9:44 AM WAT, Qiyu Yan wrote:
What about to provide a prompt to the user telling them the difference between editors? For example, when a new user to fedora first invokes git commit without $EDITOR set, a program named fedora-default-editor comes up and asks: Which editor do you like? User can do his or hers choice and the choice will be remembered by setting $EDITOR in his or hers ~/.bashrc
The fedora-default-editor can be a small script that shows user all the difference and set $EDITOR for the user.
+1, but I think it's better to set the variable in ~/.profile to make it shell agnostic.
To be honest, I'm sad about the change.
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.
When I was new to Linux (when I attended a university), I stumbled over the same issue which is used to advocate for the change here - I wasn't able to write properly in Vi during time limited exercise for points :) . Thankfully, I was able to finish in time in the end with friend's help.
But my mindset wasn't 'Damn, why did someone choose such unintuitive thing for default editor, it should be changed.', but rather 'Dang, I need to learn more, it wasn't that hard.'
And I had a nice feeling that I learnt something new after time :) .
I always thought Fedora community has plenty of people who like to learn rather than complain, so the argument about a person needs to spend time to learn two commands: 'i' and ':x' to being able to commit (not much else is needed for 'basic' usage. Yes, if you want to write effectively you will need to learn more, but IMHO it is sufficient for commit messages), is quite strange to me.
But I understand someone can be surprised when committing for the first time and git-commit opens a file for him and you don't know the editor it uses.
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.
On 6/25/20 7:18 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/UseNanoByDefault
== Summary ==
Let's make Fedora more approachable, by having a default editor that doesn't require specialist knowledge to use.
== Owner ==
- Name: [[User:chrismurphy| Chris Murphy]]
- Email: chrismurphy@fedoraproject.org
== Detailed Description ==
Users are exposed to the default editor when they use commands that call it. The main example here is something like <code>git commit</code>.
Fedora does not currently have a default terminal text editor, because the $EDITOR environment variable is unset by default. But a common scenario where users wind up in a terminal text editor is when using 'git commit'. By default, git picks vi. You need to spend time learning how to use it, for even basic editing tasks. This increases the barrier to entry for those who are switching to Fedora and don't know how to use vi. It also makes things hard for those who don't particularly want to learn how to use vi. (These arguments would apply just as well if git picked Vim. vi is like hard mode for Vim, with fewer features, missing syntax highlighting, and no indication of what mode you are in. Even Vim users may feel lost and bewildered when using vi.)
In contrast, Nano offers the kind of graphical text editing experience that people are used to, and therefore doesn't require specialist knowledge to use. It is already installed across most Fedora Editions and Spins. This proposal will make Nano the default editor, while continuing to install <code>vim-minimal</code> (which provides vi, but not Vim). People will still be able to call <code>vi</code> if they want to edit a file. It will also obviously be possible to change the default editor to vi or Vim, for those who want it.
Why make Nano default and vi optional, rather than the other way round? Because Nano is the option that everyone can use.
== Feedback ==
Pending ...
== Benefit to Fedora ==
- Makes the default editor across all of Fedora more approachable.
- Nano is also mostly self-documenting, by displaying common keyboard
shortcuts on-screen.
- More in line with the default editor of other distributions.
== Scope ==
- Proposal owners:
** Modify comps to include nano Fedora wide. ** Create a new subpackage of <code>nano</code>, called <code>nano-editor</code>. ** <code>nano-editor</code> to include <code>/usr/lib/environment.d/10-nano.conf</code>, which sets <code>$EDITOR</code> to <code>nano</code>.
With this approach, if <code>nano</code> is uninstalled, the configuration will be removed with it. At the same time, installing nano on its own won't install the conf.
Other developers: N/A
Release engineering: [https://pagure.io/releng/issue/9522 #9522]
Policies and guidelines: N/A
Trademark approval: N/A
== Upgrade/compatibility impact ==
Will not apply to upgrades.
== How To Test ==
Run <code>export EDITOR="/usr/bin/nano"</code>.
== User Experience ==
Users running <code>git commit</code> will be able to just type their commit message, rather than having to learn about insert mode, and they'll be able to cut and paste without having to learn special shortcuts.
== Dependencies ==
No additional dependencies are required.
== Contingency Plan == The contingency plan is to revert the change by removing the <code>nano-editor</code> package.
- Contingency deadline: probably the beta? It's an easy change to revert.
- Blocks release? If the change breaks the redirection to an editor,
it should block the release. However, this is unlikely.
- Blocks product? Potentially all.
== Documentation == As part of this change, it would be good to add instructions for changing the default editor to the [https://docs.fedoraproject.org/en-US/quick-docs/ quick docs].
Once upon a time, Zdenek Dohnal zdohnal@redhat.com said:
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.
There are a variety of CLI tools that use $EDITOR (do any still use $VISUAL? I still set that out of habit), and usually default to /bin/vi in the absence of a setting. On one desktop system, I see about 20 packages that appear like they might be referencing $EDITOR (just grepping in /usr/bin and /usr/sbin).
I've been using vi/vim for almost 30 years, and have set $EDITOR and $VISUAL for the whole time. I honestly didn't realize $EDITOR wasn't being defaulted to /bin/vi, and we just have programs with their own arbitrary default. So I'm definitely +1 to explicitly setting it.
I would go with /etc/profile.d snippets, because that's the most obvious and historical place (for Red Hat-derived systems at least). Alternately, the default PAM config loads pam_env, which will look in /etc/security/pam_env.conf, /etc/environment, and ~/.pam_environment by default. There's possibly other things that could be moved here; if this isn't a good use for it, I don't know what is (why are we loading pam_env if we aren't going to use it?).
As for the default value of $EDITOR... I don't really care that much, because I both already set it and already know vi. But it is quite obvious that vi is not very user-friendly for the casual/occasional CLI user (someone following some online directions that include "edit this config file" for example). I'd say nano is a little better, as long as you figure out that ^ is Ctrl.
At under 3MB installed, nano is relatively light-weight (although about twice as big as vim-minimal :) ). I would say we should keep vim-minimal as part of the minimal install, as obviously there are programs that use it as a default, and it is smaller.
As a system administrator and developer, I can change defaults myself. These days, I have an Ansible playbook that I run to set up a system to my preferred liking (used to just be a collection of shell scripts). I would assume that developers already set their own defaults for lots of things, as no two developers can ever seem to agree 100% on how everything should be done. :)
On Fri, Jun 26, 2020 at 8:35 AM Chris Adams linux@cmadams.net wrote:
Once upon a time, Zdenek Dohnal zdohnal@redhat.com said:
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.
There are a variety of CLI tools that use $EDITOR (do any still use $VISUAL? I still set that out of habit), and usually default to /bin/vi in the absence of a setting. On one desktop system, I see about 20 packages that appear like they might be referencing $EDITOR (just grepping in /usr/bin and /usr/sbin).
I've been using vi/vim for almost 30 years, and have set $EDITOR and $VISUAL for the whole time. I honestly didn't realize $EDITOR wasn't being defaulted to /bin/vi, and we just have programs with their own arbitrary default. So I'm definitely +1 to explicitly setting it.
I would go with /etc/profile.d snippets, because that's the most obvious and historical place (for Red Hat-derived systems at least). Alternately, the default PAM config loads pam_env, which will look in /etc/security/pam_env.conf, /etc/environment, and ~/.pam_environment by default. There's possibly other things that could be moved here; if this isn't a good use for it, I don't know what is (why are we loading pam_env if we aren't going to use it?).
Actually, if we turn on PAM's support for split distro/admin configuration, we *could* ship this as a pam.d snippet in /usr and allow the admin to override it in /etc if they wish. This might work better than profile.d snippets too, since it'd be one file for all the shells, rather than a bunch of files for every shell.
