Re: [PATCH v2 0/2] MI: Add new command -complete

On 02/28/2019 10:18 AM, Jan Vrany wrote:
> Hello,
> 
> On Wed, 2019-02-27 at 20:41 +0000, Pedro Alves wrote:
>> I'm totally not against this new command at all, but I have to say that I'd be
>> much more thrilled if someone just spent the time to make separate CLI/MI
>> channels work on Windows too.  The channel doesn't _have_ to be a PTY.
> 
> I know. That was my initial idea just to use named pipes year or two back
> when I started to support Windows. However:
> 
> 1) Completion CLI is AFAIK implemented using readline which has problems 
>    working over pipes. Actually, I never got CLI working satisfactorily
>    on Windows even when I just run GDB "normally" from Windows command shell (`cmd.exe`),
>    let alone over pipes or alike. 

Curious.  AFAIK native Windows gdb over cmd.exe should work fine.

Over pipes or the like, indeed I wouldn't be surprised with issues.
"set interactive-mode on" may help.

BTW, (and I just remembered that after sending the previous email), AFAIK,
Eclipse made the GDB console (with new-ui) work in the Windows port by
using WinPTY.

> 
> 2) Even if it would work, there are still other usecases which working readline
>    and separate CLI/MI channel on Windows would not support. For example:
>    
>    (a) at the moment we use "my" frontend [1], [2] running on developers laptop 
>        connecting over ssh to a GDB that runs on remote RISC-V machine. Essentially,
>        instead of lauching gdb locally (on dev's machine) like: 
> 
>          gdb path/to/binary
> 
>        we do 
> 
>          ssh unleashed gdb -i=mi2 path/to/binary
> 
>        In this case, opening a secondary MI channel is very problematic. 

Why's that problematic?  You could forward a tcp port or a unix domain socket
over shh for MI?  Again, there's no real reason that new-ui only works with
ptys, other than noone ever tweaking the code to support other file types.

>        -complete command gives me at least a way to implement completion which
>        we found very important. There are still some quirks with that, sure, 
>        like when you run `pi` or `shell` commands it completely ruins the MI 
>        channel (this is a bug have not yet looked at let alone fixed but it is 
>        on my very long list).
> 

To me, it seems like you'll never manage to mimic gdb's behavior perfectly.
new-ui gets you perfect behavior, because, well, there's no mimicing.

>    (b) another frontend feature asked was to provide a kind of "workspace" for GDB commands,
>        This is essentially a text editor in which you write ad-hoc commands (possibly
>        with comments) and execute them by selecting portion of a text and pressing a button
>        (or with a shortcut). -complete command would allow me to implement completion
>        in such "workspace" 
> 

I see.

>        (I know, this may sound like a weird UI, but this is essentially what a Smalltalk workspace
>        is but for GDB commands. So far users of this frontend are mainly - me including -  
>        a small bunch of old smalltalkers working on virtual machines)
> 
> [1]: https://bitbucket.org/janvrany/jv-vdb/src/default/
> [2]: https://bitbucket.org/janvrany/jv-libgdbs/src/default/
> [3]: https://bitbucket.org/janvrany/jv-vdb/src/default/doc/Invoking.md
>    
>>
>> On 02/26/2019 07:49 PM, Tom Tromey wrote:
>>>>>>>> "Jan" == Jan Vrany <[email protected]> writes:
>>>
>>> Jan> Are there any other GDB/MI users to comment on this? What would you
>>> Jan> prefer?
>>>
>>> Given the lack of response, I think you should just say which you
>>> prefer.  If you think it would be better the "other" way, go for it.
>>> Or if you'd rather the patches you already have, let me know.
>>
>> Jan, please consider the wildmatching case.  E.g., when debugging GDB itself:
>>
>> (gdb) b push_bac<TAB>
>> Display all 102 possibilities? (y or n)
>> debug_names::offset_vec_tmpl<unsigned int>::push_back_reorder(unsigned long)
>> debug_names::offset_vec_tmpl<unsigned long>::push_back_reorder(unsigned long)
>> std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::push_back(char)
>> ...
>>
>> The frontend needs to complete "b push_bac" -> "b push_back", and present
>> the matches.
>>
>> But the least common denominator is not at the start of the matches
>> strings.  How will a frontend compute the LCD from the matches list alone?
> 
> I see. I was not aware of this behavior, thanks for pointing this out! I'll address that
> in next iterations. 

Another thing that I remembered is that in some cases, GDB's completion actually
replaces the whole complete word, instead of just appending.  For example, try:

  (gdb) handle sigv<TAB>

Results in:

  (gdb) handle SIGVTALRM

ISTR having run into other examples, but not recalling
them right now.

Thanks,
Pedro Alves