GNU bug report logs - #21609
24.5; Undesirable Cursor Jump After Movement with M-left or M-right in Term-Mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21609 in the body.
You can then email your comments to 21609 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: btdhall <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; Undesirable Cursor Jump After Movement with M-left or M-right in
 Term-Mode
Date: Fri, 02 Oct 2015 20:17:14 -0500

When I reposition the cursor in term-mode or ansi-term with M-left or
M-right, it always returns to its original position (see web link below
for the question on the Emacs StackExchange website which includes an
animation of the issue). These steps reproduce the behavior for me:

emacs -Q
M-x term-mode RET
/bin/bash RET
this is some text               (type some dummy text)
M-left
M-left                          (so that the cursor is in the middle)
M-DEL
this is some                    (this is the resultant text)


http://emacs.stackexchange.com/questions/17085/undesirable-cursor-jump-after-movement-with-m-left-or-m-right-in-term-mode/17086#17086



In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-09-09 on foutrelis
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode easymenu time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 72232 5344)
 (symbols 48 17645 0)
 (miscs 40 37 114)
 (strings 32 9280 3368)
 (string-bytes 1 253533)
 (vectors 16 8989)
 (vector-slots 8 383785 17660)
 (floats 8 63 200)
 (intervals 56 230 0)
 (buffers 960 13)
 (heap 1024 27237 956))

-- 
Bryton T.D. Hall
btdhall <at> gmail.com
(720)789-1140

Message #10 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and executed
 commands can differ
Date: Wed, 23 Nov 2016 19:44:29 +0000

[Message part 1 (text/plain, inline)]

Phil Sainty <psainty <at> orcon.net.nz> schrieb am Mo., 31. Okt. 2016 um
21:46 Uhr:

> On 2016-11-01 03:10, Philipp Stephani wrote:
> > This is dangerous because a different command is executed than the one
> > that is visible in the buffer.
> > Either Emacs should make sure that after C-<backspace> the same command
> > that is displayed is sent to the shell, or it should disable
> > C-<backspace> in char mode altogether.
>
>
> This is a duplicate of bug #21609 -- any command which directly
> modifies the state of the terminal buffer can cause the apparent
> state to be out of sync with the 'actual' state (i.e. the state
> according to the inferior process).
>

Should maybe terminal buffers in char-mode be read-only? The process filter
could then use inhibit-read-only.

[Message part 2 (text/html, inline)]

Message #13 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and executed
 commands can differ
Date: Thu, 24 Nov 2016 09:08:59 +1300

On 24/11/16 08:44, Philipp Stephani wrote:
> Phil Sainty <psainty <at> orcon.net.nz> schrieb am Mo., 31. Okt. 2016 um
>> This is a duplicate of bug #21609 -- any command which directly
>> modifies the state of the terminal buffer can cause the apparent
>> state to be out of sync with the 'actual' state (i.e. the state
>> according to the inferior process).
> 
> Should maybe terminal buffers in char-mode be read-only? The process
> filter could then use inhibit-read-only.

That's an interesting thought, and may be worth investigating (offhand
I've no idea whether it's workable), but note that it's not sufficient
to deal with all cases -- any Emacs command which moves point can create
an inconsistent state without modifying the buffer contents.

Message #16 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and executed
 commands can differ
Date: Wed, 23 Nov 2016 20:21:56 +0000

[Message part 1 (text/plain, inline)]

Phil Sainty <psainty <at> orcon.net.nz> schrieb am Mi., 23. Nov. 2016 um
21:09 Uhr:

> On 24/11/16 08:44, Philipp Stephani wrote:
> > Phil Sainty <psainty <at> orcon.net.nz> schrieb am Mo., 31. Okt. 2016 um
> >> This is a duplicate of bug #21609 -- any command which directly
> >> modifies the state of the terminal buffer can cause the apparent
> >> state to be out of sync with the 'actual' state (i.e. the state
> >> according to the inferior process).
> >
> > Should maybe terminal buffers in char-mode be read-only? The process
> > filter could then use inhibit-read-only.
>
> That's an interesting thought, and may be worth investigating (offhand
> I've no idea whether it's workable), but note that it's not sufficient
> to deal with all cases -- any Emacs command which moves point can create
> an inconsistent state without modifying the buffer contents.
>
>
Hmm, then maybe the entire buffer also needs to be made intangible, except
for the actual position of the terminal cursor?

