Shall we switch to `emacs` mode as default editing mode ?

[siteshwar]

Currently ksh uses vi as default editing mode. Most of the new users coming from bash will try to execute commands like Ctrl-L (to clear screen) and will get an impression that these bindings are not supported at all. We need to either switch to emacs as default editing mode, or find ways to make it easier for new users to discover emacs mode.

[krader1961]

Currently ksh uses vi as default editing mode.

That isn't true. It bases the default editing mode on the value of the VISUAL env var if set else the EDITOR env var. And if neither are set then it defaults to neither vi, emacs or gmacs mode being enabled. I do think that in that situation it should enable emacs mode.

We need to either switch to emacs as default editing mode, or find ways to make it easier for new users to discover emacs mode.

While I'd prefer to replace the heuristic with a simple default it's probably not worth changing now. But I do think we could improve the documentation. The current wording for the effect of the VISUAL env var on ksh behavior isn't great. It should state clearly that you can force a particular mode at startup by putting set -o emacs, etc. in your ~/.kshrc.

[siteshwar]

Currently ksh uses vi as default editing mode.

That isn't true. It bases the default editing mode on the value of the VISUAL env var if set else the EDITOR env var. And if neither are set then it defaults to neither vi, emacs or gmacs mode being enabled. I do think that in that situation it should enable emacs mode.

Right. I had EDITOR set to vim and that's how it picked up the default editing mode. May be we can print a message when ksh does this.

[krader1961]

Maybe we can print a message when ksh does this.

I've been tempted to add such a message in similar situations. But it is almost always a bad idea unless you can ensure the message only appears once. Where "appears once" is itself something that is often hard to define. I really don't want to see a message telling me the CLI editing mode is what I already expect every time I start an interactive shell. Even if the message was predicated on the absence of an explicit set -o emacs (or vi or gmacs) it would still be more annoying than helpful since I presumably am relying on the heuristic that sets the mode based on the VISUAL or EDITOR env vars.

Ksh is not a friendly shell. Even fish, whose name is an acronym for friendly interactive shell, doesn't display such a message. It simply defaults to emacs behavior. The user has to explicitly ask for vi behavior.

[hlangeveld]

At $WORK, ksh is still the default login shell on linux servers.

All of my younger colleagues switch to bash as the first action after logging in.

When I explain about 'set -o emacs' they look at me as if I'm talking gibberish. And perhaps I am.

My vote is for making emacs mode the default.

On 26/02/2019 05:35, Kurtis Rader wrote:

Maybe we can print a message when |ksh| does this.

I've been tempted to add such a message in similar situations. But it is almost always a bad idea unless you can ensure the message only appears once. Where "appears once" is itself something that is often hard to define. I really don't want to see a message telling me the CLI editing mode is what I already expect every time I start an interactive shell. Even if the message was predicated on the absence of an explicit |set -o emacs| (or vi or gmacs) it would still be more annoying than helpful since I presumably am relying on the heuristic that sets the mode based on the |VISUAL| or |EDITOR| env vars.

Ksh is not a friendly shell. Even fish, whose name is an acronym for friendly interactive shell, doesn't display such a message. It simply defaults to emacs behavior. The user has to explicitly ask for vi behavior.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/att/ast/issues/1180#issuecomment-467291670, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLHkNciac6JgfK9sHiYLdo7APngquZfks5vRLl6gaJpZM4bOpak.

[krader1961]

My vote is for making emacs mode the default.

I'm okay with such a change but it can't be done until we've managed to make a stable release based on the ksh93v- work in progress code. We have made a huge number of changes that might affect the behavior of ksh (e.g., replacing AST vmalloc with system malloc). But we are trying to avoid making any change that explicitly changes user visible behavior until another ksh release based on this code base occurs. When that happens we have some latitude for introducing backward incompatible changes.

[siteshwar]

I'm okay with such a change but it can't be done until we've managed to make a stable release based on the ksh93v- work in progress code.

When it comes to backward compatibility, my concerns are mostly related to retaining compatibility with existing scripts. I don't think there would be any issues with improving interactive features.

[siteshwar]

That isn't true. It bases the default editing mode on the value of the VISUAL env var if set else the EDITOR env var.

I am one of the people who use vim as default editor, but prefer emacs mode on command line. I am curious whether we should continue to use above approach to set default editing mode.

[kdudka]

I've been tempted to add such a message in similar situations. But it is almost always a bad idea unless you can ensure the message only appears once.

For me such a message is fine as long as it describes the action(s) one needs to take to get rid of it.

When it comes to backward compatibility, my concerns are mostly related to retaining compatibility with existing scripts. I don't think there would be any issues with improving interactive features.

I agree. You just need to make it easy for users to get the old behavior back and document it at suitable places (which is the most difficult part).

[dannyweldon]

Maybe we can print a message when ksh does this.

