Stuck in Insert Mode

[GordonDelgado]

When pressing Insert, the default behavior for powershell command window (without PSReadLine) is to toggle between insert and overstrike modes.
With PSReadLine, the window is "stuck" in insert mode. Nothing I do will fix this except unloading PSReadLine.

As this forces the user to hit two keys (key, delete) for every character it's quite counter-productive.
The original behavior should be maintained.

This still repros with the latest 2.0.0 version of PSReadLine on Windows.

[lzybkr]

I've long been waiting for someone to notice and report this. Yeah, overstrike mode isn't implemented.

[lzybkr]

As hinted to in PowerShell/PowerShell#8066, the initial setting should be retrieved via GetConsoleMode, checking the flag ENABLE_INSERT_MODE.

[JoeSalmeri]

@GordonDelgado @lzybkr

FWIW, I have reported this in the Windows 10 support forums since PSReadLine was originally introduced and basically had zero response to the issue, that's why I figured I'd try on the PS support forums.

@lzybkr I reported PowerShell/PowerShell#8066, however, just an additional clarification on that. While you might be able to use GetConsoleMode to check the ENABLE_INSERT_MODE flag it does not matter whether that option is checked or unchecked since PSReadLine does not have support for overtype mode now.

This is a major annoyance as to how such basic functionality was excluded. Originally I thought it was an oversight but the fact that years have past and nothing has been done about it leads me to believe it was on purpose.

Makes me think it is somehow related to the bring the phone world to our PCs mindset similar to how on your Phone you have a backspace key but no delete key (on standard keyboards) despite the fact that those keys perform very different commands.

The lack of insert/overtype toggle is most annoying when recalling a command to modify it.

Here's hoping that this issue gets the needed attention to get it fixed.

[lzybkr]

@JoeSalmeri - yeah, not an oversight, just hasn't been a priority for me with very little demand and this is purely an unpaid spare-time project for me.

I just noted the how of your request to honor the console default setting because that would have been easy to overlook and I wasn't sure if it was easy, but it seems like it would be, so I just wanted to capture that.

Do note that this is open source, and if it's important to you, maybe you can contribute a fix.

[JoeSalmeri]

@lzybkr

I appreciate your reply.

I am not a C# developer although I have developed in many languages over the years.

If I understood your reply correctly you think that it would be easy to honor the default console setting (meaning whether checked or unchecked).

It would seem to me that if you are able to "honor" the console setting that would mean that PSReadLine would be able to do insert or overtype mode it would just depend on which setting the console was configured for.

If that is what you mean, that seems like it would be 99% of the battle as it would then be a simple toggle switch in the code to switch between the two modes.

So you developed this as a spare-time project and then MS decided to include it in PowerShell?

Since it is also included in Windows PowerShell and loaded by default one would think that MSFT would also be interested in the loss of functionality....

Certainly PS-Readline is a great module it just really bothers me that this basic feature is missing.
It is much more natural (IMHO) to be in overtype mode normally and press DEL than it is to be in insert mode normally and press backspace to delete characters.

Here's hoping that somebody gives you the time to address this.

In an unrelated issue, I noticed a different behavior with PS Core 6.1 which also is occurring with the latest Windows PS. Both are using PS-Readline 2.0 so I assume that's why.

Here's the issue.

Type a command (does not matter what) "dir abc" and then hit enter
Now press the UP arrow to recall the command
When you pressed enter the cursor would have been after the "c" in abc
When you recall the command it is now on the "d" in dir (at the start)

This is annoying as it is quite common to type a command, run it and then recall to add to it
It is one of those things where you do it without thinking, up arrow and then start typing.

Now with the cursor at the start of the command, you are inserting into the front of the command.
When I first installed PSC 6.1 I though I was making a typing mistaken but now realize what is occurring.

If you go back to cmd.exe you will see that it took works like PS used to.

Hopefully than gets fixed. Let me know if you want a new issue created.

[JoeSalmeri]

@lzybkr

Regarding my previous comment about the cursor location when you press the up arrow.

I just found a SamplePSReadLineProfile.ps1 file which you include in the installation of PSReadline.

In there you mention a "Set-PSReadLineOption -HistorySearchCursorMovesToEnd" which addresses my cursor location issue above, however, it also appears that I uncovered a bug.

In that sample file you have a note which says:

"The option "moves to end" is useful if you want the cursor at the end
of the line while cycling through history like it does w/o searching,"

I have used the UpArrow and DownArrow handlers in my profile for years, however, my profile had the following note:

#   This controls the cursor location while searching (leave or move to end)
#   It defaults to not moving to end but it does not appear to work and always
#   moves it to the end (which is what I want anyway).  It does highlight
#   the original part typed so it is easy to see even with the cursor at the
#   end:
#
#       Set-PSReadLineOption -HistorySearchCursorMovesToEnd
#

Seems that option was broke in the past.

In PSC 6.1, I did the following test.
Open up window 1 with my profile loaded
Open up window 2 with -noprofile -noexit

In both windows I type "dir *" and hit enter and the press the up arrow.
Based on your comment that the cursor moves to the end when you press up arrow w/o searching I would expect both of windows to have the cursor at the end since I am not searching.

Instead window 1 (my profile which does not specify that option) has the cursor at the start, whereas window 2 (no profile) has the cursor at the end. Based on your description both should have been at the end.

In the sample the comment goes on to say

"without that option, the cursor will remain at the position it was when you used up arrow, which can be useful if you forget the exact string you started the search on.