[Message part 2 (text/html, inline)]

Message #19 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: psainty <at> orcon.net.nz, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and executed
 commands can differ
Date: Sat, 02 Sep 2017 17:14:27 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Wed, 23 Nov 2016 20:21:56 +0000
> Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
> 
> Phil Sainty <psainty <at> orcon.net.nz> schrieb am Mi., 23. Nov. 2016 um 21:09 Uhr:
> 
>  On 24/11/16 08:44, Philipp Stephani wrote:
>  > Phil Sainty <psainty <at> orcon.net.nz> schrieb am Mo., 31. Okt. 2016 um
>  >> This is a duplicate of bug #21609 -- any command which directly
>  >> modifies the state of the terminal buffer can cause the apparent
>  >> state to be out of sync with the 'actual' state (i.e. the state
>  >> according to the inferior process).
>  >
>  > Should maybe terminal buffers in char-mode be read-only? The process
>  > filter could then use inhibit-read-only.
> 
>  That's an interesting thought, and may be worth investigating (offhand
>  I've no idea whether it's workable), but note that it's not sufficient
>  to deal with all cases -- any Emacs command which moves point can create
>  an inconsistent state without modifying the buffer contents.
> 
> Hmm, then maybe the entire buffer also needs to be made intangible, except for the actual position of the
> terminal cursor? 

This bug is currently one of those marked to block the release of
Emacs 26.1.  Given that it existed for quite some time, I tend to
remove the blocking status, but if someone has practical ideas how to
fix this, I think we should do that now.

Thanks.

Message #22 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and executed
 commands can differ
Date: Sun, 3 Sep 2017 14:58:23 +1200

[Message part 1 (text/plain, inline)]

On 03/09/17 02:14, Eli Zaretskii wrote:
> This bug is currently one of those marked to block the release of
> Emacs 26.1.  Given that it existed for quite some time, I tend to
> remove the blocking status, but if someone has practical ideas how
> to fix this, I think we should do that now.

Well here's a starter for discussion.

I've performed only cursory testing, but at first glance this seems
to do the trick, so I'll see what other people think...

Firstly I'm using Philipp Stephani's suggestion that the buffer be
read-only in `term-char-mode' (and removing that in `term-line-mode';
this code doesn't attempt to remember the pre-existing states if
the user had changed it manually).  The default term process filter
`term-emulate-terminal' then binds `buffer-read-only' to nil.

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.


-Phil

[0001-Avoid-creating-inconsistent-buffer-states-in-term-ch.patch (text/x-patch, attachment)]

Message #25 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#21609: bug#24837: 26.0.50; term.el: In char mode, displayed
 and executed commands can differ
Date: Sun, 3 Sep 2017 15:09:28 +1200

On 03/09/17 14:58, Phil Sainty wrote:
> Firstly I'm using Philipp Stephani's suggestion that the buffer be
> read-only in `term-char-mode' [...] The default term process filter
> `term-emulate-terminal' then binds `buffer-read-only' to nil.

