Ctrl-B and Ctrl-F produces unexpected results in Emacs mode

[nickpapadonis]

1. Tested in ksh93 and ksh88

2. On prompt type (A)

3. Your cursor is now to the right of )

4. Type <Ctrl-B>

5. Your cursor is now over the A

6. Type , the result should now look like (A)

the cursor is over the right paren.

7. Type <Ctrl-B>

8. This appears on the screen (A^B)

this does not appear correct to have ^B shown

9. Goto step 2, try <Ctrl-A> for step 8, same behavior

There is a video reproducing this at: https://www.youtube.com/watch?v=ojfAgdnwQzw&feature=youtu.be

Notes from KSH mailing list discussion: Kurtis: That behavior is present in the ksh93u+ release and thus is not something introduced since the most recent stable release seven years ago. Note that the unexpected behavior is due to the backslash. Without the char under the cursor being a backslash [ctrl-B] and [ctrl-F] behave as you would expect. This affects pretty much every control char such as [ctrl-A] to move to the start of the line. Whether this behavior is good or bad is debatable. If you feel it should be changed, despite being long standing behavior, please open an issue

The problem isn't the presence of parenthesis; it's the backslash. Type a\[ctrl-B]. This behavior only happens if the most recent character you typed is a backslash. So you can type a()b, then move the cursor inside the parens, type \[ctrl-B] and the same thing will happen. Personally, I think the magic backslash is a misfeature. You can always type [ctrl-V][ctrl-B] to insert a literal [ctrl-B]. Feel free to open an issue. Even better, create a patch for us to review.

On that platform /bin/ksh is 93t+ 2010-03-05 and exhibits the behavior you described. You should be able to run /bin/ksh --version to figure out which ksh variant you're using.

Having said all that I agree with you the behavior is confusing and should be changed regardless of how many years it has been in effect.

[jghub]

FYI, the present repo is no longer under active development. please have a look at #1466 (and the larger part of #1464 referenced from there) regarding the details and background why the ksh2020 line of development has been stopped here (and AFAIK is stalling now and not taken elsewhere). my personal view is that this decision by the ATT team was a good one.

a few people have recently started ksh-community with the aim of maintaining ksh based on the last stable AST/ATT release (ksh93u+). so you might consider to re-open your issue there. take note that this effort is still in its early phase and things will take time.

[nickpapadonis]

Is there another bug system to use?

On Mar 24, 2020, at 5:42 AM, jghub [email protected] wrote:

FYI, the present repo is no longer under active development. please have a look at #1466 https://github.com/att/ast/issues/1466 (and the larger part of #1464 https://github.com/att/ast/issues/1464 referenced from there) regarding the details and background why the ksh2020 line of development has been stopped here (and AFAIK is stalling now and not taken elsewhere). my personal view is that this decision by the ATT team was a good one.

a few people have recently started ksh-community https://github.com/ksh-community with the aim of maintaining ksh based on the last stable AST/ATT release (ksh93u+). so you might consider to re-open your issue there. take note that this effort is still in its early phase and things will take time.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/att/ast/issues/1475#issuecomment-603134350, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD272XSVJIXD776ION5MO5DRJB57ZANCNFSM4LQ7PKAA.

[jghub]

https://github.com/ksh-community/ksh/issues would be the new issue tracker. as said, things might/will take some time to get going (first priority is to make it build again everywhere (including OSX, e.g.) and to do patch integration). but we seriously want to make it a success and a viable new upstream for distros/package maintainers.

[nickpapadonis]

Is there a plan to migrate the bug to the new github system? or should each owner do it individually?

Thanks

On Mar 24, 2020, at 12:01 PM, jghub [email protected] wrote:

https://github.com/ksh-community/ksh/issues https://github.com/ksh-community/ksh/issues would be the new issue tracker. as said, things might/will take some time to get going (first priority is to make it build again everywhere (including OSX, e.g.) and to do patch integration). but we seriously want to make it a success and a viable new upstream for distros/package maintainers.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/att/ast/issues/1475#issuecomment-603329599, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD272XV6W5EHSV65FMG3HWTRJDKOJANCNFSM4LQ7PKAA.

[jghub]

this whole repo including the issue history has been archived to ensure that the issue history is guaranteed to be accessible as reference in the future (but I am sure the ATT/AST team will also take care that this repo/project will remain accessible at least as a github archive.

but there is not plan/intent to import the "old" issues into the new project for the simple reason that ksh2020 was based on ksh93v- and the vast majority (my unofficial estimate but true ;)) of issues/bugs are ksh93v- or ksh2020 specific problems that do not affect ksh93u+ (and there will be other issues which only affect 93u+ I am sure) whereas ksh-community has started from ksh93u+. so if the statement by krader1961 is true that "your" issue is a problem in ksh93u+ I would propose to reopen the issue.