Vendoring code in a (Non?)GNU ELPA package

Vendoring code in a (Non?)GNU ELPA package

[Daniel Semyonov]

I've created a dynamic module implementing a simple audio player using
miniaudio (https://miniaud.io, public domain or MIT-0) and libsndfile
(https://libsndfile.github.io/libsndfile, LGPL).
I also built a player implementation for EMMS utilizing it.

However, it has been sitting in a local directory for a while since
I'm not sure how to publish it - miniaudio is very self contained, it
requires no dependencies and is distributed as a single header file
(miniaudio.h) containing all the code (which is then compiled with your
program).  AFAICT almost no distribution packages it.

I think the intention is to "vendor" miniaudio.h with your program (not
sure if I'm using the term correctly), but this doesn't really fit well
into the concept of a package IMO, especially since GNU ELPA packages
require copyright assignment.

Is it acceptable to "vendor" miniaudio.h with the package on GNU or
NonGNU ELPA?
Assuming it isn't, is it acceptable to download "miniaudio.h" as part of
the package installation process if it's not available locally (which
I'm not sure how to check either)?

In any case, I decided to polish the code a bit and upload it to a
public repo in the meantime: (currently I just added miniaudio.h to the tree)
https://git.sr.ht/~dsemy/emacs-miniaudio-player

Some notes about the module:
- Should support all audio file types supported by libsndfile.
- Should work on most platforms, I use it on GNU/Linux and Android.
- All of my C knowledge comes from trial and error and reading the
  source code of other free software, so there might be some very
  obvious issues I'm not aware of.

Thanks,
Daniel

Re: Vendoring code in a (Non?)GNU ELPA package

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think the intention is to "vendor" miniaudio.h with your program (not
  > sure if I'm using the term correctly),

Can you please state what you mean in different words?  "Vendonr" is a
noun, not a verb, and that noun is usually meaningless in the context
of free software.  As a result, I can't imagine what a verb "to
vendor" would mean.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Vendoring code in a (Non?)GNU ELPA package

[No Wayman]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I think the intention is to "vendor" miniaudio.h with your program (not
>   > sure if I'm using the term correctly),
>
> Can you please state what you mean in different words?  "Vendonr" is a
> noun, not a verb, and that noun is usually meaningless in the context
> of free software.  As a result, I can't imagine what a verb "to
> vendor" would mean.

Vendoring in this context is industry jargon for hosting 3rd party
dependencies (in this case the miniaudio library) alongside software
(the elisp package). Put plainly, they want to know if it would be okay
to host a copy of the miniaudio library alongside their elisp package.

Re: Vendoring code in a (Non?)GNU ELPA package

[Daniel Semyonov]

>>>>> Richard Stallman writes:

    >> I think the intention is to "vendor" miniaudio.h with your
    >> program (not sure if I'm using the term correctly),

    > Can you please state what you mean in different words?  "Vendonr"
    > is a noun, not a verb, and that noun is usually meaningless in the
    > context of free software.  As a result, I can't imagine what a
    > verb "to vendor" would mean.

Sure, what I meant was to include the file "miniaudio.h" as part of the
package.  "miniaudio.h" is not a usual C header file, it actually
contains all the code of the miniaudio library, so in effect this will
make the package mostly 3rd party code (which is why I assume this isn't
acceptable).
However, since only a few distributions package miniaudio, this seems
like it would be the most convenient option for users.

I don't know why miniaudio is distributed this way, I'm assuming there
is some benefit to this method that I don't understand because I don't
have much experience with C programming.

Re: Vendoring code in a (Non?)GNU ELPA package

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Vendoring in this context is industry jargon for hosting 3rd party
  > dependencies (in this case the miniaudio library) alongside software
  > (the elisp package). Put plainly, they want to know if it would be okay
  > to host a copy of the miniaudio library alongside their elisp package.

Thanks.

Let's not adopt that term "vendoring", particularly since the GNU Project
is not a "vender".  But the question is a reasonable one to pose.

The answer would depend on questions such as
(1) What is the license of that library?
(2) What on does it do?
(3) What is the reason for using it?
(4) When running, how does it communicate with Emacs?
(5) Does it get linked with Emacs?  If so, when does that happen?
(6) In what sense is it a "library"?
(7) Would this be souce code, executable, or both?
(8) How would it get built for your distro?

Some combinations of answers might make it ok, others would make it
unacceptable.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Vendoring code in a (Non?)GNU ELPA package

[Dmitry Gutov]

On 31/12/2023 05:15, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > Vendoring in this context is industry jargon for hosting 3rd party
>    > dependencies (in this case the miniaudio library) alongside software
>    > (the elisp package). Put plainly, they want to know if it would be okay
>    > to host a copy of the miniaudio library alongside their elisp package.
> 
> Thanks.
> 
> Let's not adopt that term "vendoring", particularly since the GNU Project
> is not a "vender".  But the question is a reasonable one to pose.
> 
> The answer would depend on questions such as
> (1) What is the license of that library?
> (2) What on does it do?
> (3) What is the reason for using it?
> (4) When running, how does it communicate with Emacs?
> (5) Does it get linked with Emacs?  If so, when does that happen?
> (6) In what sense is it a "library"?
> (7) Would this be souce code, executable, or both?
> (8) How would it get built for your distro?
> 
> Some combinations of answers might make it ok, others would make it
> unacceptable.

I'm pretty sure that most of these questions have answers in the 
original email that started this thread.

Re: Vendoring code in a (Non?)GNU ELPA package

[Daniel Semyonov]

>>>>> Richard Stallman writes:

    > Let's not adopt that term "vendoring", particularly since the GNU
    > Project is not a "vender".  But the question is a reasonable one
    > to pose.

I agree; I only used the term originally since it seemed to describe
what I wanted to do and I saw it used online.

    > The answer would depend on questions such as
    > (1) What is the license of that library?

A choice of either Unlicense (public domain) or MIT No Attribution (I'll
paste the exact license text as it appears in the library at the end of
this email).

    > (2) What on does it do?

It provides a uniform API for playing or recording audio on various
platforms (GNU/Linux, FreeBSD, OpenBSD, NetBSD, Windows, macOS, Android,
iOS and browsers).
It also includes (quoted from the website, 'miniaud.io'): "Built-in
decoders, advanced mixing and effect processing, resource management, 3D
spatialization, filters, data conversion and more."

    > (3) What is the reason for using it?

My module only uses the audio playback API to play music through Emacs.
I don't currently have plans to make use of other parts of the library.

    > (4) When running, how does it communicate with Emacs?

Some functions exposed to Elisp in my module use subroutines defined in
"miniaudio.h".  Emacs also gets input through a pipe process (created
with 'make-pipe-process') from the module, which writes to the pipe
process through a file descriptor; this is required to notify Emacs when
audio playback finishes.

    > (5) Does it get linked with Emacs?  If so, when does that happen?
    > (6) In what sense is it a "library"?
    > (7) Would this be source code, executable, or both?

I don't have a formal background in C so I might not understand the
terminology correctly, but I think it gets linked with Emacs when my
module does (when it is loaded by Emacs with 'module-load', for
example).

It is distributed as a single source file ("miniaudio.h") which is
included by my module.  "miniaudio.h" contains all the code of the
miniaudio "library".

I don't know if my module "links" with miniaudio technically, since all
of its code is completely contained inside my module once built.

    > (8) How would it get built for your distro?

Assuming you mean the miniaudio library itself, it seems there is an
official "split" version of it which contains both "miniaudio.c" and
"miniaudio.h", where the actual implementation lives inside
"miniaudio.c".

I think the few distros that do package it compile this version and
distribute it like other C libraries.

If you mean my module, then I'm not sure - I never really looked into
how distros manage Emacs packages.

    > Some combinations of answers might make it ok, others would make
    > it unacceptable.

Hopefully I've made things clear now, thanks for your interest.

Daniel


License text which appears at the end of the file "miniaudio.h":


This software is available as a choice of the following licenses. Choose
whichever you prefer.

===============================================================================
ALTERNATIVE 1 - Public Domain (www.unlicense.org)
===============================================================================
This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or distribute this
software, either in source code form or as a compiled binary, for any purpose,
commercial or non-commercial, and by any means.

In jurisdictions that recognize copyright laws, the author or authors of this
software dedicate any and all copyright interest in the software to the public
domain. We make this dedication for the benefit of the public at large and to
the detriment of our heirs and successors. We intend this dedication to be an
overt act of relinquishment in perpetuity of all present and future rights to
this software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to <http://unlicense.org/>

===============================================================================
ALTERNATIVE 2 - MIT No Attribution
===============================================================================
Copyright 2023 David Reid

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Re: Vendoring code in a (Non?)GNU ELPA package

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > A choice of either Unlicense (public domain) or MIT No Attribution (I'll
  > paste the exact license text as it appears in the library at the end of
  > this email).

The Unlicense is adequate to make it free software we cna use.
"MIT No Attribution" is not the name of a license I know of.

(Later) I see you showed it at the end of the message.  It is ok.

  > My module only uses the audio playback API to play music through Emacs.
  > I don't currently have plans to make use of other parts of the library.

I see.  It woild not be a pronlem to use a simple free linraru for
that.  But maybe it is not necessary.  Will `play-sound' do the job?

  > I don't have a formal background in C so I might not understand the
  > terminology correctly, but I think it gets linked with Emacs when my
  > module does (when it is loaded by Emacs with 'module-load', for
  > example).

Could a C expert please check what is going on here?

  > Assuming you mean the miniaudio library itself, it seems there is an
  > official "split" version of it which contains both "miniaudio.c" and
  > "miniaudio.h", where the actual implementation lives inside
  > "miniaudio.c".

That makes sense to me -- it is common practice.
How does the version you use differ from that?



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Vendoring code in a (Non?)GNU ELPA package

[Daniel Semyonov]

>>>>> Richard Stallman writes:

    >> My module only uses the audio playback API to play music through
    >> Emacs.  I don't currently have plans to make use of other parts
    >> of the library.

    > I see.  It woild not be a pronlem to use a simple free linraru for
    > that.  But maybe it is not necessary.  Will `play-sound' do the
    > job?

Unfortunately no, for various reasons:
- 'play-sound' blocks Emacs while the sound is playing; the functions my
  module implements play audio and manage playback asynchronously.
- 'play-sound' only supports playing WAV and AU files (though I see now
  that sound data can also be passed as a string, so I could implement
  decoding functions in C and use them together with 'play-sound' to play
  any sound file IIUC).
- My module has been successfully tested on Android, and should also work
  on Windows.  'play-sound' doesn't work at all on Android, and passing
  sound data as a string isn't supported on Windows.

    >> Assuming you mean the miniaudio library itself, it seems there is
    >> an official "split" version of it which contains both
    >> "miniaudio.c" and "miniaudio.h", where the actual implementation
    >> lives inside "miniaudio.c".

    > That makes sense to me -- it is common practice.  How does the
    > version you use differ from that?

The version I use (which is the "main" version) combines "miniaudio.c"
and "miniaudio.h" into a single file.

Re: Vendoring code in a (Non?)GNU ELPA package

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > The answer would depend on questions such as
  > > (1) What is the license of that library?
  > > (2) What on does it do?
  > > (3) What is the reason for using it?
  > > (4) When running, how does it communicate with Emacs?
  > > (5) Does it get linked with Emacs?  If so, when does that happen?
  > > (6) In what sense is it a "library"?
  > > (7) Would this be souce code, executable, or both?
  > > (8) How would it get built for your distro?
  > > 
  > > Some combinations of answers might make it ok, others would make it
  > > unacceptable.

  > I'm pretty sure that most of these questions have answers in the 
  > original email that started this thread.

Maybe they do, but they were not clear to me.

If you can find the answers in that message, would you please
facilitate the discussions we should have now
by posting each of those answers in clear, explicit words?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Vendoring code in a (Non?)GNU ELPA package

[Stefan Kangas]

Daniel Semyonov <daniel@dsemy.com> writes:

>>>>>> Richard Stallman writes:
>
>     >> My module only uses the audio playback API to play music through
>     >> Emacs.  I don't currently have plans to make use of other parts
>     >> of the library.
>
>     > I see.  It woild not be a pronlem to use a simple free linraru for
>     > that.  But maybe it is not necessary.  Will `play-sound' do the
>     > job?
>
> Unfortunately no, for various reasons:
> - 'play-sound' blocks Emacs while the sound is playing; the functions my
>   module implements play audio and manage playback asynchronously.
> - 'play-sound' only supports playing WAV and AU files (though I see now
>   that sound data can also be passed as a string, so I could implement
>   decoding functions in C and use them together with 'play-sound' to play
>   any sound file IIUC).
> - My module has been successfully tested on Android, and should also work
>   on Windows.  'play-sound' doesn't work at all on Android, and passing
>   sound data as a string isn't supported on Windows.

Is it possible to fix the above issues in `play-sound'?  That would be
preferable, because then it would benefit all users and not just those
that use your module.

Re: Vendoring code in a (Non?)GNU ELPA package

[Daniel Semyonov]

>>>>> Stefan Kangas writes:

    > Daniel Semyonov <daniel@dsemy.com> writes:
    >>>>>>> Richard Stallman writes:
    >> 
    >> >> My module only uses the audio playback API to play music
    >> through >> Emacs.  I don't currently have plans to make use of
    >> other parts >> of the library.
    >> 
    >> > I see.  It woild not be a pronlem to use a simple free linraru
    >> for > that.  But maybe it is not necessary.  Will `play-sound' do
    >> the > job?
    >> 
    >> Unfortunately no, for various reasons: - 'play-sound' blocks
    >> Emacs while the sound is playing; the functions my module
    >> implements play audio and manage playback asynchronously.  -
    >> 'play-sound' only supports playing WAV and AU files (though I see
    >> now that sound data can also be passed as a string, so I could
    >> implement decoding functions in C and use them together with
    >> 'play-sound' to play any sound file IIUC).  - My module has been
    >> successfully tested on Android, and should also work on Windows.
    >> 'play-sound' doesn't work at all on Android, and passing sound
    >> data as a string isn't supported on Windows.

    > Is it possible to fix the above issues in `play-sound'?  That
    > would be preferable, because then it would benefit all users and
    > not just those that use your module.

I don't see why it wouldn't be possible, though it would change the
behavior of `play-sound' slightly, so maybe a new function should be
introduced instead.

I could try to implement an `async-play-sound-internal' built-in
function (for GNU/Linux only at first), using the available subroutines
in "src/sound.c", though it might take me a while as I have near zero
experience with Emacs' C code, and this will be lower level than the
implementation in my module.

BTW, is using threads (pthreads) acceptable?  I saw many files under
"src/" that include "pthread.h" but I couldn't find any file where a
thread is created (though maybe I missed something).
If not, I'm not really sure how to implement this (I only ever did async
programming in C using pthreads, and since I don't have any sort of
formal background in C, I never learned or tried any other method).

Thanks,
Daniel

Re: Vendoring code in a (Non?)GNU ELPA package

[Stefan Kangas]

Daniel Semyonov <daniel@dsemy.com> writes:

> I don't see why it wouldn't be possible, though it would change the
> behavior of `play-sound' slightly, so maybe a new function should be
> introduced instead.
>
> I could try to implement an `async-play-sound-internal' built-in
> function (for GNU/Linux only at first), using the available subroutines
> in "src/sound.c", though it might take me a while as I have near zero
> experience with Emacs' C code, and this will be lower level than the
> implementation in my module.

We could also change the signature from

    (play-sound SOUND)

to

    (play-sound SOUND &optional ASYNC)

or something along those lines.  Though, on the face of things, I don't
think I understand why `play-sound` should block.  Is there a good
reason for that, or is it just an implementation accident?  And are
there any important reasons to preserve its blocking behavior?

> BTW, is using threads (pthreads) acceptable?  I saw many files under
> "src/" that include "pthread.h" but I couldn't find any file where a
> thread is created (though maybe I missed something).
> If not, I'm not really sure how to implement this (I only ever did async
> programming in C using pthreads, and since I don't have any sort of
> formal background in C, I never learned or tried any other method).

Threads sound like an unnecessary complication, and I'm not sure why we
would need them.  Aren't there non-blocking calls that we could use?

Or would that require pulling in pulseaudio?

BTW, if this new feature only works on GNU/Linux at first, then that is
fine according to our guidelines.

Re: Vendoring code in a (Non?)GNU ELPA package

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I could try to implement an `async-play-sound-internal' built-in
  > function (for GNU/Linux only at first), using the available subroutines
  > in "src/sound.c", though it might take me a while as I have near zero
  > experience with Emacs' C code, and this will be lower level than the
  > implementation in my module.

This approach would be cleaner in several important ways.
Maybe other people would like to join in implementing it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Vendoring code in a (Non?)GNU ELPA package

[Daniel Semyonov]

>>>>> Stefan Kangas writes:

    > Daniel Semyonov <daniel@dsemy.com> writes:
    >> I don't see why it wouldn't be possible, though it would change
    >> the behavior of `play-sound' slightly, so maybe a new function
    >> should be introduced instead.
    >> 
    >> I could try to implement an `async-play-sound-internal' built-in
    >> function (for GNU/Linux only at first), using the available
    >> subroutines in "src/sound.c", though it might take me a while as
    >> I have near zero experience with Emacs' C code, and this will be
    >> lower level than the implementation in my module.

    > We could also change the signature from

    >     (play-sound SOUND)

    > to

    >     (play-sound SOUND &optional ASYNC)

    > or something along those lines.  Though, on the face of things, I
    > don't think I understand why `play-sound` should block.  Is there
    > a good reason for that, or is it just an implementation accident?
    > And are there any important reasons to preserve its blocking
    > behavior?

No clue honestly, I've never seen code that uses `play-audio'.
It isn't surprising though, `play-audio' in it's current state isn't
very useful apart from playing very short sounds IMO.

    >> BTW, is using threads (pthreads) acceptable?  I saw many files
    >> under "src/" that include "pthread.h" but I couldn't find any
    >> file where a thread is created (though maybe I missed something).
    >> If not, I'm not really sure how to implement this (I only ever
    >> did async programming in C using pthreads, and since I don't have
    >> any sort of formal background in C, I never learned or tried any
    >> other method).

    > Threads sound like an unnecessary complication, and I'm not sure
    > why we would need them.  Aren't there non-blocking calls that we
    > could use?

There are, but I had trouble understanding how they could actually be
used in this situation.  In any case I did some more research and I
think I understand how to implement this without threads now (at least
for ALSA).

    > Or would that require pulling in pulseaudio?

No need.

    > BTW, if this new feature only works on GNU/Linux at first, then
    > that is fine according to our guidelines.

Great.

Re: Vendoring code in a (Non?)GNU ELPA package

[Stefan Kangas]

Daniel Semyonov <daniel@dsemy.com> writes:

> No clue honestly, I've never seen code that uses `play-audio'.
> It isn't surprising though, `play-audio' in it's current state isn't
> very useful apart from playing very short sounds IMO.

Yes, but it's useful to be able to play even very short sounds without
blocking the entire Emacs session.  So it's probably okay to just change
`play-sound' to be non-blocking.

>     > Threads sound like an unnecessary complication, and I'm not sure
>     > why we would need them.  Aren't there non-blocking calls that we
>     > could use?
>
> There are, but I had trouble understanding how they could actually be
> used in this situation.  In any case I did some more research and I
> think I understand how to implement this without threads now (at least
> for ALSA).

Sounds good, thanks for working on it.

Re: Vendoring code in a (Non?)GNU ELPA package

[No Wayman]

Stefan Kangas <stefankangas@gmail.com> writes:

> Yes, but it's useful to be able to play even very short sounds 
> without
> blocking the entire Emacs session.  So it's probably okay to 
> just change
> `play-sound' to be non-blocking.

+1 for my own selfish reasons.
I've been working on elisp games, and async sound support would 
open up a lot of possibilities.

Re: Vendoring code in a (Non?)GNU ELPA package

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Is there anyone who _wants_ `play-sound' to wait for the sound to
finish?

Is there anyone who has code that would need to be changed if we
modify `play-sound' not to wait for the sound to finish?

If the change would not cause trouble for anyone, we can go ahead
and change the behavior.

We might want to define an argument value that directs `play-sound' to
wait, like `sleep-for', while playing the sound.  And another argument
value that directs it to wait but stop if there is keyboard input,
like `sit-for'.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Vendoring code in a (Non?)GNU ELPA package

[No Wayman]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider 
> ]]]
> [[[ whether defending the US Constitution against all enemies, 
> ]]]
> [[[ foreign or domestic, requires you to follow Snowden's 
> example. ]]]
>
> Is there anyone who _wants_ `play-sound' to wait for the sound 
> to
> finish?
>
> Is there anyone who has code that would need to be changed if we
> modify `play-sound' not to wait for the sound to finish?
>
> If the change would not cause trouble for anyone, we can go 
> ahead
> and change the behavior.
>
> We might want to define an argument value that directs 
> `play-sound' to
> wait, like `sleep-for', while playing the sound.  And another 
> argument
> value that directs it to wait but stop if there is keyboard 
> input,
> like `sit-for'.

How about: (defun play-sound (sound &optional async) ...

With the ASYNC parameter being:

- nil, block while playing (backward compatible).
- t, play the sound asynchronously.
- A callback function which is executed once the sound playing 
  process terminates.
  I'm not familiar enough with the play-sound API to say whether 
  or not it'd be useful to pass something back to the callback 
  function.

Re: Vendoring code in a (Non?)GNU ELPA package

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> Though, on the face of things, I don't think I understand why
> `play-sound` should block.  Is there a good reason for that, or is it
> just an implementation accident?  And are there any important reasons
> to preserve its blocking behavior?

I'm answering myself here:

Jan Djärv <jan.h.d@swipnet.se> writes:

> It would be better if all sound implementations where asynchronous and
> quittable.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3351#19