Another problem with doing this is that it could potentially break using rsync with ssh if it prints text because someone has it in their .profile. It should of course only be in their .kshrc.

My vote is for making emacs mode the default.

One of the differences with bash, I believe, is that it defaults to emacs mode even if no mode has been set, in violation of POSIX apparently. Whereas ksh, in that case, starts in a mode with no editing capability at all.

All of my younger colleagues switch to bash as the first action after logging in. When I explain about 'set -o emacs' they look at me as if I'm talking gibberish.

That is strange as emacs mode should have been set by their .kshrc which is copied from /etc/skel/.kshrc and which is properly configured in Red Hat and Debian, unless setting $EDITOR to vim or vi somewhere is changing it.

However if their accounts have been setup before ksh was installed, then they won't have received a copy of the .kshrc in their home dir, which is a good reason to change the behaviour of ksh to default to emacs if no mode has been set, because otherwise users installing ksh to try it out will get a bad experience as they won't get a copy of the default .kshrc.

[krader1961]

When it comes to backward compatibility, my concerns are mostly related to retaining compatibility with existing scripts. I don't think there would be any issues with improving interactive features.

Okay but using the same reasoning there shouldn't be any objection to replacing the implementation of the mail related env vars in the core code with equivalent ksh script functions that are run when an interactive prompt it about to be displayed. See issue #1163.

Also, whether replacing the current heuristic with a constant default is an improvement is debatable. I do agree the heuristic is fragile. The fact you get no default editing mode if the heuristic fails to match your preferred editor is an argument against it. But the heuristic has been in place for several decades and I can't recall ever hearing from another ksh user before now that this behavior surprised them, let alone "I'm going to stop using ksh" because of that behavior.

Also, as @dannyweldon points out printing a message can cause problems. Even if you ignore the issue that displaying the message every time an interactive ksh shell starts is going to annoy people.

[kdudka]

On Thursday, March 7, 2019 8:35:10 AM CET Kurtis Rader wrote:

But the heuristic has been in place for several decades and I can't recall ever hearing from another ksh user before now that this behavior surprised them, let alone "I'm going to stop using ksh" because of that behavior.

I do. When I was studying at the university 15 years ago, ksh was the default shell on some non-Linux servers. When students (mostly Windows users) were given the vi-style line editor, which was the default, they got totally lost.
Instead of figuring out how to switch the editor mode, they quickly learned how to switch to bash, which was also available on those servers.

[krader1961]

were given the vi-style line editor, which was the default, they got totally lost

It's only the default if your VISUAL or EDITOR env vars imply that is your preferred editor mode. So I don't understand what point you are making. Are you saying that those students were given an environment which would have launched a vi style text editing program if an external editor was required and those students were surprised the ksh CLI provided that behavior? Or are you saying the ksh environment set up for those students had an explicit set -o vi in the ksh initialization scripts? In which case what does that have to do with this issue? Since that would be a mistake made by the people responsible for setting up student's computing environments.

[krader1961]

@hlangeveld Please provide more information about why your coworkers switch to bash after you tell them about set -o emacs. Why does the default shell environment provided by your company for new employees cause ksh to default to vi editing mode? Presumably it's because that environment defines the EDITOR or VISUAL env vars in a manner that looks like a vi style editor is what the user expects. If that is the case isn't the solution to either

a) stop defining those default env vars, or

b) change the default to emacs, or

c) explain to the new employee how to set those env vars in their personal shell dot files or add a set -o emacs by default.

[krader1961]

Please understand I am not a fan of the existing heuristic. But so far I haven't seen a good argument for why it should be changed after being in place for 3+ decades. I am also perplexed by statements like

When I explain about 'set -o emacs' they look at me as if I'm talking gibberish.

Note that bash supports both set -o emacs and set -o vi. If your colleagues don't understand something that trivial, but still switch to bash because the ksh CLI editing mode isn't what they expected, I am inclined to suggest they should consider a career that does not involve a computer CLI.

[kdudka]

On Thursday, March 7, 2019 10:27:47 AM CET Kurtis Rader wrote:

were given the vi-style line editor, which was the default, they got totally lost It's only the default if your VISUAL or EDITOR env vars imply that is your preferred editor mode.

Could be. I do not have access to those systems any more. In fact, I am not even sure whether they still exist.

So I don't understand what point you are making.

I am saying that bash was using a different default, which was much better accepted by the target consumers.

Are you saying that those students were given an environment which would have launched a vi style text editing program if an external editor was required and those students were surprised the ksh CLI provided that behavior?

Yes, that was very likely the case.

Or are you saying the ksh environment set up for those students had an explicit set -o vi in the ksh initialization scripts?

I do not think there was much on-site customisation on those servers.

In which case what does that have to do with this issue? Since that would be a mistake made by the people responsible for setting up student's computing environments.

Could be. You just need to be careful in order not to do a similar mistake with the upstream distribution of ksh.