bug#36779: 25.1; mouse click not recognized for frames with large left position

[martin rudalics <rudalics@gmx.at>]

 >>    . We generally avoid naming proprietary products, and instead say
 >>      something like "some proprietary X servers".
 >
 > I gave the (link to) details of the X server (while avoiding to write
 > the product name, though the address includes it, which in fact may be
 > useful when searching the file for the former as long as the case is
 > ignored) since I was asked to do so.  The description "some
 > proprietary X servers" is not factual since (at least) I am not aware
 > of any other X server that exhibits the problem.  I had considered
 > "some proprietary X server" of course but that does not seem to give
 > useful information (if we keep the description vague, what is the
 > purpose of the file?).

I agree with Eijiro and consider his description quite tactful in this
regard.

 >>    . The part that this problem is only known to happen with Emacs
 >>      doesn't seem important (this is, after all, a file that deals
 >>      solely with Emacs-related problems), and I'd omit it.
 >
 > That part is important since, while the manufacturer says the problem
 > is due to a limitation of the X server, it seems to happen only to
 > Emacs, which greatly confused me and is crucial information for
 > possible users in the same situation.

This part could be omitted if we left in the reference to the bug
report.

 >    . I'd prefer not to send the reader to read the bug discussion, and
 >>      instead would tell here the important parts of what was said there
 >>      that clarify the issue (if there are such details there).
 >
 > I linked to this discussion since the "details" are too complex to be
 > summarized in "a few lines" (as I was instructed).  Personally, I wish
 > if other entries in the file also included links to more detailed
 > discussions!

Since I often miss such links too I strongly agree with Eijiro.

 >>    . We usually try to describe some workarounds -- do they exist in
 >>      this case?
 >
 > The workaround is to avoid changing the monitor configuration after
 > the X server has started (or, equivalently, restart the X server every
 > time after such a change), which I believe is already clear from my
 > description.

Still that workaround should be explicitly mentioned.

martin