Fedora Approves Of Making Nano The Default Terminal Text Editor, Other Features Accepted

[mos87]

Sad to see so many misconceptions about Vim... Not to say its author(s) aren't somewhat responsible for this IMO.
Why not ship a sensibly customized version of Vim, at least alongside with nano? It's perfectly doable and not that hard too.

Also the infatuation with nano as some paragon of user-friendliness is IMO simply due to the fact it draws its basic shortcuts on-screen by default. Which is hardly a) unimplementable (at least in Vim) b) such an amazing feature in itself

So called progressive and inclusive open source management continues to take increasingly anti-ergonomic decisions..

[royce]

nano? The hell with that. Micro. Always like Fedora to be behind the times on anything that isn't GNOME.

Thank you, I didn't know Micro and looks pretty interesting.

[oiaohm]

Sad to see so many misconceptions about Vim... Not to say its author(s) aren't somewhat responsible for this IMO.
Why not ship a sensibly customized version of Vim, at least alongside with nano? It's perfectly doable and not that hard too.

vim-tiny and full vim in fact built out of the upstream Vim project. This is a problem the issue need to be fixed upstream so it spreads downstream. Shipping customised version of vi on one distribution still will equal user will go and use it on another distribution and hit the broken.

Also the infatuation with nano as some paragon of user-friendliness is IMO simply due to the fact it draws its basic shortcuts on-screen by default. Which is hardly a) unimplementable (at least in Vim) b) such an amazing feature in itself

Yes one of nano feature is drawing basic short cuts on screen yes you can customise Vim todo this. The second one is using control key short cuts instead of the :<letters> enter stuff of vim that does result in reduced key-presses to get stuff done this is another item you could customise with Vim. Third one is nano starting straight in a insert mode and not needing to exit it to do any actions VIM cannot do this.

So called progressive and inclusive open source management continues to take increasingly anti-ergonomic decisions..

If you put the two versions of vim that you can get out of the vim project being the vim-tiny build and the full build head to head with nano on ergonomic measurements for tasks done by people doing administration both of the offered vim lose. Really it a simple measurement count the key-presses to perform the task lower the count in key-presses the better. Ergonomics is a reason why current vim project provided vim versions need to cease to be default editor.

mon87 do the simple one you have to open a file and edited 1 value on one line and save it again. Without customising you vim or nano install just with the out the box experience how few of key strokes can you get that to. Nano will be less.

Nano design comes from the pico editor from the pine email client it was designed for basic editing in 1994 on terminals that had curses and control keys are usable out the box. Yes pico was design that a new student needing write file would have a light learning curve. Why those using the pico email client now Alpine was design for random subject University of Washington new students it pick up on the first day of usage with almost zero training time.

Vim basic interface goes back to vi what is 1976 this was the time of using serial terminals where at times the local serial terminal would respond to control key presses. Vi interface design is showing is age and Vim has not really modernised the out the box. Vim does include a lot of options that user can customise VIm to take advantage of control keys and other things that are usable today but those doing administration don't want to have to customise editor before they use it instead we are after a good out the box experience that is predictable.

Think about it I type nano on any distribution that has nano installed I get basically the same decent experience every single time. I type vi/vim on a distribution I don't get the same experience every single time. Yes your idea of ship a sensible customized version will not fix this problem because its not customised us doing administration want its decent out the box. Administrators have enough customisation of stuff to-do without wasting time customising the editor over and over again. Remember in the age of docker images and vm us Administrators can be dealing with like 20 different distributions in the same day. Dealing with each of the distributions quirks is bad enough without editor issues and that means we are thinking about enough without having to try to remember what key-presses do what in the editor as well.

[royce]

Yes indeed, nano is a pretty reasonable default and newcomers will find it easy to use, what with it displaying the keyboard shortcuts for saving and exiting off the bat. If you know of vim and know how to use you'll know how to change the default editor easily enough.

[foxhound]

IMHO this is bad change. Vi(m) may look like ancient software that is used only by grey bearded admins. It has its drawbacks, as every software, but this is a tool and each tool requires effort to be able to used it efficiently. Moreover this tool is proven in practice since '70. Bash is complex shell for newcomers ... should we replace it with easy and feature-poor cmd.exe equivalent just to make newcomers comfortable? I think not.

