Shift Backspace behaviour

[chrismasters]

If you type:
abd[Shift-Backspace]c
then then resulting string is
abc\bd
(with the \b escape char for backspace)
If you use Backspace instead of Shift-Backspace, then it is fine.
Is this on purpose, and if so, is there a recommended way to sanitise the string when there are escape chars?

[Latency]

There are escape characters in VT100 terms and other consoles similarly. Keep in mind that this project is a port of Readline libs to .NET. Its all under the GPL and it works on a character-by-character basis.

There are variations of console emulators in their behaviors across platforms. Therefore, taking advantage of the built in capabilities of the terminals themself will vary.

I might have some work lying around to illustrate this, but I dont think it is relevant to the project since we are not mapping the terminal portion into this project. That will be left up to whomever to do, if needed, within their project.

However, I do believe it is possible to filter out escape codes prior to displaying the output in this project.

I have about a half of page of code written in ANSI C that I can bring over from another project and drop in to handle VT100 escape seqs, but I will more than likely need to map the ones for windows too which is completely different.

What I recommend that I do is, stub in an additional parameter callback action at the location where needed and curry it through internally. This way you can define your own implementation on how you wish to intercept the input.

Any thoughts or comments, let me know.

-Latency

[Latency]

Added new build found

Tested your issue and unable to reproduce in demo app.

[Latency]

@chrismasters ,

I just rebuilt the project and tested it using the ReadLine.Demo contained within. I am running on Win10 (v1903) and the console app is working as expected.

What platform are you using?

I can not reproduce your problem.

Furthermore, after giving some considerable thought to your question, I looked at seeing about exposing the KeyHandler to the public so that it could be extended within a derived class / interface / or callback of sorts. This seemed to coincide with my thoughts from earlier this morning.

However, after careful consideration, it would not be advantageous to do this and have since restricted visibility for the KeyHandler class within the library now. It would be a feature of the GetText() former section of Read(…) and that is going to be dependent upon the characteristics of the Console.ReadKey(...) method itself; which is a found within the system library we are not responsible for maintaining.

[chrismasters]

@Latency

Thanks for the quick reply. I downloaded the new build and actually still see the problem. To illustrate a little better, I modified the Demo Program.cs

        public static void Main(string[] args)
        {
            Console.WriteLine("ReadLine Library Demo");
            Console.WriteLine("---------------------");
            Console.WriteLine();

            string[] history =
            {
                "ls -a",
                "dotnet run",
                "git init"
            };
            ReadLine.AddHistory(history);

            ReadLine.AutoCompletionHandler = new AutoCompletionHandler();

            var input = ReadLine.Read("(prompt)> ");
            Console.WriteLine("");
            Console.WriteLine(input);

            var bytes = Encoding.ASCII.GetBytes(input);
            Console.WriteLine(string.Join(" ", bytes.Select(x => x.ToString("x2"))));

            input = ReadLine.Read("Enter Password> ", true);
            Console.WriteLine(input);
        }

Output is then

ReadLine Library Demo
---------------------

(prompt)> abc
abc
61 62 64 08 63

So while it visible writes OK with Console.WriteLine, you can see the 08 when the string is converted to hex.

I can process the string myself, but just wondered if this was the behavior intended (I don't know GNU readline well enough to know if this is also the behavior there)

Thanks

Chris

edit - I am on Windows 10.0.17134.345, I also don't have .NET Core 2.2 on my machine so downgraded the project to 2.1 when I tested the latest build

[Latency]

Oh, that seems to clarify things considerably. I did not compare the output binary stream.. so thank you for bringing that to my attention.

Yes, I too detected it to be visibly correct and left it at that.

Let me poke around internal and see what I can find. I will get back to you.

---

As for the targeted framework for the project, … Yes I had removed 2.1. Let me put that back in to help you in the future when pulling updates or cloning a fresh copy of the source while having to avoid changing framework versions. This forces it so you won't have the option to mess with that from the designer anymore.

It is going to be the same version number. The ReadLine.dll itself is not affected. Only the Demo and Tests projects are which are only applicable when you have the source anyway.

Changes are reflective within the latest build and sync'd to the published release now (tagged ).

We will have to get @tonerdo to push the PR to master and update nuget.org accordingly after code review.

[chrismasters]

Thanks again, apologies I forgot to mention the actual string bytes earlier

[Latency]

Okay, wow.. that took me a minute.

I gone ahead and decided to incorporate my idea from this morning while maintaining the efforts I had done from earlier today.

There is now a callback to intercept input from the KeyHandler and curried into the core now.

Latest release

---

RESOLVED

[chrismasters]

OK thanks! So you recommend explicitly providing the callback and handling it this way rather than having it done transparently behind the scenes?

Before this I hadn't ever seen that Shift-Backspace behavior in a terminal before

[Latency]

Well.. yes.. because its platform specific and dependent upon Console.ReadKey().

I haven't tested it on other platforms running NET Core, but you should be able to drop the .exe in Linux and run 'dotnet ReadLine.Demo.exe' to try it.

I would expect it to behave the same, but until its confirmed one would have to map a plethora of key bindings associated.

I tried it with ctrl + home or was it Sft + home and it did some emulating behavior. I dont think it was part of ReadLine library as it appeared to highlight the text in background color starting from idx = 0.

This appeared correct and it didn't give any character associated which means it was handled externally by the system library.

You can test it yourself to confirm.

If there are others to map, I would use the system I designed today. If it's the only one ... it would be easy to add it internally and nop out the callback code.

[Latency]

--- Closed ---