Multiple locations and breakpoints confusion.

[Pedro Alves]

On 05/02/2018 07:18 PM, Phil Muldoon wrote:
> On 02/05/18 17:48, Joel Brobecker wrote:
>>> But if you ask me, the current output is immediately
>>> understandable.  I'd go for updating the manual.
>>
>> FWIW, that was my thinking also when I first started reading this thread.
>>
> 
> I have no real strong opinions -- my purpose was to make sure the
> functionality of the upcoming multiple locations patchlet for Python
> breakpoints reflected that of GDB. However, seeing (y) in one of
> locations of a multiple location breakpoint, even when the main or
> parent breakpoint is disabled, does display contradictory
> information. I understand the logic of the parent breakpoint
> enablement or disablement overriding that of each location, though,
> but I also can't help but think it is unclear or ambiguous to the
> user when one of the locations says it is enabled when it isn't.
It's only contradictory if you think of it like the final or
output  state, which it is not.  

Think of it like the state of an _input_ switch instead.

Like, if we were talking about a light circuit:

 [mains switch] - [light switch] - [light bulb]
  open/closed      open/closed      on/off

The breakpoint enablement is like the mains switch's state.

The location's enablement is like the light switch's state.

Open any of the switches, and the light turns off.

There's no equivalent for light on/off (the final state).

Thanks,
Pedro Alves