You compare vi to nano by keystrokes. Sure, but did you took under consideration that touch-typists don't have to loose focus and typing continuity by not removing hands from letter area of a keyboard? When you have to use arrows/home/end etc you must move hand away. The vi(m) design is unique because of that I would say. Even InelliJ has plugin to use vim mode.

I know that vi(m) came from times when character dumb terminals were made in a way to be as cheap as possible but thanks to that the editor by itself is designed in very efficient way. I would avoid using ed today but vi(m) is worked over to eliminate all its drawbacks. Vi(m) falls into a category of UNIX powertools and part of POSIX, certainly not by coincidence or because some grey bearded old-timer wanted that.

This change will teach those newcomers to use quasi-simple poor tools instead of the real ones. Nano is like animations in Fedora, they looks nice for first hour and then you install Tweaks to turn them off because they become annoying and handicapping.

Yeah sure, powerusers will know how to change back to vi but this is case of standard.

But, lets roll! Default text terminal has many key short cuts which I believe are extremly complex for newcomers and they can hurt themselves with pressing unfortunate key combination. I think FESCo should vote on this as well! More and more they are transforming from Linux to Lindows. I hope those silly changes won't land to CentOS/RHEL!

[skeevy420]

IMHO this is bad change. Vi(m) may look like ancient software that is used only by grey bearded admins. It has its drawbacks, as every software, but this is a tool and each tool requires effort to be able to used it efficiently. Moreover this tool is proven in practice since '70. Bash is complex shell for newcomers ... should we replace it with easy and feature-poor cmd.exe equivalent just to make newcomers comfortable? I think not.

Which is why the first tool in the toolbox should be a simple tool like an Eastwing hammer that everyone can figure out and not a Lincoln 140 Mig Welder.

[oiaohm]

IMHO this is bad change. Vi(m) may look like ancient software that is used only by grey bearded admins. It has its drawbacks, as every software, but this is a tool and each tool requires effort to be able to used it efficiently. Moreover this tool is proven in practice since '70. Bash is complex shell for newcomers ... should we replace it with easy and feature-poor cmd.exe equivalent just to make newcomers comfortable?

Bad compare Bash is not from the 1970s we don't give new users Dash/pure posix shell because its lacking all the nice auto complete stuff. Bash could still be made better with what fish shell has done or maybe navi https://github.com/denisidoro/navi.

You compare vi to nano by keystrokes. Sure, but did you took under consideration that touch-typists don't have to loose focus and typing continuity by not removing hands from letter area of a keyboard? When you have to use arrows/home/end etc you must move hand away.

This is that you have never really learnt to use nano. arrows/home/end... Pine before nano was design for computers that the keyboards did not have arrows keys or ins del home end page up page down or number pad or Fkeys or ESC keys. But the keyboard Pine was design for had a functional control and metakey(alt now) Yes nano keeps all the pine keyboard shortcuts.

Arrow keys in nano/pico
ctrl-B goes back one char or Left arrow
ctrl-F goes forward one char or right arrow
ctrl-P goes up a line or up arrow
ctrl-N goes down a line or down arrow.

Everything with nano/pine can be done without you hands leaving the letter areas of the keyboard by using ctrl or meta key(alt) combinations. One of the big things about nano/pine that is different to vim for typist is that you press 2 keys at the same time. Vim/vi design is not design for pressing 2 keys at once.

Do take note of something that nano/pine hooked up arrow keys, home/end... so they are all use able the original pine design you press a arrow key absolutely nothing would happen because they are not a proper ctrl/meta key pair.

I am a touch typist I know how to use nano properly. The reality is nano less keystrokes less overall hand movement compared to vim when you have a person who is a operator who knows how to use the ctrl and meta(alt) key presses of nano well but getting to this point requires a learning curve.

For users who don't know the keystrokes of nano well yes they will be using the arrow keys the F keys and the home/end etc keys and be having a very light learning curve at the price of more hand movement.

There is a downside to Nano alt key usage when using it in a graphical terminal have something else grab the key pair.

The vi(m) design is unique because of that I would say. Even InelliJ has plugin to use vim mode.

Something to consider here IntelliJ does not force uses to use the Vi(m) design they can opt in or out.

https://plugins.jetbrains.com/plugin/164-ideavim

