[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
bug#21609: bug#24837: 26.0.50; term.el: In char mode, displayed and executed commands can differ
Mon, 4 Sep 2017 21:55:57 +1200
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
On 03/09/17 14:58, Phil Sainty wrote:
> Secondly, I've added a local `post-command-hook' function in
> `term-char-mode' which simply moves point back to the local process
> mark position.
> Might such a simple approach be usable? I'm not very familiar with
> the code, so maybe there are glaring holes that I'm not seeing.
I've realised that one such glaring hole is mouse input, as clicking
then tends to create a selection between where you click and (forcibly)
the mark position at (most likely) the end of the buffer.
I'm not sure whether that's a deal breaker, or something which is
essentially incompatible with any solution to the problem and should
perhaps be disabled when in term-char-mode?
Inhibiting mouse events (or similar) sounds a little bit drastic;
however if unimpeded mouse selection is possible, and this allows the
user a way to move point from the process mark, then that just seems
contradictory to what we're trying to achieve in the first place,
which is to keep the state of the buffer (including point) consistent
with what the terminal process believes it to be.
We could automatically switch to term-line-mode upon mouse clicks,
but offhand I don't see how we could switch back automatically
without simply triggering the initial problem, and requiring the
user to manually switch back doesn't seem so user-friendly.