Extra space after sdb prompt

[lf-]

Hi! There's a usability issue I'm having that's making it rather impossible to use sdb: the cursor has a bunch of spaces between it and the (sdb) prompt. This is a critical problem because if I arrow up, the space is not added and the characters displayed don't match up with the ones I'm editing.

Here is a screenshot of the misbehaviour, from konsole (though it's also shown up in alacritty):

I just built this sdb from the master branch today, 7a408a09894b6cf0e2c3b3535ee7de90e9434274. I'm running this mono version on Arch Linux:

dev/sdb - [master] » mono --version
Mono JIT compiler version 6.12.0 (makepkg/a22ed3f094e Tue Dec 22 06:01:50 PM -03 2020)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug 
        Interpreter:   yes
        LLVM:          supported, not enabled.
        Suspend:       hybrid
        GC:            sgen (concurrent by default)

[alexrp]

Do you have libedit.so.2 installed?

[lf-]

@alexrp I appear to have libedit.so.0 via the Arch package libedit, version 20191231_3.1-3

[alexrp]

I'm not sure why the soname is different on Arch, but you can edit sdb.exe.config to look like this:

<configuration>
    <dllmap dll="libedit" target="libedit.so.0" os="!windows" />
    <dllmap dll="libedit" target="libedit.dylib" os="osx" />
</configuration>

This should hopefully make SDB pick up libedit and use that instead of Mono.Terminal.LineEditor which isn't as robust.

[lf-]

Thanks! This fixes the usability issue although another issue presents itself:

It seems like some terminal control codes are getting eaten. It seems to be resolved for the next line by hitting C-c.

[alexrp]

I'm not able to reproduce that under WSL in any of the terminal emulators I have here (conhost, wt, mintty). I don't have a native Linux system available at the moment; could you try some different terminal emulators?

[lf-]

I'm observing it in alacritty inside of a neovim, as well as a Linux console session.

Is there some way I can take a reproducible recording of it? I've done a script (binary file) here, if that's useful: https://gist.github.com/4d956ebe234a3a9a25161e4ecf3370f2

[alexrp]

There is one thing that's interesting in that output, which is that we print the attribute reset sequence even if we didn't output an attribute sequence earlier. So we do a pointless reset on empty lines or lines containing 'neutral' text, for example.

I doubt that's what's causing this issue, but you could try changing this line:

https://github.com/mono/sdb/blob/7a408a09894b6cf0e2c3b3535ee7de90e9434274/src/Log.cs#L42

To something like:

var str = color + (args.Length == 0 ? format : string.Format(format, args)) + (color.Length != 0 ? Color.Reset : string.Empty);

Other than that, it might be worth checking if libedit.so.0 on Arch is even the same library as libedit.so.2 on other distros, or just a library with a compatible API but less robust implementation. (libedit.so.2 is itself a mostly API-compatible drop-in replacement for libreadline.so.8.)

Another thing you can try is to just use libreadline:

<configuration>
    <dllmap dll="libedit" target="libreadline.so.8" os="!windows" />
    <dllmap dll="libedit" target="libedit.dylib" os="osx" />
</configuration>

(SDB doesn't do this out of the box due to license incompatibility. But I see no reason why you doing so for your local machine would be a problem legally.)

If all of this fails, then I think I can only chalk it up to something in your shell environment...

[lf-]

libreadline appears to work perfectly. I tried that source change but it didn't seem to have any effect. I've looked at what Debian is shipping in their libedit and it seems to be the same source as the Arch one, just with a different soname.

Thank you so much for lending your time in looking into this. I really appreciate it.