Yes this plugin you are talking about its not always installed by default.

foxhound nano with pine before it shows that you can reduce the learning curve and improve the skilled users effectiveness without really giving up anything.

Really vim could choose to display a line usage information on screen that advanced users could disable. Could also do what pine did of hooking up arrow keys and key pair presses out box to make learning curve lighter.

There has been a lot of this arguement for a long time we with vim for people who can touch type because we keep hands on the letter section of keyboard when the reality is this is made up garbage when you compare vim to nano/pine. Vim users/developers have been using argument for not implementing other key support out the box to make learning curve as light as possible. Same with excuse used to explain why vim tiny is basically helpless.

I am not saying that vim need to reduce it functionality. I am saying vim developers need to take lesson from early pine moving to more complete keyboard and on screen hinting to lower learning curve point to productivity. First version of pine did not display the keystrokes need to operate pine either.

Making application simpler to learn on fly due to a lighter learning curve the does not mean removing functionality. Instead its making the functionality more naturally displayed and discoverable.

[foxhound]

Bad compare Bash is not from the 1970s we don't give new users Dash/pure posix shell because its lacking all the nice auto complete stuff. Bash could still be made better with what fish shell has done or maybe navi https://github.com/denisidoro/navi.

I didn't write that bash comes from '70s ...

This is that you have never really learnt to use nano. arrows/home/end... Pine before nano was design for computers that the keyboards did not have arrows keys or ins del home end page up page down or number pad or Fkeys or ESC keys. But the keyboard Pine was design for had a functional control and metakey(alt now) Yes nano keeps all the pine keyboard shortcuts.

Arrow keys in nano/pico
ctrl-B goes back one char or Left arrow
ctrl-F goes forward one char or right arrow
ctrl-P goes up a line or up arrow
ctrl-N goes down a line or down arrow.

Everything with nano/pine can be done without you hands leaving the letter areas of the keyboard by using ctrl or meta key(alt) combinations. One of the big things about nano/pine that is different to vim for typist is that you press 2 keys at the same time. Vim/vi design is not design for pressing 2 keys at once.

Do take note of something that nano/pine hooked up arrow keys, home/end... so they are all use able the original pine design you press a arrow key absolutely nothing would happen because they are not a proper ctrl/meta key pair.

I am a touch typist I know how to use nano properly. The reality is nano less keystrokes less overall hand movement compared to vim when you have a person who is a operator who knows how to use the ctrl and meta(alt) key presses of nano well but getting to this point requires a learning curve.

Excuse me but using Ctrl/Meta combination for arrows is like flying from Berlin to Paris by Madrid. Vi(M) here is an obvious winner because without much effort for the cost of only single Esc pressing you can quickly navigate through file with pressing single keys each time instead of using uncomfortable Ctrl/Meta key combinations. Ctrl key location has been switched with CapsLock by IBM and it was extremely stupid ... but was copied by dumb keyboard manufacturers and become a standard. On every machine I have set CapsLock as Ctrl which allows me to use keyboard more effectively.

For users who don't know the keystrokes of nano well yes they will be using the arrow keys the F keys and the home/end etc keys and be having a very light learning curve at the price of more hand movement.

Come on ... arrow keys works in Vi(M) as well. Have you ever use Vi(M) at all?

Something to consider here IntelliJ does not force uses to use the Vi(m) design they can opt in or out.

https://plugins.jetbrains.com/plugin/164-ideavim

Yes this plugin you are talking about its not always installed by default.

Yes, because this is a plugin?

foxhound nano with pine before it shows that you can reduce the learning curve and improve the skilled users effectiveness without really giving up anything.

Really vim could choose to display a line usage information on screen that advanced users could disable. Could also do what pine did of hooking up arrow keys and key pair presses out box to make learning curve lighter.

The main goal of every tool, not only software, is to optimize your work, better productivity by doing things faster, more automated with keeping things uncomplicated which Vi(M) does. Usually the better tool, the more complex usage. You can't sacrifice tool functionalities because it must be ultraeasy to learn ... take an example of Javascript. It is quite easy in learn ... and how bad this cr*p is in production. Nightmare, regular webpage can kill off powerful multicore Intel 12th gen just to display a popup.

