GNU bug report logs - #56110
27+; switching from line-mode to char-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 56110 in the body.
You can then email your comments to 56110 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: "C. Michailidis" <signal3 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27+; switching from line-mode to char-mode
Date: Mon, 20 Jun 2022 10:20:05 -0400

I recently updated a few machines and noticed that term.el in Emacs
version 27+ forcibly submits my pasted commands to the shell sub-process
when switching to char-mode (from line-mode). In prior versions of Emacs
term.el didn't do this; I could further modify the command in char-mode
even if it was pasted from line-mode and submit it myself by pressing
enter.

See also:
https://lists.gnu.org/archive/html/help-gnu-emacs/2022-06/msg00452.html

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: "C. Michailidis" <signal3 <at> gmail.com>
Cc: 56110 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Tue, 21 Jun 2022 13:47:27 +0200

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

"C. Michailidis" <signal3 <at> gmail.com> writes:

> I recently updated a few machines and noticed that term.el in Emacs
> version 27+ forcibly submits my pasted commands to the shell sub-process
> when switching to char-mode (from line-mode). In prior versions of Emacs
> term.el didn't do this; I could further modify the command in char-mode
> even if it was pasted from line-mode and submit it myself by pressing
> enter.

Thanks for the report.

This issue is a side effect of this change:

5653b76d0b * lisp/term.el: Fix minor compilation issues with cl-lib and lexbind
Stefan Monnier <monnier <at> iro.umontreal.ca> 2019-02-24

When I revert the part that changes `term-char-mode':

[0001-WIP-Fix-56110.patch (text/x-diff, inline)]

From 3ebb78f622453623a406d4413cbee421ae57ad84 Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Tue, 21 Jun 2022 13:41:51 +0200
Subject: [PATCH] WIP: Fix 56110

---
 lisp/term.el | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lisp/term.el b/lisp/term.el
index 94bf13e973..eec78707e7 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1463,14 +1463,16 @@ term-char-mode
     (add-hook 'post-command-hook #'term-goto-process-mark-maybe nil t)

     ;; Send existing partial line to inferior (without newline).
-    (let ((pmark (process-mark (get-buffer-process (current-buffer)))))
+    (let ((pmark (process-mark (get-buffer-process (current-buffer))))
+	  (save-input-sender term-input-sender))
       (when (> (point) pmark)
 	(unwind-protect
 	    (progn
-	      (add-function :override term-input-sender #'term-send-string)
+	      (setq term-input-sender
+		    (symbol-function 'term-send-string))
 	      (end-of-line)
 	      (term-send-input))
-	  (remove-function term-input-sender #'term-send-string))))
+	  (setq term-input-sender save-input-sender))))
     (term-update-mode-line)))

 (defun term-line-mode  ()
--
2.30.2

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

the original behavior is restored.

Stefan, how would a fix look like that fits your intention?

TIA,

Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: "C. Michailidis" <signal3 <at> gmail.com>
Cc: 56110 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Tue, 21 Jun 2022 14:20:16 +0200

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

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Stefan, how would a fix look like that fits your intention?

This maybe?

[0001-WIP-Fix-56110.patch (text/x-diff, inline)]

From db062f00cbd4cdf5934237dee3350046a40f0482 Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Tue, 21 Jun 2022 13:41:51 +0200
Subject: [PATCH] WIP: Fix 56110

---
 lisp/term.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/term.el b/lisp/term.el
index 94bf13e973..a8e44b4c34 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1467,10 +1467,10 @@ term-char-mode
       (when (> (point) pmark)
 	(unwind-protect
 	    (progn
-	      (add-function :override term-input-sender #'term-send-string)
+	      (add-function :override (local 'term-input-sender) #'term-send-string)
 	      (end-of-line)
 	      (term-send-input))
-	  (remove-function term-input-sender #'term-send-string))))
+	  (remove-function (local 'term-input-sender) #'term-send-string))))
     (term-update-mode-line)))

 (defun term-line-mode  ()
--
2.30.2

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

[ I first failed to do this correctly because I had tried with
(local term-input-sender) instead of (local 'term-input-sender) - maybe
we can warn about that syntax missing that quote? ]

TIA,

Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: "C. Michailidis" <signal3 <at> gmail.com>
Cc: 56110 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Wed, 22 Jun 2022 19:23:08 +0200

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

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> This maybe?

That works - but I fail to understand why a simple `let' doesn't suffice
(which works as well):

