GNU bug report logs -
#69819
30.0.50; comint-mode does not always respect the read-only flag
Previous Next
To reply to this bug, email your comments to 69819 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69819
; Package
emacs
.
(Fri, 15 Mar 2024 20:09:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dima Kogan <dima <at> secretsauce.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 15 Mar 2024 20:09:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi. Here's a recipe:
1. emacs -Q
2. M-x shell
3. Observe that the shell is live. You can run commands, and the
inferior process responds
4. C-x C-q
Turns on read-only-mode
5. Observe that we now cannot interact with the shell since it's
read-only. We can C-x C-q again to make it work again. Before step 6,
C-x C-q again, to make it read-only
6. C-d
This normally exits the shell. But if we're read-only, it shouldn't
do that. I see that it still works, despite being read-only.
I'm observing this with all comint-based modes, not just shell-mode.
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69819
; Package
emacs
.
(Sat, 16 Mar 2024 07:20:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 69819 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Fri, 15 Mar 2024 13:07:40 -0700
>
> Hi. Here's a recipe:
>
> 1. emacs -Q
>
> 2. M-x shell
>
> 3. Observe that the shell is live. You can run commands, and the
> inferior process responds
>
> 4. C-x C-q
>
> Turns on read-only-mode
>
> 5. Observe that we now cannot interact with the shell since it's
> read-only. We can C-x C-q again to make it work again. Before step 6,
> C-x C-q again, to make it read-only
>
> 6. C-d
>
> This normally exits the shell. But if we're read-only, it shouldn't
> do that. I see that it still works, despite being read-only.
Why do you think C-d shouldn't work when the buffer is read-only?
> I'm observing this with all comint-based modes, not just shell-mode.
It's a feature, AFAICT. But I'm interested in hearing why you thought
it was a bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69819
; Package
emacs
.
(Sun, 17 Mar 2024 20:02:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 69819 <at> debbugs.gnu.org (full text, mbox):
> Why do you think C-d shouldn't work when the buffer is read-only?
>
>> I'm observing this with all comint-based modes, not just shell-mode.
>
> It's a feature, AFAICT. But I'm interested in hearing why you thought
> it was a bug.
Is there no expectation that a "read-only" mode would block any changes
to a buffer? Killing the inferior process breaks that expectation, hence
this report.
That said, I've been a daily user of shell-mode for something like 25
years, and encountered it for the first time just recently, so fixing
this surely isn't very high priority. But still.
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69819
; Package
emacs
.
(Sun, 17 Mar 2024 20:45:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 69819 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 69819 <at> debbugs.gnu.org
> Date: Sun, 17 Mar 2024 12:51:20 -0700
>
> > Why do you think C-d shouldn't work when the buffer is read-only?
> >
> >> I'm observing this with all comint-based modes, not just shell-mode.
> >
> > It's a feature, AFAICT. But I'm interested in hearing why you thought
> > it was a bug.
>
>
> Is there no expectation that a "read-only" mode would block any changes
> to a buffer? Killing the inferior process breaks that expectation, hence
> this report.
What expectation, exactly? The buffer is not changed; the process is
terminated, but that's not the same as changing the process's buffer!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69819
; Package
emacs
.
(Mon, 18 Mar 2024 05:09:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 69819 <at> debbugs.gnu.org (full text, mbox):
> What expectation, exactly? The buffer is not changed; the process is
> terminated, but that's not the same as changing the process's buffer!
The buffer IS changed, actually: when the inferior process dies, it
prints a message into the buffer:
Process shell<1> finished
But that's a red herring I think: if the inferior process died, but the
printing was blocked by the read-only mode, I would still consider that
to be a bug.
My use case is this. I use shell-mode buffers extensively. Periodically
I want to examine the output of some command in a *shell* buffer:
compare it against other data, look at it, cut/paste it, whatever. While
I'm doing that I don't want to accidentally change anything, so I C-x
C-q. Then accidental keystrokes don't end up changing anything. UNLESS
that accidental keystroke is C-d (and probably a few others I haven't
hit by mistake yet). This use case and expectation seems reasonable to
me.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#69819
; Package
emacs
.
(Mon, 18 Mar 2024 13:18:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 69819 <at> debbugs.gnu.org (full text, mbox):
> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 69819 <at> debbugs.gnu.org
> Date: Sun, 17 Mar 2024 21:57:26 -0700
>
> > What expectation, exactly? The buffer is not changed; the process is
> > terminated, but that's not the same as changing the process's buffer!
>
> The buffer IS changed, actually: when the inferior process dies, it
> prints a message into the buffer:
>
> Process shell<1> finished
Not relevant: this comes from the process sentinel, which is invoked
when the process exits. By that time, the buffer is no long a shell
buffer, and the process finished notification is shown to announce the
end of the session.
> My use case is this. I use shell-mode buffers extensively. Periodically
> I want to examine the output of some command in a *shell* buffer:
> compare it against other data, look at it, cut/paste it, whatever. While
> I'm doing that I don't want to accidentally change anything, so I C-x
> C-q. Then accidental keystrokes don't end up changing anything. UNLESS
> that accidental keystroke is C-d (and probably a few others I haven't
> hit by mistake yet). This use case and expectation seems reasonable to
> me.
I don't agree that it is reasonable. C-d is a key that is bound to a
certain function, not unlike C-f or C-v. You wouldn't expect C-f or
C-v not do their job when a buffer is read-only, would you? Then why
expect that from C-d?
As for your use case: I understand now where you are coming from, but
I think that what you want is a missing feature; that it just happens
to work with 99% of your keystrokes is sheer luck. What you want is a
feature whereby input to the shell is blocked until explicitly
unblocked by the user, in which case C-d would be blocked as well. I
don't think we have such a feature, so I propose to add it.
This bug report was last modified 360 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.