There has been a lot of this arguement for a long time we with vim for people who can touch type because we keep hands on the letter section of keyboard when the reality is this is made up garbage when you compare vim to nano/pine.

What garbage are you talking about? Again, have you used Vi(M) for more than 30s? From what you're writing I guess no.

Vim users/developers have been using argument for not implementing other key support out the box to make learning curve as light as possible. Same with excuse used to explain why vim tiny is basically helpless.

I would say that not implementing other key schemas/combinations other that proven one guarantees compatibility on different platforms/systems/versions. I know that I can work fluently not matter on which version or system I will fire up Vi(M). This is one of the killer features of Vi(M).

I am not saying that vim need to reduce it functionality. I am saying vim developers need to take lesson from early pine moving to more complete keyboard and on screen hinting to lower learning curve point to productivity. First version of pine did not display the keystrokes need to operate pine either.

Making application simpler to learn on fly due to a lighter learning curve the does not mean removing functionality. Instead its making the functionality more naturally displayed and discoverable.

You are clearly wrong here. Teaching how to use is a task for books/tutorials/videos not the tool itself. The task of the tool is to allow you to work with it fluently. Does screwdriver tell and show you how to use it every time you are trying to unscrew a bolt? Mine is not. I had to learn how to use a screwdriver on my own before I tried to actually use it ...

[oiaohm]

Excuse me but using Ctrl/Meta combination for arrows is like flying from Berlin to Paris by Madrid. Vi(M) here is an obvious winner because without much effort for the cost of only single Esc pressing you can quickly navigate through file with pressing single keys each time instead of using uncomfortable Ctrl/Meta key combinations. Ctrl key location has been switched with CapsLock by IBM and it was extremely stupid ... but was copied by dumb keyboard manufacturers and become a standard. On every machine I have set CapsLock as Ctrl which allows me to use keyboard more effectively.

Ctrl alt shift are all on the keyboard twice so us touch typist hold Ctrl/alt/shift with one hand and press the added key with the other. Used this way it is totally comfortable.

Pushing ESC for a touch typist equals on most keyboard moving your hands out of location.

I did write typist there for a reason. Keyboards were design to suite ten finger typists to a point.

The main goal of every tool, not only software, is to optimize your work, better productivity by doing things faster, more automated with keeping things uncomplicated which Vi(M) does. Usually the better tool, the more complex usage. You can't sacrifice tool functionalities because it must be ultraeasy to learn ... take an example of Javascript. It is quite easy in learn ... and how bad this cr*p is in production. Nightmare, regular webpage can kill off powerful multicore Intel 12th gen just to display a popup.

We don't exact force hammers for driving in nails even that they exist. Yes those could give better productivity and less human harm.

The logic that you cannot sacrifice tool functionalities to be ultra easy to learn don't hold up in the real world. The default being nano does not prevent person from using vi. Does every user need the function of vi/vim the answer is no.

[foxhound]

Ctrl alt shift are all on the keyboard twice so us touch typist hold Ctrl/alt/shift with one hand and press the added key with the other. Used this way it is totally comfortable.

Nope, on most keyboard layouts right Alt is used only for national characters. That is why it is often labeled as 'AltGr'.

Pushing ESC for a touch typist equals on most keyboard moving your hands out of location.

Nope again. I have small hands and even for me it is not true. The key question in touch typing is to keep your fingers on F and H keys. When you must press Esc you do not remove your finger from F.
Another thing is that you must press Esc once when in your version of the world with Ctrl/Meta combinations you must press the combination EVERY TIME.

The logic that you cannot sacrifice tool functionalities to be ultra easy to learn don't hold up in the real world. The default being nano does not prevent person from using vi. Does every user need the function of vi/vim the answer is no.

And nope again Making super easy and super simple tool as default just for some small number of newcomers and forcing all other users to extra effort of reinstalling packages to be able to work is insane and illogical. It is like: hey lets force everyone to use BASIC by default to write any code when it is super easy and super simple for newcomers when compare it to C, Java or even assembly!
I have to remind you that the change affects many aspects of work in the shell like default editor for git as an example. To change it you must reinstall package to get back to 'normal'.

The default being nano does not prevent person from using vi. Does every user need the function of vi/vim the answer is no.

I could say exactly opposite: the default being vi does not prevent person from using nano