Re: [8/9] multiple locations

[Vladimir Prus <ghost at cs dot msu dot su>]

On Wednesday 14 November 2007 22:17:59 you wrote:
>  >...
>  > I think the right approach would be moving the check for loc->shlib_disabled
>  > later, like this:
>  > 
>  >     if (b->loc == NULL)
>  >         ui_out_field_string (uiout, "addr", "<PENDING>");
>  >     else if (header_of_multiple)
>  >         ui_out_field_string (uiout, "addr", "<MULTIPLE>");
>  >     else if (loc->shlib_disabled)
>  >         ui_out_field_string (uiout, "addr", "<PENDING>");
>  >     else
>  >         ui_out_field_core_addr (uiout, "addr", loc->address);
>  > 
>  > But there's also testsuite to be updated and getting somebody to
>  > actually approve this patch.
> 
> OK, but it looks much a smaller/simpler patch than the one you've already
> committed.

Yes, but I have better luck getting huge patches approved, than for 
obvious patches, for whatever reasons.

Basically, it boils down to:
1. Using <PENDING> like above seems a good idea to try.
2. There's a bit of time involved
3. I'm short of time, and probably won't spend it until all the
patches I've sent already are reviewed ;-)

So, if you have the time now to adjust your current patch per my
comments, adjust testsuite and somebody's willing to approve
the patch -- go ahead.

>  > >  > But generally, trying to keeping CLI back compatible have to stop
>  > >  > at some time -- if we keep this "don't break CLI clients even if
>  > >  > CLI clients were deprecated from some time" attitude, it will result
>  > >  > in new features being available via MI only.
>  > > 
>  > > Focussing on the issue at hand, we're just talking about making a minor
>  > > adjustment to the format of "info breakpoints", for the case of pending
>  > > breakpoints, to avoid breaking existing frontend(s).  
>  > 
>  > Not quite. We're trying to please frontend(s) using deprecated protocol.
>  > However little time is spent on that, it's time not spent on other, better
>  > things.  Is there a reason Emacs website cannot say "Use MI support,
>  > available at http://...";?
> 
> The short answer is that, although I have a mode that works with MI, it is
> currently worse than the current one, which uses a mixture of MI and CLI
> commands.  Even if it was as good, there would still be many people already
> using Emacs 22.1 who wouldn't be aware of the website, or willing/able to
> update Emacs from it.

Is there a way to package MI support separately, so that every existing Emacs
user can try it?

> Also MI is still evolving.  It's interesting that you suggest all frontends
> should use it as the changes you have just made for breakpoints with
> multiple locations appear in the output of "info breakpoints" but not
> in that of "-break-list".  So I don't see how any front end could handle
> this information through MI.

Heh, you probably know what's going on here yourself. Even though MI
was advertised as the right interface for frontend for some years, it does
not have a maintainer, or a particular development plan, and misses some bits.
And probably the only way to change the situation is to decide that MI is
the future, and actively discourage use of CLI for anything, to the degree
of immediately refusing any request mentioning CLI in relation to any frontend.

As for multiple breakpoints -- I would have being happy to provide MI
interface, and not provide CLI at all -- but I doubt that would have being
acceptable, and MI has fallen out. Again, a policy that new advanced
functionality is allowed to be available via MI only might have helped.

- Volodya