GNU bug report logs - #24837
26.0.50; term.el: In char mode, displayed and executed commands can differ

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 24837 in the body.
You can then email your comments to 24837 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: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50;
 term.el: In char mode, displayed and executed commands can differ
Date: Mon, 31 Oct 2016 15:10:28 +0100

emacs -Q
M-x term RET RET
Make sure the terminal is in char mode.
Enter foo-bar C-<backspace> RET

The string "foo-" is now shown in the term buffer, but "foo-bar" has
been sent to the shell.  Typical output is "foo-bar: command not
found".
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.


In GNU Emacs 26.0.50.14 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2016-10-31 built on localhost
Repository revision: 8e7b1af1d708dcf41695cf3fbeff9d35cdb8e5b6
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04 LTS

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

Configured using:
 'configure --with-modules --enable-checking
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''

Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

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

Major mode: Term

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa
derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils term
disp-table easymenu ehelp ring time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded 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 inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 101998 8071)
 (symbols 48 20928 0)
 (miscs 40 339 145)
 (strings 32 19121 4563)
 (string-bytes 1 622106)
 (vectors 16 15237)
 (vector-slots 8 465841 4221)
 (floats 8 185 39)
 (intervals 56 269 0)
 (buffers 976 13)
 (heap 1024 47494 1043))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Diese E-Mail ist vertraulich.  Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen
Sie die E-Mail und alle Anhänge.  Vielen Dank.

This e-mail is confidential.  If you are not the right addressee please do not
forward it, please inform the sender, and please erase this e-mail including
any attachments.  Thanks.

Message #12 received at 24837 <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,
 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: Tue, 01 Nov 2016 09:46:32 +1300

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).

In my own config I use the following, and something along these
lines might form a useful solution? It would be convenient if
there was a symbol property to identify standard commands which
should be disabled, but that may well be excessive/unworkable
in practice.

For killing and yanking text, many cases might be accounted for
by detecting the issue within `kill-region' and `insert-for-yank'
respectively. That isn't comprehensive (at minimum rectangles are
different), but might still be worth considering.


(eval-after-load "term"
  '(progn
     ;; Fix forward/backward word when (term-in-char-mode).
     (define-key term-raw-map (kbd "<C-left>")
       (lambda () (interactive) (term-send-raw-string "\eb")))
     (define-key term-raw-map (kbd "<M-left>")
       (lambda () (interactive) (term-send-raw-string "\eb")))
     (define-key term-raw-map (kbd "<C-right>")
       (lambda () (interactive) (term-send-raw-string "\ef")))
     (define-key term-raw-map (kbd "<M-right>")
       (lambda () (interactive) (term-send-raw-string "\ef")))
     ;; Disable killing and yanking in char mode (term-raw-map).
     (mapc
      (lambda (func)
        (eval `(define-key term-raw-map [remap ,func]
                 (lambda () (interactive) (ding)))))
      '(backward-kill-paragraph
        backward-kill-sentence backward-kill-sexp backward-kill-word
        bookmark-kill-line kill-backward-chars kill-backward-up-list
        kill-forward-chars kill-line kill-paragraph kill-rectangle
        kill-region kill-sentence kill-sexp kill-visual-line
        kill-whole-line kill-word subword-backward-kill subword-kill
        yank yank-pop yank-rectangle))))

Message #17 received at 24837 <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 #20 received at 24837 <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 #23 received at 24837 <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 #26 received at 24837 <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 #29 received at 24837 <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 #32 received at 24837 <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 #35 received at 24837 <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 #38 received at 24837 <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 #41 received at 24837 <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 #44 received at 24837 <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 #47 received at 24837 <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 #50 received at 24837 <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 #53 received at 24837 <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 #56 received at 24837 <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 #59 received at 24837 <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 #62 received at 24837 <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 #65 received at 24837 <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 #68 received at 24837 <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 #71 received at 24837 <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 #74 received at 24837 <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 #79 received at 24837-done <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.