bug#21652: bell chars

bug#21652: bell chars

[Tom Baker]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

Please excuse me if this has been suggested before for adding to Emacs.



I have a real need to have my command shells beep at me when their work is
done, so I set it up so beeps are passed to the

host system.



In the function comint-carriage-motion I alter



(defun comint-carriage-motion (start end)

  "Interpret carriage control characters in the region from START to END.

Translate carriage return/linefeed sequences to linefeeds.

Make single carriage returns delete to the beginning of the line.

Make backspaces delete the previous character."



to say



(defun comint-carriage-motion (start end)

  "Interpret carriage control characters and bells in the region from START
to END.

Translate carriage return/linefeed sequences to linefeeds.

Make single carriage returns delete to the beginning of the line.

Make backspaces delete the previous character. Pass bells through."



and the code chunk



                (cond ((= ch ?\b)                  ; CH = BS

                       (delete-char 1)

                       (if (> (point) lbeg)

                                   (delete-char -1)))

                      ((= ch ?\n)

                       (when delete-end            ; CH = LF

                                (if (< delete-end (point))

                                     (delete-region lbeg delete-end))

                                (set-marker delete-end nil)

                                (setq delete-end nil))

                       (forward-char 1)

                       (setq lbeg (point)))

                      (t                            ; CH = CR



changed to



                (cond ((= ch ?\b)            ; CH = BS

                       (delete-char 1)

                       (if (> (point) lbeg)

                                   (delete-char -1)))

                      ((= ch ?\n)

                       (when delete-end      ; CH = LF

                                (if (< delete-end (point))

                                     (delete-region lbeg delete-end))

                                (set-marker delete-end nil)

                                (setq delete-end nil))

                       (forward-char 1)

                       (setq lbeg (point)))

                      ((= ch ?\a)

                       (forward-char 1)

                       (ding)

                       (sit-for 0.45 t))      ; CH = BL

                      (t                      ; CH = CR



Again, please excuse me if this has been suggested as a feature before.


God's Blessings,

Tom Baker

[-- Attachment #2: Type: text/html, Size: 10383 bytes --]

bug#21652: bell chars

[Stefan Kangas]

Tom Baker <tombaker17@gmail.com> writes:

> I have a real need to have my command shells beep at me when their work is done, so I set it up so beeps are passed to the
> host system.
>
> In the function comint-carriage-motion I alter
>
> (defun comint-carriage-motion (start end)
>   "Interpret carriage control characters in the region from START to END.
> Translate carriage return/linefeed sequences to linefeeds.
> Make single carriage returns delete to the beginning of the line.
> Make backspaces delete the previous character."
>
> to say
>
> (defun comint-carriage-motion (start end)
>   "Interpret carriage control characters and bells in the region from START to END.
> Translate carriage return/linefeed sequences to linefeeds.
> Make single carriage returns delete to the beginning of the line.
> Make backspaces delete the previous character. Pass bells through."
>
> and the code chunk
>
>                 (cond ((= ch ?\b)                  ; CH = BS
>                        (delete-char 1)
>                        (if (> (point) lbeg)
>                                    (delete-char -1)))
>                       ((= ch ?\n)
>                        (when delete-end            ; CH = LF
>                                 (if (< delete-end (point))
>                                      (delete-region lbeg delete-end))
>                                 (set-marker delete-end nil)
>                                 (setq delete-end nil))
>                        (forward-char 1)
>                        (setq lbeg (point)))
>                       (t                            ; CH = CR
>
> changed to
>
>                 (cond ((= ch ?\b)            ; CH = BS
>                        (delete-char 1)
>                        (if (> (point) lbeg)
>                                    (delete-char -1)))
>                       ((= ch ?\n)
>                        (when delete-end      ; CH = LF
>                                 (if (< delete-end (point))
>                                      (delete-region lbeg delete-end))
>                                 (set-marker delete-end nil)
>                                 (setq delete-end nil))
>                        (forward-char 1)
>                        (setq lbeg (point)))
>                       ((= ch ?\a)
>                        (forward-char 1)
>                        (ding)
>                        (sit-for 0.45 t))      ; CH = BL
>                       (t                      ; CH = CR

So the difference here is that you would like to add a call to (ding)?
I'm not sure the addition you propose is suitable for general use.

Perhaps you could explain the use-case here in a bit more detail?  For
example, why can't you just add an advice to the function in question?

Best regards,
Stefan Kangas

bug#21652: bell chars

[Tom Baker]

First the use case -- One has a number of things to do, in a limited
amount of time. Using the command shell in emacs, give the first in a
series of commands, one that will take a long time; after it finishes
successfully, another command should be given; if it fails, it should
be corrected and run again. And while it runs for a long time, one
wants to be doing something else.  So one arranges for an "echo
control-G" command to make the thing beep when it is done, so one
doesn't have to sit and watch the thing run through the command,
watching for the first command to finish.

I wrote this because I have a history of setting one command going,
then going off to do something else, and then remembering an hour
later "is that command done yet?" and looking to see that it finished
a half hour before.

Second -- I have little trouble withdrawing the suggestion, because
the "shelisp" package is a more suitable implementation of my use
case. The idea of an advice got to be a little sloppy of an
implementation because the sound would come put before the call, or
after the call, and not synchronized with the other characters.

Thanks for your volunteer work in maintaining the emacs software!

On 8/15/20, Stefan Kangas <stefan@marxist.se> wrote:
> Tom Baker <tombaker17@gmail.com> writes:
>
>> I have a real need to have my command shells beep at me when their work is
>> done, so I set it up so beeps are passed to the
>> host system.
>>
>> In the function comint-carriage-motion I alter
>>
>> (defun comint-carriage-motion (start end)
>>   "Interpret carriage control characters in the region from START to END.
>> Translate carriage return/linefeed sequences to linefeeds.
>> Make single carriage returns delete to the beginning of the line.
>> Make backspaces delete the previous character."
>>
>> to say
>>
>> (defun comint-carriage-motion (start end)
>>   "Interpret carriage control characters and bells in the region from
>> START to END.
>> Translate carriage return/linefeed sequences to linefeeds.
>> Make single carriage returns delete to the beginning of the line.
>> Make backspaces delete the previous character. Pass bells through."
>>
>> and the code chunk
>>
>>                 (cond ((= ch ?\b)                  ; CH = BS
>>                        (delete-char 1)
>>                        (if (> (point) lbeg)
>>                                    (delete-char -1)))
>>                       ((= ch ?\n)
>>                        (when delete-end            ; CH = LF
>>                                 (if (< delete-end (point))
>>                                      (delete-region lbeg delete-end))
>>                                 (set-marker delete-end nil)
>>                                 (setq delete-end nil))
>>                        (forward-char 1)
>>                        (setq lbeg (point)))
>>                       (t                            ; CH = CR
>>
>> changed to
>>
>>                 (cond ((= ch ?\b)            ; CH = BS
>>                        (delete-char 1)
>>                        (if (> (point) lbeg)
>>                                    (delete-char -1)))
>>                       ((= ch ?\n)
>>                        (when delete-end      ; CH = LF
>>                                 (if (< delete-end (point))
>>                                      (delete-region lbeg delete-end))
>>                                 (set-marker delete-end nil)
>>                                 (setq delete-end nil))
>>                        (forward-char 1)
>>                        (setq lbeg (point)))
>>                       ((= ch ?\a)
>>                        (forward-char 1)
>>                        (ding)
>>                        (sit-for 0.45 t))      ; CH = BL
>>                       (t                      ; CH = CR
>
> So the difference here is that you would like to add a call to (ding)?
> I'm not sure the addition you propose is suitable for general use.
>
> Perhaps you could explain the use-case here in a bit more detail?  For
> example, why can't you just add an advice to the function in question?
>
> Best regards,
> Stefan Kangas
>

bug#21652: bell chars

[Stefan Kangas]

Tom Baker <tombaker17@gmail.com> writes:

> I wrote this because I have a history of setting one command going,
> then going off to do something else, and then remembering an hour
> later "is that command done yet?" and looking to see that it finished
> a half hour before.

This is a valid use case.  But I'm not convinced we should do any
changes in the code to cover it.  The problem here is that everyone's
needs are different, so we would end up having to spread little `beep's
all over the Emacs code base.

May I propose something like the following as an alternative:

   long-running-command.sh ; aplay beep.wav

(Searching the web I also found out about a command line utility
`beep' that may or may not be of interest.)

> Second -- I have little trouble withdrawing the suggestion, because
> the "shelisp" package is a more suitable implementation of my use
> case. The idea of an advice got to be a little sloppy of an
> implementation because the sound would come put before the call, or
> after the call, and not synchronized with the other characters.

I don't know what shelisp is or how it relates to the current
discussion.  Could you please clarify?

I'm sorry to hear you had no success with advice.  That would be the
canonical way to add specialized behaviour to a function in Emacs, but
sometimes it can be a bit finicky to get the details right.  Perhaps you
could ask on the emacs-help mailing list about it.

> Thanks for your volunteer work in maintaining the emacs software!

Thanks for using it!

Best regards,
Stefan Kangas

bug#21652: bell chars

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 16 Aug 2020 07:23:29 -0700
> Cc: 21652@debbugs.gnu.org
> 
> Tom Baker <tombaker17@gmail.com> writes:
> 
> > I wrote this because I have a history of setting one command going,
> > then going off to do something else, and then remembering an hour
> > later "is that command done yet?" and looking to see that it finished
> > a half hour before.
> 
> This is a valid use case.

There's something I don't think I understand in this use case: if the
same command was run from a shell prompt outside Emacs, would the
shell beep?  Or is the intent to make the Emacs shell mode do
something a shell doesn't?

bug#21652: bell chars

[Tom Baker]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

On Sun, Aug 16, 2020 at 10:57 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Kangas <stefan@marxist.se>
> > Date: Sun, 16 Aug 2020 07:23:29 -0700
> > Cc: 21652@debbugs.gnu.org
> >
> > Tom Baker <tombaker17@gmail.com> writes:
> >
> > > I wrote this because I have a history of setting one command going,
> > > then going off to do something else, and then remembering an hour
> > > later "is that command done yet?" and looking to see that it finished
> > > a half hour before.
> >
> > This is a valid use case.
>
> There's something I don't think I understand in this use case: if the
> same command was run from a shell prompt outside Emacs, would the
> shell beep?  Or is the intent to make the Emacs shell mode do
> something a shell doesn't?
>

This is correct.  Most non-emacs shells have a scrolling limit, so
eventually command output scrolls off the top of the screen and is lost
forever.

So "the Emacs shell mode" does "something a shell doesn't" right there.

Whether I am on Android, Mac, PC, or Linux, I can scroll back in the shell
mode.  And the "cross-platform" part of it is important to me, since I jump
from one machine to another all the time.

> would the shell beep?

Yes, whether in bash or cmd.exe, I add an "echo the bell char so I'll know
I am done" command. In shell mode (and not in all external shells), I can
"enter my command" and hit enter, and then slap my forehead and mutter
"gee, I forgot", and enter the "echo bell" command any time after that --
the shell mode will execute followup lines of commands afterwards
seamlessly.

So that's another "the Emacs shell mode" does "something a shell doesn't".

There are lots more -- I've relied on the basic Emacs shell-mode since the
1980's. It's incredibly productive.

(IN CASE OF FOLLOWUP DISCUSSION: I already said (in the post to which this
is a reply) that I can withdraw the suggestion. I don't need it any more.
[I forget exactly what year, 2018, 2019, or 2020, I made this suggestion,
but I've moved on from it without an emacs change, which I did form my own
benefit, anyway.] )

[-- Attachment #2: Type: text/html, Size: 3008 bytes --]

bug#21652: bell chars

[Andreas Schwab]

On Aug 16 2020, Tom Baker wrote:

> This is correct.  Most non-emacs shells have a scrolling limit, so
> eventually command output scrolls off the top of the screen and is lost
> forever.

That's a property of the terminal emulator, not the shell.  For example,
konsole can be configured to infinite scrollback.

Andreas.

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

bug#21652: bell chars

[Tom Baker]

On 8/16/20, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Aug 16 2020, Tom Baker wrote:
>
>> This is correct.  Most non-emacs shells have a scrolling limit, so
>> eventually command output scrolls off the top of the screen and is lost
>> forever.
>
> That's a property of the terminal emulator, not the shell.  For example,
> konsole can be configured to infinite scrollback.

Thank you, Andreas, for that correction. You are right, I was speaking
in a "general usage", which was technically inexact.

On windows, one can run the CMD.EXE "shell" within the "Command
Window" that is a terminal emulator.

On platforms that support the bash "shell", it usually is not hard to
have it generate its own teminal emulator window. One can also just
run the "shell" within another terminal emulator.

bug#21652: bell chars

[Eli Zaretskii]

> From: Tom Baker <tombaker17@gmail.com>
> Date: Sun, 16 Aug 2020 11:55:01 -0400
> Cc: Stefan Kangas <stefan@marxist.se>, 21652@debbugs.gnu.org
> 
> > would the shell beep?
> 
> Yes, whether in bash or cmd.exe, I add an "echo the bell char so I'll know I am done" command. In shell
> mode (and not in all external shells), I can "enter my command" and hit enter, and then slap my forehead and
> mutter "gee, I forgot", and enter the "echo bell" command any time after that -- the shell mode will execute
> followup lines of commands afterwards seamlessly.
> 
> So that's another "the Emacs shell mode" does "something a shell doesn't".

I'm probably confused: if shell-mode does beep, then why do you need
any changes?  Just be sure to have the "echo bell" at the end of your
command, and it will beep, right?

> (IN CASE OF FOLLOWUP DISCUSSION: I already said (in the post to which this is a reply) that I can
> withdraw the suggestion. I don't need it any more. [I forget exactly what year, 2018, 2019, or 2020, I made
> this suggestion, but I've moved on from it without an emacs change, which I did form my own benefit,
> anyway.] )

Before we decide that you should withdraw your suggestion, I think
it's worthwhile to figure out whether there's some Emacs bug here.  If
the shell does something, but running that shell inside Emacs doesn't,
then there's a bug we had better fixed.

But, of course, if you would like to stop the discussion, I won't
insist on continuing it.

Thanks.

bug#21652: bell chars

[Tom Baker]

On 8/16/20, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Tom Baker <tombaker17@gmail.com>
>> Date: Sun, 16 Aug 2020 11:55:01 -0400
>> Cc: Stefan Kangas <stefan@marxist.se>, 21652@debbugs.gnu.org
>>
>> > would the shell beep?
>>
>> Yes, whether in bash or cmd.exe, I add an "echo the bell char so I'll know
>> I am done" command.

Yes, but know that I mean the instance bash that I invoked outside of
emacs, or the instance
of cmd.exe that I invoked in the Windows Run Command box. A separate
window, not in emacs. My command that does work runs to completion,
and then the computer puts out a beep sound.

>> In shell
>> mode (and not in all external shells), I can "enter my command" and hit
>> enter, and then slap my forehead and
>> mutter "gee, I forgot", and enter the "echo bell" command any time after
>> that -- the shell mode will execute
>> followup lines of commands afterwards seamlessly.

All that happens when this runs inside of emacs is that my command
that does work runs to completion, and then my "echo bell" command
runs and the screen now has a cute little up arrow
and a letter G (for the control-G that was output).

> I'm probably confused: if shell-mode does beep, then why do you need
> any changes?  Just be sure to have the "echo bell" at the end of your
> command, and it will beep, right?

No. The paragraph was confusing, I admit. shell-mode will output a
control-G to the screen, silently, and the user sees  ^G  .

>> (IN CASE OF FOLLOWUP DISCUSSION: I already said (in the post to which this
>> is a reply) that I can
>> withdraw the suggestion. I don't need it any more. [I forget exactly what
>> year, 2018, 2019, or 2020, I made
>> this suggestion, but I've moved on from it without an emacs change, which
>> I did form my own benefit,
>> anyway.] )
>
> Before we decide that you should withdraw your suggestion, I think
> it's worthwhile to figure out whether there's some Emacs bug here.  If

I do not know how this wound up on a "bug list" when this would be
simply an "enhancement".

There is no emacs bug.

bug#21652: bell chars

[Eli Zaretskii]

> From: Tom Baker <tombaker17@gmail.com>
> Date: Sun, 16 Aug 2020 13:10:40 -0400
> Cc: stefan@marxist.se, 21652@debbugs.gnu.org
> 
> shell-mode will output a control-G to the screen, silently, and the
> user sees ^G .

That sounds like a bug to me: Emacs should emulate what the shell does
outside of Emacs.

Or maybe you need to run "M-x term" for that to work?

bug#21652: bell chars

[Andreas Schwab]

On Aug 16 2020, Eli Zaretskii wrote:

>> From: Tom Baker <tombaker17@gmail.com>
>> Date: Sun, 16 Aug 2020 13:10:40 -0400
>> Cc: stefan@marxist.se, 21652@debbugs.gnu.org
>> 
>> shell-mode will output a control-G to the screen, silently, and the
>> user sees ^G .
>
> That sounds like a bug to me: Emacs should emulate what the shell does
> outside of Emacs.

It's a matter of how much you want to do in the
comint-output-filter-functions.

Andreas.

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

bug#21652: bell chars

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Tom Baker <tombaker17@gmail.com>,  21652@debbugs.gnu.org,
>   stefan@marxist.se
> Date: Sun, 16 Aug 2020 19:51:20 +0200
> 
> > That sounds like a bug to me: Emacs should emulate what the shell does
> > outside of Emacs.
> 
> It's a matter of how much you want to do in the
> comint-output-filter-functions.

Right, so maybe we could have a function to handle the bell, and then
users who want it could customize comint-output-filter-functions to
include that function.

bug#21652: bell chars

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Right, so maybe we could have a function to handle the bell, and then
> users who want it could customize comint-output-filter-functions to
> include that function.

I've now done this in Emacs 29.

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

bug#21652: bell chars

[Tom Baker]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

The "shelisp" package is one of the "packages" that emacs can use. (I refer
you to the manual about
"packages" to find it.)  It sits on the shell-mode and watches for a
certain escape sequence being written to the screen.

When the escape sequence shows up, immediately following should be some
elisp code, followed by a terminating sequence.

My example would be that I enter

     $ longrunningcommand.exe ; mydinger.sh

where "mydinger.sh" is a bash script that outputs the escape sequence, then
"(ding)", and then the terminating sequence.

That is enough to make the emacs ring a bell and get my attention.

[Please remember, in the post to which this was a reply, I suggest
withdrawing the suggestion. I made it quite a while back and don't
need it. Thanks.]

[-- Attachment #2: Type: text/html, Size: 1036 bytes --]

bug#21652: bell chars

[Stefan Kangas]

Tom Baker <tombaker17@gmail.com> writes:

> [Please remember, in the post to which this was a reply, I suggest
> withdrawing the suggestion. I made it quite a while back and don't
> need it. Thanks.]

Sorry, I misread what you were saying in that message and thought you
were saying the opposite.

I'm happy to hear that you found a solution to your problem.  I think
Eli asked some questions in his latest email that you could maybe help
us clarify.

Best regards,
Stefan Kangas