On 24/09/17 23:59, Philipp Stephani wrote:
> I haven't checked the code in detail, but it seems to be reasonable.
> Since nobody complained in weeks, maybe just push it to the release
> branch and see whether it breaks anything.

Before we do that, here's a revised patch based on my own follow-ups
to my initial patch.  Changes to that version are as follows:


I've switched the `buffer-read-only' let-binding to `inhibit-read-only',
as you had originally suggested.


It looks like programatically calling `read-only-mode' was incorrect
on my part, so I'm now setting `buffer-read-only' instead.  I've added
a `read-only-mode-hook' function to track when the user toggles the
read-only state, however, so that if the user happens to enable
`read-only-mode' in line mode, toggling to and from char mode will not
revert their selected read-only state.


Lastly I'm trying to avoid messing with mouse selection in char mode,
by *not* moving point back to the process mark if the last command
input event was a mouse event.

So keyboard events cannot leave point in the wrong position; and while
mouse events can do so, as soon as the keyboard is involved again we
jump to where we're supposed to be.

This still happens in post-command-hook only.

Question: Is there a reason to additionally do this in pre-command-hook?
I initially thought I'd need to do so, due to it now being possible for
a (mouse) command to leave point in the wrong position; however I think
it's probably still fine to limit this to post-command-hook?

IIRC the main danger of leaving point in the wrong position is mitigated
by the buffer being read-only, which ensures that the user cannot make
inconsistent changes to the buffer state in char mode; and I'm assuming
that inferior process output is guaranteed to happen at the process mark.

(The user could invoke a command which uses inhibit-read-only to
update the buffer, but that's going to introduce inconsistencies no
matter where point is at the time, so I think that's out of scope.)

The user might also wish to invoke a keyboard command that acts upon
the mouse-selected region, so limiting ourselves to post-command-hook
means we won't interfere with such a command.

New patch is attached.


-Phil