GNU bug report logs -
#32883
26.1; Emacs not response in shell mode
Previous Next
Reported by: "alexei28" <alexei28 <at> gmail.com>
Date: Sun, 30 Sep 2018 07:48:01 UTC
Severity: normal
Found in version 26.1
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32883 in the body.
You can then email your comments to 32883 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 07:48:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"alexei28" <alexei28 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 30 Sep 2018 07:48:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
Windows 10 (64 bit), Emacs 26.1
1. I download Emacs 26 from here :
http://ftp.gnu.org/gnu/emacs/windows/emacs-26/emacs-26.1-x86_64.zip
2. Unpack and run pure Emacs (no external packages)
3. Connect android device to my computer
4. M-x shell
5. Run the next command adb logcat -vtime. Tool logcat- is a tool
from Google to see android's device logging. It's very helpful.
6. This tool (logcat) generate many text interactively in shell.
7. So I press button arrow up and move cursor to the center of
screen.
8. Text is continues to be generated.
9. And now I press button Enter
10. As result Emacs not response any more. Show progress bar
forever. Nothing help. Only kill Emacs process from Task Manager
Why this is happened? is this a bug of Emacs?
Thanks.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 09:15:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 32883 <at> debbugs.gnu.org (full text, mbox):
> From: "alexei28" <alexei28 <at> gmail.com>
> Date: Sun, 30 Sep 2018 10:47:27 +0300
>
> 1. I download Emacs 26 from here :
> http://ftp.gnu.org/gnu/emacs/windows/emacs-26/emacs-26.1-x86_64.zip
>
> 2. Unpack and run pure Emacs (no external packages)
>
> 3. Connect android device to my computer
>
> 4. M-x shell
>
> 5. Run the next command adb logcat -vtime. Tool logcat- is a tool from Google to see android's device
> logging. It's very helpful.
>
> 6. This tool (logcat) generate many text interactively in shell.
>
> 7. So I press button arrow up and move cursor to the center of screen.
>
> 8. Text is continues to be generated.
>
> 9. And now I press button Enter
>
> 10. As result Emacs not response any more. Show progress bar forever. Nothing help. Only kill Emacs
> process from Task Manager
How long did you wait? Is it possible that it just takes a lot of
time for Emacs to display this text?
Did you try C-g several times? Did that help?
Does it help to set w32-pipe-read-delay to zero?
If none of the above helps, can you save the output of "logcat -vtime"
in a file and post that file here? Does visiting that file exhibit
similar problems, i.e. a long (or infinite) time needed for its
display?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 11:24:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 32883 <at> debbugs.gnu.org (full text, mbox):
[Please keep the bug address on the CC list.]
> From: "alexei28" <alexei28 <at> gmail.com>
> Date: Sun, 30 Sep 2018 12:41:15 +0300
>
> " How long did you wait? " - forever.
Please tell the approximate time. I understand it was a long time,
but hardly "forever".
> " Did you try C-g several times? " - yes, but it not help.
> " (setq w32-pipe-read-delay 0)" - not help
OK.
> "can you save the output of "logcat -vtime"" - it does not make sense
> because "logcat" generate unique text. You can do it yourself.
> Here steps:
> 1. Connect any android device to your comuter
> 2. Enable USB-debugging
You assume I have an Android device to do that, and that I'd agree to
enable USB debugging on such a device. But those assumptions are not
necessarily true.
I asked whether saving the text to a file and visiting that file on
your system also locks up Emacs. Did you try that? If that doesn't
lock up Emacs, posting the file won't help. Otherwise, please do post
such a file, I'd like to look at the actual text Emacs needed to deal
with in your case.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 12:07:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 32883 <at> debbugs.gnu.org (full text, mbox):
> From: "alexei28" <alexei28 <at> gmail.com>
> Date: Sun, 30 Sep 2018 14:46:39 +0300
>
> [Please keep the bug address on the CC list.]
You didn't, please do in the future. It is important for this
discussion to be recorded by the bug tracker.
> Оne hour passed, but Emacs is not response. Show progress.
> 'C-g' sometime help to unlock. But sometime not.
OK.
> OK. Not mandatory to start "adb logcat -vtime". You can start any process
> that generate text in standard output.
Then I cannot reproduce the problem on my system. On my system, while
the process runs and generates the text, I can switch to another
buffer and invoke Emacs commands, like "C-x C-f" to visit other files,
and any other command. Are you saying that you cannot type any
command while the command producing text runs in *shell*?
When you invoke "M-x shell", which shell runs in the *shell* buffer?
On my system it is cmd.exe.
> If I save text from shell to the file. And open this file by Emacs then no
> problem. Not lock Emacs. All work fine.
> I attached test file.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 12:53:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 32883 <at> debbugs.gnu.org (full text, mbox):
> From: "alexei28" <alexei28 <at> gmail.com>
> Date: Sun, 30 Sep 2018 15:15:30 +0300
Please use "Reply to All" to reply to these messages, so that the bug
address gets a copy. Thanks.
> > OK. Not mandatory to start "adb logcat -vtime". You can start any
> > process that generate text in standard output.
>
> Then I cannot reproduce the problem on my system. On my system, while the
> process runs and generates the text, I can switch to another buffer and
> invoke Emacs commands, like "C-x C-f" to visit other files, and any other
> command. Are you saying that you cannot type any command while the command
> producing text runs in *shell*?
> - Yes, I can't do anything. Sometime "C-g" help to unlock this, but
> sometimes not.
So if you do this:
M-x shell
dir
Then Emacs is locked up? Does it stop being locked up after the "DIR"
command finishes?
Does the problem happen if you invoke Emacs with "emacs -Q" from the
cmd command line?
> When you invoke "M-x shell", which shell runs in the *shell* buffer?
> On my system it is cmd.exe.
>
> - Suppose I'm in the folder d:\temp. When I start "M-x shell" then open
> shell with the next text:
>
> Microsoft Windows [Version 10.0.17134.285]
> (c) 2018 Microsoft Corporation. All rights reserved.
>
> d:\TEMP>
>
> I think this is a "cmd.exe"
Yes, this is cmd.exe.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 13:00:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 32883 <at> debbugs.gnu.org (full text, mbox):
-----Original Message-----
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Sunday, September 30, 2018 15:52
To: alexei28 <alexei28 <at> gmail.com>
Cc: 32883 <at> debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode
> From: "alexei28" <alexei28 <at> gmail.com>
> Date: Sun, 30 Sep 2018 15:15:30 +0300
Please use "Reply to All" to reply to these messages, so that the bug
address gets a copy. Thanks.
> > OK. Not mandatory to start "adb logcat -vtime". You can start any
> > process that generate text in standard output.
>
> Then I cannot reproduce the problem on my system. On my system, while
> the process runs and generates the text, I can switch to another
> buffer and invoke Emacs commands, like "C-x C-f" to visit other files,
> and any other command. Are you saying that you cannot type any
> command while the command producing text runs in *shell*?
> - Yes, I can't do anything. Sometime "C-g" help to unlock this, but
> sometimes not.
So if you do this:
M-x shell
dir
Then Emacs is locked up? Does it stop being locked up after the "DIR"
command finishes?
M-x shell
Dir
Work nice. Not lock of Emacs after finish command.
Does the problem happen if you invoke Emacs with "emacs -Q" from the cmd
command line?
Yes, it's happen when start Emacs by "emacs - Q"
> When you invoke "M-x shell", which shell runs in the *shell* buffer?
> On my system it is cmd.exe.
>
> - Suppose I'm in the folder d:\temp. When I start "M-x shell" then
> open shell with the next text:
>
> Microsoft Windows [Version 10.0.17134.285]
> (c) 2018 Microsoft Corporation. All rights reserved.
>
> d:\TEMP>
>
> I think this is a "cmd.exe"
Yes, this is cmd.exe.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 13:36:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 32883 <at> debbugs.gnu.org (full text, mbox):
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 15:59:36 +0300
>
> So if you do this:
>
> M-x shell
> dir
>
> Then Emacs is locked up? Does it stop being locked up after the "DIR"
> command finishes?
>
> M-x shell
> Dir
>
> Work nice. Not lock of Emacs after finish command.
Hmm, so what other commands do cause Emacs to lock up?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 13:42:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 32883 <at> debbugs.gnu.org (full text, mbox):
I noticed that only this command.
When in shell mode (e.g. some application) generate interactively text in
standard output .
-----Original Message-----
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Sunday, September 30, 2018 16:35
To: alexei28 <alexei28 <at> gmail.com>
Cc: 32883 <at> debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 15:59:36 +0300
>
> So if you do this:
>
> M-x shell
> dir
>
> Then Emacs is locked up? Does it stop being locked up after the "DIR"
> command finishes?
>
> M-x shell
> Dir
>
> Work nice. Not lock of Emacs after finish command.
Hmm, so what other commands do cause Emacs to lock up?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 13:51:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 32883 <at> debbugs.gnu.org (full text, mbox):
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 16:41:39 +0300
>
> I noticed that only this command.
>
> When in shell mode (e.g. some application) generate interactively text in
> standard output .
Sorry, I don't understand. What does "generate interactively" mean?
Earlier you said "you can start any process that generates text on
standard output", and "dir" is such a command. If it's only the
single command "adb logcat -vtime", and no other command produces the
same problem, maybe that command is simply incompatible with Emacs?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 14:05:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 32883 <at> debbugs.gnu.org (full text, mbox):
-----Original Message-----
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Sunday, September 30, 2018 16:51
To: alexei28 <alexei28 <at> gmail.com>
Cc: 32883 <at> debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 16:41:39 +0300
>
> I noticed that only this command.
>
> When in shell mode (e.g. some application) generate interactively text
> in standard output .
Sorry, I don't understand. What does "generate interactively" mean?
Earlier you said "you can start any process that generates text on standard
output", and "dir" is such a command. If it's only the single command "adb
logcat -vtime", and no other command produces the same problem, maybe that
command is simply incompatible with Emacs?
I mean some process (e.g. application) that generate text long time (e.g. 1
minutes) in standard output.
The command "dir" execute very quickly (about 1 second).
Test:
1. M-x shell
2. Start some application that generate text about 1 minute to standard
output.
3. Аt the fifth second press arrow up and move cursor to the center of the
screen (the text continues generated)
4. And now press Enter. It's important to press Enter when text is continue
to generate in shell mode.
5. And Emacs will "freeze". Not response any more.
Only "C-g" can help or not to unlock this.
I always kill Emacs process from Task Manager
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 14:21:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 32883 <at> debbugs.gnu.org (full text, mbox):
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 17:04:24 +0300
>
> 1. M-x shell
> 2. Start some application that generate text about 1 minute to standard
> output.
> 3. Аt the fifth second press arrow up and move cursor to the center of the
> screen (the text continues generated)
> 4. And now press Enter. It's important to press Enter when text is continue
> to generate in shell mode.
> 5. And Emacs will "freeze". Not response any more.
> Only "C-g" can help or not to unlock this.
> I always kill Emacs process from Task Manager
In my case, a single C-g stops waiting, and the application generating
the output resumes running.
Do you have a program named cat.exe somewhere? If you do, can you use
that program instead of adb logcat -vtime? You can invoke cat.exe
like this:
cat some-file
I used the output from logcat you sent instead of "some-file". I
cannot cause Emacs to lock up this way. I can always interrupt the
waiting with a single C-g.
In any case, when you press Enter, you actually send to the shell the
line that is at the cursor, so maybe you send something that runs some
other command in your case, I don't know.
Why do you need to type Enter as long as the command didn't finish
producing its output?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 15:15:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 32883 <at> debbugs.gnu.org (full text, mbox):
-----Original Message-----
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Sunday, September 30, 2018 17:20
To: alexei28 <alexei28 <at> gmail.com>
Cc: 32883 <at> debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 17:04:24 +0300
>
> 1. M-x shell
> 2. Start some application that generate text about 1 minute to
> standard output.
> 3. Аt the fifth second press arrow up and move cursor to the center of
> the screen (the text continues generated) 4. And now press Enter. It's
> important to press Enter when text is continue to generate in shell
> mode.
> 5. And Emacs will "freeze". Not response any more.
> Only "C-g" can help or not to unlock this.
> I always kill Emacs process from Task Manager
In my case, a single C-g stops waiting, and the application generating the
output resumes running.
Do you have a program named cat.exe somewhere? If you do, can you use that
program instead of adb logcat -vtime? You can invoke cat.exe like this:
cat some-file
I do the another test.
1. M-x shell
2. Open some text file (about 2 MB) by command "cat some_text.txt".
In shell mode something like this:
Microsoft Windows [Version 10.0.17134.285]
(c) 2018 Microsoft Corporation. All rights reserved.
d:\TEMP\temp>cat trace.log.2018-08-09
4. Start command
5. And while file is scrolling I press arrow up. As result cursor is on the
center of screen
6. Press Enter
7. And Emacs also "freeze". Not response. In this case Emacs is not response
only when file is opening (scrolling).
8. After "cat" finish the Emacs is success unlock. In this case (file size =
2 MB) it's unlock after 30 seconds.
But suppose file has size 200 MB. It's then unlock after one hour?
It's not good.
I used the output from logcat you sent instead of "some-file". I cannot
cause Emacs to lock up this way. I can always interrupt the waiting with a
single C-g.
In any case, when you press Enter, you actually send to the shell the line
that is at the cursor, so maybe you send something that runs some other
command in your case, I don't know.
Why do you need to type Enter as long as the command didn't finish producing
its output?
It's happens by accident.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Sun, 30 Sep 2018 17:07:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 32883 <at> debbugs.gnu.org (full text, mbox):
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 18:14:35 +0300
>
> I do the another test.
> 1. M-x shell
> 2. Open some text file (about 2 MB) by command "cat some_text.txt".
> In shell mode something like this:
>
> Microsoft Windows [Version 10.0.17134.285]
> (c) 2018 Microsoft Corporation. All rights reserved.
>
> d:\TEMP\temp>cat trace.log.2018-08-09
>
> 4. Start command
> 5. And while file is scrolling I press arrow up. As result cursor is on the
> center of screen
> 6. Press Enter
> 7. And Emacs also "freeze". Not response. In this case Emacs is not response
> only when file is opening (scrolling).
> 8. After "cat" finish the Emacs is success unlock. In this case (file size =
> 2 MB) it's unlock after 30 seconds.
> But suppose file has size 200 MB. It's then unlock after one hour?
> It's not good.
But that is what is supposed to happen. When you press Enter,
shell-mode takes all the stuff between the point where you pressed
Enter and the end of output, and submits that to the shell. Since
that's a lot of text, it could take a long time to process.
So just don't do that, it makes no sense to do that in the situation
you describe.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Mon, 01 Oct 2018 07:10:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 32883 <at> debbugs.gnu.org (full text, mbox):
-----Original Message-----
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Sunday, September 30, 2018 20:06
To: alexei28 <alexei28 <at> gmail.com>
Cc: 32883 <at> debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 18:14:35 +0300
>
> I do the another test.
> 1. M-x shell
> 2. Open some text file (about 2 MB) by command "cat some_text.txt".
> In shell mode something like this:
>
> Microsoft Windows [Version 10.0.17134.285]
> (c) 2018 Microsoft Corporation. All rights reserved.
>
> d:\TEMP\temp>cat trace.log.2018-08-09
>
> 4. Start command
> 5. And while file is scrolling I press arrow up. As result cursor is
> on the center of screen 6. Press Enter 7. And Emacs also "freeze". Not
> response. In this case Emacs is not response only when file is opening
> (scrolling).
> 8. After "cat" finish the Emacs is success unlock. In this case (file
> size =
> 2 MB) it's unlock after 30 seconds.
> But suppose file has size 200 MB. It's then unlock after one hour?
> It's not good.
But that is what is supposed to happen. When you press Enter, shell-mode
takes all the stuff between the point where you pressed Enter and the end of
output, and submits that to the shell. Since that's a lot of text, it could
take a long time to process.
So just don't do that, it makes no sense to do that in the situation you
describe.
So this is a not Emac's bug?
But sometime I need to press Enter(while text is generate) because I , e.g.
want to insert some new text (e.g. notes) between existing text.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Mon, 01 Oct 2018 07:46:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 32883 <at> debbugs.gnu.org (full text, mbox):
"alexei28" <alexei28 <at> gmail.com> writes:
> But sometime I need to press Enter(while text is generate) because I , e.g.
> want to insert some new text (e.g. notes) between existing text.
Then you shall press "C-q ENTER" instead.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Mon, 01 Oct 2018 07:50:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 32883 <at> debbugs.gnu.org (full text, mbox):
Here result:
C-q ENTER
^Minsert new text
How hide ^M ?
-----Original Message-----
From: Michael Albinus <michael.albinus <at> gmx.de>
Sent: Monday, October 1, 2018 10:45
To: alexei28 <alexei28 <at> gmail.com>
Cc: 'Eli Zaretskii' <eliz <at> gnu.org>; 32883 <at> debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode
"alexei28" <alexei28 <at> gmail.com> writes:
> But sometime I need to press Enter(while text is generate) because I ,
e.g.
> want to insert some new text (e.g. notes) between existing text.
Then you shall press "C-q ENTER" instead.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Mon, 01 Oct 2018 07:51:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 32883 <at> debbugs.gnu.org (full text, mbox):
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Mon, 1 Oct 2018 10:09:37 +0300
>
> So this is a not Emac's bug?
No, I don't think so.
> But sometime I need to press Enter(while text is generate) because I , e.g.
> want to insert some new text (e.g. notes) between existing text.
I suggest to use "C-q C-j" for that, i.e. quote the Enter key.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Mon, 01 Oct 2018 07:54:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 32883 <at> debbugs.gnu.org (full text, mbox):
-----Original Message-----
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Monday, October 1, 2018 10:50
To: alexei28 <alexei28 <at> gmail.com>
Cc: 32883 <at> debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Mon, 1 Oct 2018 10:09:37 +0300
>
> So this is a not Emac's bug?
No, I don't think so.
> But sometime I need to press Enter(while text is generate) because I ,
e.g.
> want to insert some new text (e.g. notes) between existing text.
I suggest to use "C-q C-j" for that, i.e. quote the Enter key.
OK. I will use "C-q C-j". It's a good solution. Thanks very much.
Emacs is cool :-)
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Mon, 01 Oct 2018 08:03:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"alexei28" <alexei28 <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 01 Oct 2018 08:03:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 32883-done <at> debbugs.gnu.org (full text, mbox):
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Mon, 1 Oct 2018 10:53:05 +0300
>
> > I suggest to use "C-q C-j" for that, i.e. quote the Enter key.
>
> OK. I will use "C-q C-j". It's a good solution. Thanks very much.
>
> Emacs is cool :-)
Thanks, I'm therefore closing this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Mon, 01 Oct 2018 08:05:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 32883-done <at> debbugs.gnu.org (full text, mbox):
OK
-----Original Message-----
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Monday, October 1, 2018 11:03
To: alexei28 <alexei28 <at> gmail.com>
Cc: 32883-done <at> debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode
> From: "alexei28" <alexei28 <at> gmail.com>
> Cc: <32883 <at> debbugs.gnu.org>
> Date: Mon, 1 Oct 2018 10:53:05 +0300
>
> > I suggest to use "C-q C-j" for that, i.e. quote the Enter key.
>
> OK. I will use "C-q C-j". It's a good solution. Thanks very much.
>
> Emacs is cool :-)
Thanks, I'm therefore closing this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Mon, 01 Oct 2018 08:46:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 32883 <at> debbugs.gnu.org (full text, mbox):
"alexei28" <alexei28 <at> gmail.com> writes:
> Here result:
>
> C-q ENTER
>
> ^Minsert new text
>
> How hide ^M ?
Try "C-q C-j".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32883
; Package
emacs
.
(Mon, 01 Oct 2018 08:48:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 32883 <at> debbugs.gnu.org (full text, mbox):
Yes, this is a good solution.
Thanks
-----Original Message-----
From: Michael Albinus <michael.albinus <at> gmx.de>
Sent: Monday, October 1, 2018 11:45
To: alexei28 <alexei28 <at> gmail.com>
Cc: 'Eli Zaretskii' <eliz <at> gnu.org>; 32883 <at> debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode
"alexei28" <alexei28 <at> gmail.com> writes:
> Here result:
>
> C-q ENTER
>
> ^Minsert new text
>
> How hide ^M ?
Try "C-q C-j".
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 29 Oct 2018 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 235 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.