[0001-WIP-Fix-56110.patch (text/x-diff, inline)]

From 24a089360bfb8521b255d583e462dc19cac9179b Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Tue, 21 Jun 2022 13:41:51 +0200
Subject: [PATCH] WIP: Fix 56110

---
 lisp/term.el | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/lisp/term.el b/lisp/term.el
index 94bf13e973..1fde42aa7f 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1465,12 +1465,9 @@ term-char-mode
     ;; Send existing partial line to inferior (without newline).
     (let ((pmark (process-mark (get-buffer-process (current-buffer)))))
       (when (> (point) pmark)
-	(unwind-protect
-	    (progn
-	      (add-function :override term-input-sender #'term-send-string)
-	      (end-of-line)
-	      (term-send-input))
-	  (remove-function term-input-sender #'term-send-string))))
+	(let ((term-input-sender #'term-send-string))
+	  (end-of-line)
+	  (term-send-input))))
     (term-update-mode-line)))

 (defun term-line-mode  ()
--
2.30.2

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

Does anybody know?

TIA,

Michael.

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

From: signal3 <signal3 <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 56110 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Wed, 22 Jun 2022 19:22:28 +0000

On Wed, Jun 22, 2022 at 5:23 PM Michael Heerdegen
<michael_heerdegen <at> web.de> wrote:
>
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
> > This maybe?
>
> That works - but I fail to understand why a simple `let' doesn't suffice
> (which works as well):
>
>
> Does anybody know?
>
> TIA,
>
> Michael.

I don't know. But, whenever I'm making changes I like to keep the
smallest hamming distance possible between revisions. Just a pet peeve
maybe?

So unless there is a reason to avoid using 'let', it seems preferable
to me. That way the snippet better resembles the version prior to 27+.

And in that vein, I'm not sure why the unwind-protect was removed.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: signal3 <signal3 <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 56110 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Thu, 23 Jun 2022 00:14:02 +0300

signal3 [2022-06-22 19:22 +0000] wrote:

> On Wed, Jun 22, 2022 at 5:23 PM Michael Heerdegen
> <michael_heerdegen <at> web.de> wrote:
>>
>> That works - but I fail to understand why a simple `let' doesn't suffice
>> (which works as well):
>>
>> Does anybody know?

FWIW, I also fail to see why let wouldn't be equivalent for most
intensive porpoises, but then I wouldn't trust myself to tell a porpoise
from a dolphin.

> I don't know. But, whenever I'm making changes I like to keep the
> smallest hamming distance possible between revisions. Just a pet peeve
> maybe?
>
> So unless there is a reason to avoid using 'let', it seems preferable
> to me. That way the snippet better resembles the version prior to 27+.

Surely rewriting in terms of let increases Hamming distance? ;)

In any case, my vote is for correct and simpler code over a smaller
diff.

> And in that vein, I'm not sure why the unwind-protect was removed.

AFAICT it's redundant because let always unwinds its temporary bindings,
in contrast with the previous add-function and setq which make permanent
modifications that require manual unwinding.

Thanks,

-- 
Basil

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

From: signal3 <signal3 <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 56110 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Wed, 22 Jun 2022 22:23:49 +0000

On Wed, Jun 22, 2022 at 9:14 PM Basil L. Contovounesios <contovob <at> tcd.ie> wrote:
<snip>
> In any case, my vote is for correct and simpler code over a smaller
> diff.

Lol, correct is definitely better! Smaller diff might be considered if
there's doubt regarding correctness.

> > And in that vein, I'm not sure why the unwind-protect was removed.
>
> AFAICT it's redundant because let always unwinds its temporary bindings,
> in contrast with the previous add-function and setq which make permanent
> modifications that require manual unwinding.

Ah... makes sense to me now, thanks for the clarification..

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Wed, 22 Jun 2022 20:02:55 -0400

>> This maybe?
>
> That works - but I fail to understand why a simple `let' doesn't suffice
> (which works as well):

Depends if you want to have to think about what other code does or not.
If you don't, then `let` is not the same: e.g. if some other code uses
`add/remove-function` on that variable within your `let`, their changes
will be lost when your `let` ends.


        Stefan

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Thu, 23 Jun 2022 18:56:30 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> > That works - but I fail to understand why a simple `let' doesn't suffice
> > (which works as well):
>
> Depends if you want to have to think about what other code does or
> not.

I want.  The initial revision by Richard already looks like

#+begin_src emacs-lisp
(unwind-protect
    (progn
      (setq term-input-sender (symbol-function 'term-send-string))
      (end-of-line)
      (term-send-input))
  (setq term-input-sender save-input-sender))
#+end_src

I checked (using variable watchers) that when I replace
unwind-protect+setq with let, the executed code doesn't leave the scope
of the let.  So why was it written like that?  `term-input-sender' has a
buffer local binding (it already had in the initial revision from 1994)
- but the current buffer is not changed in between.

Did `let' back then not work with buffer-local bindings - or what could
have been the intention to avoid `let'?

> If you don't, then `let` is not the same: e.g. if some other code uses
> `add/remove-function` on that variable within your `let`, their changes
> will be lost when your `let` ends.

Yeah, such things - but I don't think anything like this is crucial
here.


Thanks,

Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Thu, 23 Jun 2022 17:45:55 -0400

> I want.  The initial revision by Richard already looks like
>
> #+begin_src emacs-lisp
> (unwind-protect
>     (progn
>       (setq term-input-sender (symbol-function 'term-send-string))
>       (end-of-line)
>       (term-send-input))
>   (setq term-input-sender save-input-sender))
> #+end_src

I have no idea why it was written that way.  There's been all kinds of
bugs linked to `let` bindings interacting with buffer-local bindings,
but that doesn't seem to explain it either.
It's probably just an accident of history.

>> If you don't, then `let` is not the same: e.g. if some other code uses
>> `add/remove-function` on that variable within your `let`, their changes
>> will be lost when your `let` ends.
> Yeah, such things - but I don't think anything like this is crucial
> here.

So you prefer taking the risk that such a thing happens at some point in
the future, or that someone copies this code without knowing what were
your assumptions?

Personally, I prefer using `add/remove-function` and stop worrying about
those risks.  After all, that's part of the reason why I developed them.


        Stefan

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sat, 25 Jun 2022 14:17:53 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> So you prefer taking the risk that such a thing happens at some point in
> the future, or that someone copies this code without knowing what were
> your assumptions?
>
> Personally, I prefer using `add/remove-function` and stop worrying about
> those risks.  After all, that's part of the reason why I developed them.

I must admit I don't understand.

First: Don't buffer local variables come with the same problem?

Second: When somebody changes a binding using `add/remove-function` with
a scope limited to the scope of my `let', we have no problem.

So let's assume a global scope is wanted.  Then that somebody still has
to figure out what exactly to add-function to, and if the currently seen
value is not the global one, or what the scope of the currently seen
binding is.  Bindings can be local or buffer local.

Then one has to figure out if the binding (variable), or the value is to
be modified.  You yourself got it wrong in this case.  So using
`add/remove-function` is still absolutely nontrivial if I used
`add-function' instead of `let'.

Finally, what about variables that can be bound to functions but also
other types like strings?  You can't use `add-function' on them, right?

TIA,

Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 04:17:26 -0400

> First: Don't buffer local variables come with the same problem?

The problem is somewhat orthogonal to buffer-local vs global, yes.

> Second: When somebody changes a binding using `add/remove-function` with
> a scope limited to the scope of my `let', we have no problem.

Indeed.

> So let's assume a global scope is wanted.  Then that somebody still has
> to figure out what exactly to add-function to, and if the currently seen
> value is not the global one, or what the scope of the currently seen
> binding is.  Bindings can be local or buffer local.

The same holds if they want to use `let` (except that it's a lot more
difficult to let-bind the global value of a variable when there is
a buffer-local value).

> Then one has to figure out if the binding (variable), or the value is to
> be modified.

I don't understand what you mean by that.

> You yourself got it wrong in this case.  So using
> `add/remove-function` is still absolutely nontrivial if I used
> `add-function' instead of `let'.

Yup.  The purpose is not to protect you from your own errors, but to let
you write code whose semantics is more precisely the ones you need such
that the interaction with other code out there will be correct even for
"unexpected" code.

> Finally, what about variables that can be bound to functions but also
> other types like strings?  You can't use `add-function' on them, right?

That's right (well, you still can if the variable currently holds
a function, but it's less convenient in any case).


        Stefan

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 13:24:28 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> > Then one has to figure out if the binding (variable), or the value is to
> > be modified.
>
> I don't understand what you mean by that.

Simply speaking I meant one has to figure out whether one wants to
`add-function' to var or to 'var.

Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 08:23:57 -0400

> Simply speaking I meant one has to figure out whether one wants to
> `add-function' to var or to 'var.

`add-function` expects a "place", like `setf`.


        Stefan

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 15:04:00 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> > Simply speaking I meant one has to figure out whether one wants to
> > `add-function' to var or to 'var.
>
> `add-function` expects a "place", like `setf`.

Thanks, I had an error in my mental model, partly induced by the SYMBOL
without quote vs. (local 'SYMBOL) with quote thing.

Do we want a let-like environment (`let-function'?) that does the same
as `add-function' temporarily?

Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110-done <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 16:49:49 +0200

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

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Personally, I prefer using `add/remove-function` and stop worrying about
> those risks.  After all, that's part of the reason why I developed them.

Ok - I have now installed this fix:

[0001-Fix-Bug-56110-switching-from-line-mode-to-char-mode.patch (text/x-diff, inline)]

From edf6f5d0cae97de10c914c6e94dc5b35f06ec33c Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Tue, 21 Jun 2022 13:41:51 +0200
Subject: [PATCH] Fix Bug#56110 (switching from line-mode to char-mode)

* lisp/term.el (term-char-mode): Make `add-function' override the
correct place (the buffer local variable `term-input-sender').
---
 lisp/term.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/term.el b/lisp/term.el
index 94bf13e973..a8e44b4c34 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1467,10 +1467,10 @@ term-char-mode
       (when (> (point) pmark)
 	(unwind-protect
 	    (progn
-	      (add-function :override term-input-sender #'term-send-string)
+	      (add-function :override (local 'term-input-sender) #'term-send-string)
 	      (end-of-line)
 	      (term-send-input))
-	  (remove-function term-input-sender #'term-send-string))))
+	  (remove-function (local 'term-input-sender) #'term-send-string))))
     (term-update-mode-line)))

 (defun term-line-mode  ()
--
2.30.2

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

Thanks,

Michael.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: 56110 <at> debbugs.gnu.org
Cc: michael_heerdegen <at> web.de, signal3 <at> gmail.com
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 17:08:51 +0200

On Jun 26 2022, Michael Heerdegen wrote:

> diff --git a/lisp/term.el b/lisp/term.el
> index 94bf13e973..a8e44b4c34 100644
> --- a/lisp/term.el
> +++ b/lisp/term.el
> @@ -1467,10 +1467,10 @@ term-char-mode
>        (when (> (point) pmark)
>  	(unwind-protect
>  	    (progn
> -	      (add-function :override term-input-sender #'term-send-string)
> +	      (add-function :override (local 'term-input-sender) #'term-send-string)
>  	      (end-of-line)
>  	      (term-send-input))
> -	  (remove-function term-input-sender #'term-send-string))))
> +	  (remove-function (local 'term-input-sender) #'term-send-string))))
>      (term-update-mode-line)))

Why can't that simply use let?

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: "C. Michailidis" <signal3 <at> gmail.com>, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 11:15:46 -0400

>> > Simply speaking I meant one has to figure out whether one wants to
>> > `add-function' to var or to 'var.
>> `add-function` expects a "place", like `setf`.
> Thanks, I had an error in my mental model, partly induced by the SYMBOL
> without quote vs. (local 'SYMBOL) with quote thing.

Right, that's because for the argument to `local`, we can actually
accept any expression (i.e. an rvalue) as long as it returns a symbol
(just like for `(setf (car EXP) ..)` where can accept an expression EXP
as long as it returns a cons-cell).

I did hesitate to restrict the syntax to (local SYMBOL) because of the
asymmetry it between "SYMBOL" for the global case and "(local 'SYMBOL)"
for the local case, but there is no technical reason to restrict it
this way.

> Do we want a let-like environment (`let-function'?) that does the same
> as `add-function' temporarily?

I'm not sure it's common enough to be worthwhile.  But if we do, then
we'd also want to add something for the `add/remove-hook` version of
the problem.


        Stefan

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: signal3 <at> gmail.com, 56110 <at> debbugs.gnu.org
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 17:30:03 +0200

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> Why can't that simply use let?

I asked the same question in <877d58obnn.fsf <at> web.de> above in this bug's
thread.

Michael.

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

From: signal3 <signal3 <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 56110-done <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 16:01:43 +0000

I may literally die from laughter when someone changes it back! See:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49186
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44087

On Sun, Jun 26, 2022 at 2:49 PM Michael Heerdegen
<michael_heerdegen <at> web.de> wrote:
>
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> > Personally, I prefer using `add/remove-function` and stop worrying about
> > those risks.  After all, that's part of the reason why I developed them.
>
> Ok - I have now installed this fix:
>
>
> Thanks,
>
> Michael.



-- 
Software is written for people to read; the machine's execution of it
is ancillary.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: signal3 <signal3 <at> gmail.com>
Cc: 56110-done <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 20:00:02 +0200

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

signal3 <signal3 <at> gmail.com> writes:

> I may literally die from laughter when someone changes it back! See:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49186
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44087

Oh no - not literally!  Anyway - thanks for this important hint.

Is installing this ok for everyone (Lars?)?  I don't think anyone will
miss the never intended behavior.

[0001-term-char-mode-doc-string-correction.patch (text/x-diff, inline)]

From bf8663415e31abb6b7b96baff2947d9b74b37b1a Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Sun, 26 Jun 2022 19:14:41 +0200
Subject: [PATCH] `term-char-mode' doc string correction

This reverts 16860f6c5f "`term-char-mode' doc string clarification".
Making switching to `term-char-mode' send partially given input
obviously was changed by accident (in 5653b76d0b "Fix minor
compilation issues with cl-lib and lexbind").

See Bug#44087, Bug#49186 and Bug#56110.

* lisp/term.el (term-char-mode): Restore the version of the docstring
describing the originally intended behavior.  Break an overlong line.
---
 lisp/term.el | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/lisp/term.el b/lisp/term.el
index a8e44b4c34..2a7eb72363 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1445,10 +1445,7 @@ term-send-function-key
 (defun term-char-mode ()
   "Switch to char (\"raw\") sub-mode of term mode.
 Each character you type is sent directly to the inferior without
-intervention from Emacs, except for the escape character (usually C-c).
-
-This command will send existing partial lines to the terminal
-process."
+intervention from Emacs, except for the escape character (usually C-c)."
   (interactive)
   ;; FIXME: Emit message? Cfr ilisp-raw-message
   (when (term-in-line-mode)
@@ -1467,7 +1464,8 @@ term-char-mode
       (when (> (point) pmark)
 	(unwind-protect
 	    (progn
-	      (add-function :override (local 'term-input-sender) #'term-send-string)
+	      (add-function :override (local 'term-input-sender)
+                            #'term-send-string)
 	      (end-of-line)
 	      (term-send-input))
 	  (remove-function (local 'term-input-sender) #'term-send-string))))
--
2.30.2

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

TIA,

Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: signal3 <signal3 <at> gmail.com>
Cc: 56110-done <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 20:39:16 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Is installing this ok for everyone (Lars?)?  I don't think anyone will
> miss the never intended behavior.

Lars was faster, he had already updated the docstring.

Michael.

Message #73 received at 56110-done <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: signal3 <signal3 <at> gmail.com>, 56110-done <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 20:40:14 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Is installing this ok for everyone (Lars?)?  I don't think anyone will
> miss the never intended behavior.

[...]

> This reverts 16860f6c5f "`term-char-mode' doc string clarification".

I've already reverted that, though?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #76 received at 56110-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: signal3 <signal3 <at> gmail.com>, 56110-done <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56110: 27+; switching from line-mode to char-mode
Date: Sun, 26 Jun 2022 20:44:15 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> > This reverts 16860f6c5f "`term-char-mode' doc string clarification".
>
> I've already reverted that, though?

Yes.  Meanwhile I have noticed, too :-)

Thanks,

Michael.

Previous Next

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