In fact Philipp actually suggested binding `inhibit-read-only' in the
process filter, which is presumably preferable.

Message #28 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#21609: bug#24837: 26.0.50; term.el: In char mode, displayed
 and executed commands can differ
Date: Mon, 4 Sep 2017 21:55:57 +1200

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.


-Phil

Message #31 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#24837: bug#21609: bug#24837: 26.0.50; term.el: In char mode,
 displayed and executed commands can differ
Date: Mon, 4 Sep 2017 22:10:45 +1200

On 04/09/17 21:55, Phil Sainty wrote:
> 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
Maybe switching to line mode and temporarily shifting the post-command
hook to pre-command, such that nothing happens post-command for the
mouse events, but afterwards, at pre-command, any keyboard events
first trigger a move to the process mark (at which point we could
shift the behaviour back to post-command again).

(All speculation; I'm not sure if that would actually work.)

Message #34 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>, Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#21609: bug#24837: bug#21609: bug#24837: 26.0.50; term.el: In
 char mode, displayed and executed commands can differ
Date: Mon, 4 Sep 2017 23:59:08 +1200

On 04/09/17 21:55, Phil Sainty wrote:
> We could automatically switch to term-line-mode upon mouse clicks,

Actually, that's probably a non-starter -- if you paste via the mouse
whilst in char mode, it is reasonable (and perhaps necessary) that the
paste will execute in char mode.

However the simpler approach of using the following for both pre-command
and post-command hooks whilst in char mode doesn't seem awful:

  (unless (mouse-event-p last-command-event)
    (term-goto-process-mark))

Mouse events aren't inhibited, but as soon as the keyboard is involved
we jump to where we're supposed to be.

Potentially that's a reasonable compromise.


-Phil

Message #37 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and executed
 commands can differ
Date: Sun, 24 Sep 2017 10:59:13 +0000

[Message part 1 (text/plain, inline)]

Phil Sainty <psainty <at> orcon.net.nz> schrieb am So., 3. Sep. 2017 um
04:58 Uhr:

> On 03/09/17 02:14, Eli Zaretskii wrote:
> > This bug is currently one of those marked to block the release of
> > Emacs 26.1.  Given that it existed for quite some time, I tend to
> > remove the blocking status, but if someone has practical ideas how
> > to fix this, I think we should do that now.
>
> Well here's a starter for discussion.
>
> I've performed only cursory testing, but at first glance this seems
> to do the trick, so I'll see what other people think...
>
> Firstly I'm using Philipp Stephani's suggestion that the buffer be
> read-only in `term-char-mode' (and removing that in `term-line-mode';
> this code doesn't attempt to remember the pre-existing states if
> the user had changed it manually).  The default term process filter
> `term-emulate-terminal' then binds `buffer-read-only' to nil.
>
> 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 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.

[Message part 2 (text/html, inline)]

Message #40 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: 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

[Message part 1 (text/plain, inline)]

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 (text/x-patch, attachment)]

Message #43 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Philipp Stephani <p.stephani2 <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
 bug-gnu-emacs <bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org>
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and
 executed commands can differ
Date: Mon, 25 Sep 2017 16:09:22 +1300

On 2017-09-25 13:48, Phil Sainty wrote:
> 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.

Thinking on this further, it might be even better to use 
pre-command-hook
to establish whether the pre-command position of point is equal to the
process mark, and then act conditionally on that in post-command-hook,
so that if the pre-command point did not already match the process mark,
we do *not* forcibly move it to the process mark afterwards.

The intention being that in term-char-mode:

1. Unless mouse activity takes place, a command cannot leave point in
   an inconsistent position.

2. The user *can* still use the mouse in char mode (e.g. to move point
   and/or select a region).

3. Once the user has used the mouse to move point, they may continue
   to invoke arbitrary commands without it being forced back to the
   process mark (so exchange-point-and-mark would do what they expected,
   for example).  The buffer will still be read-only of course.

4. Upon process output, point would move back to the process mark as
   normal.  When this happens (or if the user manually moves point to
   that position) the user would need to use the mouse once more to
   move point elsewhere.

Obviously they can switch to term-line-mode at any time and do anything
to the buffer, but the above would give some ability to the mouse and
certain keybindings in char mode as well.


-Phil

Message #46 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
 bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and
 executed commands can differ
Date: Fri, 29 Sep 2017 11:37:48 +0300

