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

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. 

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. 
       -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).

   (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 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. 

Thanks a lot! 

Jan