[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21609: bug#24837: 26.0.50; term.el: In char mode, displayed and exec
From: |
Phil Sainty |
Subject: |
bug#21609: bug#24837: 26.0.50; term.el: In char mode, displayed and executed commands can differ |
Date: |
Mon, 25 Sep 2017 13:48:57 +1300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
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
0001-Avoid-creating-inconsistent-buffer-states-in-term-ch.patch
Description: Text Data