> Date: Mon, 25 Sep 2017 16:09:22 +1300
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org, bug-gnu-emacs
>  <bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org>
> 
> On 2017-09-25 13:48, Phil Sainty wrote:
> > 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.
> 
> Thinking on this further, it might be even better to use 
> pre-command-hook
> to establish whether the pre-command position of point is equal to the
> process mark, and then act conditionally on that in post-command-hook,
> so that if the pre-command point did not already match the process mark,
> we do *not* forcibly move it to the process mark afterwards.

Do you have a patch along these lines?

Thanks.

Message #49 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
 bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and executed
 commands can differ
Date: Mon, 9 Oct 2017 01:39:41 +1300

[Message part 1 (text/plain, inline)]

On 29/09/17 21:37, Eli Zaretskii wrote:
>> On 2017-09-25 13:48, Phil Sainty wrote:
>> Thinking on this further, it might be even better to use 
>> pre-command-hook
>> to establish whether the pre-command position of point is equal to the
>> process mark, and then act conditionally on that in post-command-hook,
>> so that if the pre-command point did not already match the process mark,
>> we do *not* forcibly move it to the process mark afterwards.
> 
> Do you have a patch along these lines?

I've found a little time to work on this some more.

New patch attached, with the aforementioned changes.

I think the remaining task would be to add user options to disable
the new behaviours, as some users might object to them?


-Phil

[0001-Avoid-creating-inconsistent-buffer-states-in-term-ch.patch (text/x-patch, attachment)]

Message #52 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
 bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and executed
 commands can differ
Date: Tue, 10 Oct 2017 03:04:24 +1300

[Message part 1 (text/plain, inline)]

On 09/10/17 01:39, Phil Sainty wrote:
> I think the remaining task would be to add user options to disable
> the new behaviours, as some users might object to them?

This is now done, and rebased onto the emacs-26 branch.  The new user
options are enabled by default, and a NEWS entry added.  New patch is
attached; please review.


-Phil

[0001-Avoid-creating-inconsistent-buffer-states-in-term-ch.patch (text/x-patch, attachment)]

Message #55 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
 bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
Subject: Re: bug#24837: 26.0.50; term.el: In char mode, displayed and executed
 commands can differ
Date: Mon, 09 Oct 2017 18:32:49 +0300

> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
>  bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
> Date: Tue, 10 Oct 2017 03:04:24 +1300
> 
> This is now done, and rebased onto the emacs-26 branch.  The new user
> options are enabled by default, and a NEWS entry added.  New patch is
> attached; please review.

Thanks, see below.

> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -1148,6 +1148,18 @@ languages.  (Version 2.1.0 or later of Enchant is required.)
>  +++
>  *** Emacs no longer prompts the user before killing Flymake processes on exit.
>  
> +** Term
> +
> ++++

This indication means the change is already described in the manual.
But since the patch doesn't include any doc changes except NEWS, I
presume you decided this shouldn't be mentioned in the manual (and I
agree), so the indication should be "---" instead.