Repeating the test above, however, after typing "dir *" move the cursor back to the "r" in "dir" and then hit enter.

Next type "di" and then hit the UpArrow

Based on that comment I expect the cursor to be on the "r" in dir after pressing the uparrow (w/o searching).

Window 1 (my profile without the option) has the cursor correctly positioned on the "r'" in the recalled "dir *" command, wherease windows 2 has the cursor at the end.

If I issue the following in window 1 (my profile)

Set-PSReadLineOption -HistorySearchCursorMovesToEnd

Now I get the cursor the end when UpArrow is pressed w/o searching, however, when UpArrow is pressed w/search (di then hit enter) the cursor is also at the end.

Based on the docs if I did NOT use "moves to end" and
Press UpArrow w/o search (the cursor should be at the end - my desired behavior) and
Press UpArrow w/search (the cursor keep its location - my desired behavior)

So the issue is that not using "moves to end" should still move it to the end when not searching but it leaves it puts it at the start instead.

With this bug, I am stuck and would have to choose which functionality I want to live without.

I know that was a lot but hopefully it makes sense.

Does that make sense?

[JoeSalmeri]

@lzybkr

Based on our discussion and the documentation it appears that the default functionality for PSReadLine when using the HistorySearch functions is also my desired functionality, however, it is not working that way do to a bug in the behavior when no search is specified and there is no option which provides the default behavior that I desire. This was introduced when I moved from PowerShell Core 6.0.4 to PowerShell Core 6.1.0.

Here's is a summary of my testing and the results which should make it easier to read than my previous comment. I have also included the Actual Behavior when PSReadLine is not configured to use the HistorySearch functions so that all scenarios are documented in one place. Note that I tested on PS Core 6.1.0 as well as Windows PowerShell 5.1.17763.1 (09/2018 Windows 10 release).

Desired behavior (when using HistorySearch functions)

Search NOT specified        Cursor goes to end   of command line
Search specified            Cursor goes to end   of search string

Actual Behavior (when NOT using HistorySearch functions)

Search NOT specified        Cursor goes to end   of command line
Search specified            Cursor goes to end   of command line

Actual Behavior (when using HistorySearch functions)

Set-PSReadLineOption -HistorySearchCursorMovesToEnd:$False

    Search NOT specified    Cursor goes to start of command line (BUG: Should be end of cmdline)
    Search specified        Cursor goes to end   of search string

Set-PSReadLineOption -HistorySearchCursorMovesToEnd:$True

    Search NOT specified    Cursor goes to end   of command line
    Search specified        Cursor goes to end   of command line

Test SetUp

cmd.exe to start pwsh       -NoProfile
cmd.exe to start powershell -NoProfile

Test Flow and commands (done in both Test SetUps)

if testing HistorySearch
    Set-PSReadLineKeyHandler -Key UpArrow   -Function HistorySearchBackward
    Set-PSReadLineKeyHandler -Key DownArrow -Function HistorySearchForward

if testing HistorySearchCursorMovesToEnd
    Set-PSReadLineOption -HistorySearchCursorMovesToEnd:$True
else
    Set-PSReadLineOption -HistorySearchCursorMovesToEnd:$False

dir *
Enter
Press UpArrow
Note cursor location

di
Press UpArrow
Note cursor location

Hope that simplifies the description of the bug introduced and that we can get it fixed soon.

Thanks for your help!

[axbender]

Has there ever been a progress in seven(!) years.
This is really some basic functionality that is missing here.
It's not a problem in Linux (with readline...), in Windows's Cmd, and in PowerShell w/o PSReadline.

[JoeSalmeri]

Hi axbender,

Has there ever been a progress in seven(!) years. This is really some basic functionality that is missing here. It's not a
problem in Linux (with readline...), in Windows's Cmd, and in PowerShell w/o PSReadline.

The insert vs overtype issue is because the PSReadLine module is loaded by default.

If you unload it then insert/overtype works, BUT, then you lose all the features that PSReadLine provides.

PS is a great product and I am very happy that they made it open source and cross platform but there seems to be a pattern where basic functionality is missing or broken and there is no desire to fix it.

I submitted a bug about Copy-Item many, many years ago about how it was basically almost unusable for all but the most basic situations. You would think that file copy would be rock solid. Originally I was told it would be addressed in a new FileSystem 2 provider but then that was cancelled and when I pressed the issue the PS "committee" deemed it was not something they would pursue.

So when I find basic functionality in ps either missing or broken I no longer have any hope that it will ever be addressed.

[axbender]

@JoeSalmeri
Thx for your response.

Hm, this is quite unfortunate; not being able to toggle INS mode is one (ugly - but not critical) thing, but an unresolved bug in Copy-Item is quite another. This really make me think (again) that MS's commitment to Powershell (Open Source) is not really what it's supposed to be (don't believe that a bug e.g. in bash (although cp is not bash...) would stand for such a long time w/o being resolved.

Nonetheless, it's good to know that you're aware of these bugs...

[JoeSalmeri]

@axbender,

I don't know if you looked at the bug report or not but I detailed a bunch of basic use cases and compared the results to other copy programs.

The most ridiculous argument for not fixing was that they said they didn't want to break code that depended on the broken behavior.

To which I responded, who would depending on something that cannot produce the same results when rerun?

Isn't that one of the main reasons we write code in the first place?

I think the real reason is that the FileSystem provider code is so complicated that no one wants to touch it.

You are right though, in the Linux world if this kind of bug existed it would certainly not have been left unresolved for this long, much less deemed won't fix.