Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> I'm not sure I understand the logic of this change, so please
>>> elaborate, by showing the form(s) of POSITION for which the current
>>> code doesn't work, and please explain how this patch fixes that.
>> When you click on a part of the mode line which is after the end of
>> mode-line-format, (at least on GNU/Linux) you get an event like this:
>>
>> (down-mouse-1 (#<window 3 on *Bugs*> mode-line (2379 . 2071) 21536370
>>  nil nil (157 . 88) nil (8 . 19) (15 . 32)))
>>
>> posn-string is nil for this but it's still in the mode-line.  My change
>> checks for whether a position is in the mode-line before checking if
>> posn-string is nil, so it catches such events.
>
> I suspect this answer (in one way or another) should find its way either
> into a comment or into the commit message.
> [ I tend to have that impression for most questions that occur during
>   a code review, tho, so maybe it's just me.  ]

I agree, I added it to the commit message.

> I have a more demanding request: any chance we could concoct an ERT test
> for that?  I realize that it might be difficult, but we keep skipping
> such "UI" tests because they're difficult, so I think we should try to
> slowly get closer to having an actual test suite of the UI elements.
> If you can identify one obstacle that makes it currently impossible,
> maybe we can fix that obstacle, and thus make one step in that direction.

A very reasonable request, I think.  How about the test in the attached
patch?  It's not really an end-to-end test, but I think it's still
useful.

In fact, while writing this test, I noticed another bug in this code,
which I've now also fixed.  Good call :)

The test would be improved if we had a nice way to generate click events
from Lisp.  Then I could write some code which does "click on the mode
line" and test that that has the right behavior.  But I have no idea how
to do that, is there even a way?