> +*** New user options `term-char-mode-buffer-read-only' and
> +`term-char-mode-point-at-process-mark' are enabled by default to avoid
> +buffer states being created in `term-char-mode' which are inconsistent
> +with the terminal state expected by the inferior process.
> +
> +Respectively, these options prevent buffer changes which are not
> +caused by the process filter, and counter-act movements of point away
> +from the process mark (with the exception of mouse events).

I have a difficulty understanding why the user would like to change
the values of these options from their defaults.  How about revising
this text to describe (a) the default behavior, and (b) when would
someone want to change that by tweaking these options?

> +(defcustom term-char-mode-buffer-read-only t
> +  "If non-nil, only the process filter may modify the buffer in char mode.
> +
> +This makes the buffer read-only in char mode (except for the
> +process filter), to prevent editing commands from causing a
> +buffer state which is inconsistent with the state understood by
> +the inferior process."
> +  :type 'boolean
> +  :group 'term)
> +
> +(defcustom term-char-mode-point-at-process-mark t
> +  "If non-nil, keep point at the process mark in char mode.

Same comment about the doc strings of these options.

Also, please add a :version tag to these options.

Thanks.

Message #58 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
 bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
Subject: Re: bug#21609: bug#24837: 26.0.50; term.el: In char mode, displayed
 and executed commands can differ
Date: Wed, 11 Oct 2017 00:11:17 +1300

On 10/10/17 04:32, Eli Zaretskii wrote:
>> +*** New user options `term-char-mode-buffer-read-only' and
>> +`term-char-mode-point-at-process-mark'

> I have a difficulty understanding why the user would like to change
> the values of these options from their defaults.  How about revising
> this text to describe (a) the default behavior, and (b) when would
> someone want to change that by tweaking these options?

I'm likewise not sure whether users will *actually* want to do this.
I just wanted to make sure that they had the ability to do so, in case
these changes somehow interfered with their workflows (given that these
are notable changes to some long-standing behaviour).

I could 'demote' them to plain defvars, if we think that their use is
so unlikely that they don't actually warrant being included in the
customize group?

In any case I'll see if I can improve the wording...


-Phil

Message #61 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
 bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
Subject: Re: bug#21609: bug#24837: 26.0.50; term.el: In char mode, displayed
 and executed commands can differ
Date: Tue, 10 Oct 2017 15:35:33 +0300

> Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
>  bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Date: Wed, 11 Oct 2017 00:11:17 +1300
> 
> On 10/10/17 04:32, Eli Zaretskii wrote:
> >> +*** New user options `term-char-mode-buffer-read-only' and
> >> +`term-char-mode-point-at-process-mark'
> 
> > I have a difficulty understanding why the user would like to change
> > the values of these options from their defaults.  How about revising
> > this text to describe (a) the default behavior, and (b) when would
> > someone want to change that by tweaking these options?
> 
> I'm likewise not sure whether users will *actually* want to do this.

In that case, the text should say something like

  Customize these options to nil if you want the previous behavior.

> In any case I'll see if I can improve the wording...

Thanks.

Message #64 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
 bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
Subject: Re: bug#24837: bug#21609: bug#24837: 26.0.50; term.el: In char mode,
 displayed and executed commands can differ
Date: Thu, 12 Oct 2017 23:54:42 +1300

[Message part 1 (text/plain, inline)]

On 11/10/17 01:35, Eli Zaretskii wrote:
> In that case, the text should say something like
>   Customize these options to nil if you want the previous behavior.
> 
>> In any case I'll see if I can improve the wording...

I've revised the text for the NEWS entry and both user options.

[0001-Avoid-creating-inconsistent-buffer-states-in-term-ch.patch (text/x-patch, attachment)]

Message #67 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
 bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
Subject: Re: bug#24837: bug#21609: bug#24837: 26.0.50; term.el: In char mode,
 displayed and executed commands can differ
Date: Thu, 12 Oct 2017 15:04:31 +0300

> Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
>  bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Date: Thu, 12 Oct 2017 23:54:42 +1300
> 
> I've revised the text for the NEWS entry and both user options.

Thanks, this is fine with me, but please in the future use the US
English spelling of words such as "behavior".  (No need to send
another patch with that fixed this time.)

I will look into pushing this in a few days, if no objections or
comments surface.

Message #70 received at 21609 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: p.stephani2 <at> gmail.com, bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org,
 24837-done <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org
Subject: Re: bug#24837: bug#21609: bug#24837: 26.0.50; term.el: In char mode,
 displayed and executed commands can differ
Date: Sat, 21 Oct 2017 11:20:57 +0300

> Cc: p.stephani2 <at> gmail.com, 24837 <at> debbugs.gnu.org, 21609 <at> debbugs.gnu.org,
>  bug-gnu-emacs-bounces+psainty=orcon.net.nz <at> gnu.org
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Date: Thu, 12 Oct 2017 23:54:42 +1300
> 
> On 11/10/17 01:35, Eli Zaretskii wrote:
> > In that case, the text should say something like
> >   Customize these options to nil if you want the previous behavior.
> > 
> >> In any case I'll see if I can improve the wording...
> 
> I've revised the text for the NEWS entry and both user options.

Thanks, pushed to the release branch.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.