<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
I have tried the new mouse handling with a magic mouse and I'd like it much, much more than the previous behaviour.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
This remind me of another mouse-related problem, intermittent unfortunately, but I think connected with typing/pasting over the current selection: it gets into a crazy state where it thinks the cursor position as one half of a selection and interprets any other
mouse click as the other half. Generally, it goes berserk after this and often there's no alternative to closing the window or even quitting altogether, as sometimes it starts pasting and making an unrecoverable mess of your proof. Maybe this is just part
of the magic of a magic mouse.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg">
<div style="direction: ltr; font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof">
* Mouse event handling is now more robust and more reactive: this is<br>
especially relevant for macOS with Magic Mouse. The mouse reacts on<br>
pressing the button, and does not wait for its release. After jumping<br>
around in the editor, e.g. when following hyperlinks, mouse drag events<br>
are ignored (according to system option "editor_jump_delay", with<br>
default 0.3 seconds): this avoids spurious text selection after editor<br>
navigation.<br>
<br>
<br>
</div>
</div>
</body>
</html>