best practices for implementing Emms configuration

best practices for implementing Emms configuration

[Yoni Rabkin]

Hello all,

We are trying to make Emms (https://www.gnu.org/software/emms/) better
out of the box.

The idea is to have the user invoke "M-x emms-setup", have Emms ask some
questions (check which player binaries the user has installed, which
metadata programs are installed, where the music is located, etc.), and
have Emms generate and write the appropriate elisp configuration.

I can think of two approaches. I am wondering which, if any, would be
considered best practice:

Write the configuration to the user's ~/.emacs in the same manner as "
;; custom-set-variables was added by Custom." or ";; Added by
Package.el."  I'm not a huge fan of this option for the sole reason that
I don't appreciate packages automatically editing a file I manually
edit.

XOR

Write the configuration to ~/.emacs.d/emms/auto-config.el. Emms would
then look for that configuration file there during startup. This is
cleaner, and can have the benefit of Emms being configured without a
single line needing to be added by the user to their ~/.emacs.

I know that a bunch of packages store information in ~/.emacs.d/, just
as Emms does. But is it acceptable practice to store configuration there
too?

What I'm looking for is something along the lines of: "sure, we don't
care", or "don't do that, we don't want Emacs packages to go down that
route", or something similar.

Thank you in advance.

-- 
   "Cut your own wood and it will warm you twice"

Re: best practices for implementing Emms configuration

[Akib Azmain Turja]

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

Yoni Rabkin <yoni@rabkins.net> writes:

> Hello all,
>
> We are trying to make Emms (https://www.gnu.org/software/emms/) better
> out of the box.
>
> The idea is to have the user invoke "M-x emms-setup", have Emms ask some
> questions (check which player binaries the user has installed, which
> metadata programs are installed, where the music is located, etc.), and
> have Emms generate and write the appropriate elisp configuration.
>
> I can think of two approaches. I am wondering which, if any, would be
> considered best practice:
>
> Write the configuration to the user's ~/.emacs in the same manner as "
> ;; custom-set-variables was added by Custom." or ";; Added by
> Package.el."  I'm not a huge fan of this option for the sole reason that
> I don't appreciate packages automatically editing a file I manually
> edit.

This is better IMO.  Just use Custom.  The user can set 'custom-file'
to redirect the extra line to somewhere else.

>
> XOR
>
> Write the configuration to ~/.emacs.d/emms/auto-config.el. Emms would
> then look for that configuration file there during startup. This is
> cleaner, and can have the benefit of Emms being configured without a
> single line needing to be added by the user to their ~/.emacs.

Not bad, but is there really any need to reinvent the wheel once again?

>
> I know that a bunch of packages store information in ~/.emacs.d/, just
> as Emms does. But is it acceptable practice to store configuration there
> too?
>
> What I'm looking for is something along the lines of: "sure, we don't
> care", or "don't do that, we don't want Emacs packages to go down that
> route", or something similar.
>
> Thank you in advance.

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: best practices for implementing Emms configuration

[Yoni Rabkin]

Akib Azmain Turja <akib@disroot.org> writes:

> Yoni Rabkin <yoni@rabkins.net> writes:
>
>> Hello all,
>>
>> We are trying to make Emms (https://www.gnu.org/software/emms/) better
>> out of the box.
>>
>> The idea is to have the user invoke "M-x emms-setup", have Emms ask some
>> questions (check which player binaries the user has installed, which
>> metadata programs are installed, where the music is located, etc.), and
>> have Emms generate and write the appropriate elisp configuration.
>>
>> I can think of two approaches. I am wondering which, if any, would be
>> considered best practice:
>>
>> Write the configuration to the user's ~/.emacs in the same manner as "
>> ;; custom-set-variables was added by Custom." or ";; Added by
>> Package.el."  I'm not a huge fan of this option for the sole reason that
>> I don't appreciate packages automatically editing a file I manually
>> edit.
>
> This is better IMO.  Just use Custom.  The user can set 'custom-file'
> to redirect the extra line to somewhere else.

To be clear though: the goal isn't to present the user with one of the
customize-group interfaces; I don't use them and wouldn't force anyone
else to.

The idea is to tell the user to invoke "M-x emms-setup", have the user
answer a few y-or-n-p questions, and write the configuration based on
that.

>>
>> XOR
>>
>> Write the configuration to ~/.emacs.d/emms/auto-config.el. Emms would
>> then look for that configuration file there during startup. This is
>> cleaner, and can have the benefit of Emms being configured without a
>> single line needing to be added by the user to their ~/.emacs.
>
> Not bad, but is there really any need to reinvent the wheel once again?

As above, I consider Emacs' customize interface to be a rather square
wheel (but then, I don't like org either, so I accept that the problem
may be me.)

Thank you for the input.

-- 
   "Cut your own wood and it will warm you twice"

Re: best practices for implementing Emms configuration

[Stefan Monnier]

>> This is better IMO.  Just use Custom.  The user can set 'custom-file'
>> to redirect the extra line to somewhere else.
> To be clear though: the goal isn't to present the user with one of the
> customize-group interfaces; I don't use them and wouldn't force anyone
> else to.

To be clear, when I say "use Custom" I mean, let Custom do the saving
for you.  That doesn't imply using the Custom UI.

It just means that all the customization needs to be done by setting
vars defined with `defcustom` (and calling something like
`customize-mark-to-save` to tell Custom whats going on) and then saving
the end result with something like `custom-save-all`.

> The idea is to tell the user to invoke "M-x emms-setup", have the user
> answer a few y-or-n-p questions, and write the configuration based on
> that.

Yes, I understand you want to have your own UI for that (sounds like
something occasionally called "a wizard"; you might want to look for
other "wizards" in ELisp).


        Stefan

Re: best practices for implementing Emms configuration

[Stefan Monnier]

> Write the configuration to the user's ~/.emacs in the same manner as "
> ;; custom-set-variables was added by Custom." or ";; Added by
> Package.el."  I'm not a huge fan of this option for the sole reason that
> I don't appreciate packages automatically editing a file I manually
> edit.

AFAIK people who don't like/want Emacs to edit their manually-edited
config file (such as myself) should and do set `custom-file` accordingly.

So the better option seems very definitely to just save the config via
Custom: that's what it's for.

> Write the configuration to ~/.emacs.d/emms/auto-config.el. Emms would
> then look for that configuration file there during startup. This is
> cleaner, and can have the benefit of Emms being configured without a
> single line needing to be added by the user to their ~/.emacs.

I personally dislike it when packages do such things because it's never
completely clear how it interacts with the settings I put into my own
manually-edited init file.

Custom suffers from the same problems, of course, but once you've
learned how it works, then this carries over to all the packages
that use it.

> I know that a bunch of packages store information in ~/.emacs.d/, just
> as Emms does.  But is it acceptable practice to store configuration
> there too?

There's no law against it.  But as a user, I'd vote against it.


        Stefan

Re: best practices for implementing Emms configuration

[Björn Bidar]

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

>> Write the configuration to the user's ~/.emacs in the same manner as "
>> ;; custom-set-variables was added by Custom." or ";; Added by
>> Package.el."  I'm not a huge fan of this option for the sole reason that
>> I don't appreciate packages automatically editing a file I manually
>> edit.
>
> AFAIK people who don't like/want Emacs to edit their manually-edited
> config file (such as myself) should and do set `custom-file` accordingly.
>
> So the better option seems very definitely to just save the config via
> Custom: that's what it's for.

I agree however those people that don't like Emacs to edit their
configuration file might also setup emms manually.

>> Write the configuration to ~/.emacs.d/emms/auto-config.el. Emms would
>> then look for that configuration file there during startup. This is
>> cleaner, and can have the benefit of Emms being configured without a
>> single line needing to be added by the user to their ~/.emacs.
>
> I personally dislike it when packages do such things because it's never
> completely clear how it interacts with the settings I put into my own
> manually-edited init file.
>
> Custom suffers from the same problems, of course, but once you've
> learned how it works, then this carries over to all the packages
> that use it.

If the package writes the file with setopt the behavior should be the
same as using custom, however no released version support that so far.

>> I know that a bunch of packages store information in ~/.emacs.d/, just
>> as Emms does.  But is it acceptable practice to store configuration
>> there too?
>
> There's no law against it.  But as a user, I'd vote against it.

Sometimes it makes sense, several packages to it e.g. by proving an
org-mode file setup some configuration value.

As long as the location of the file can be configured it does sound fine
to me, packages such as no-littering exist for a reason.

Br,

Björn

Re: best practices for implementing Emms configuration

[Stefan Monnier]

> Sometimes it makes sense, several packages to it e.g. by proving an
> org-mode file setup some configuration value.
>
> As long as the location of the file can be configured it does sound fine
> to me, packages such as no-littering exist for a reason.

Indeed, another advantage of using Custom is that there are already
various tools that let you control where things go.


        Stefan

Re: best practices for implementing Emms configuration

[Yoni Rabkin]

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

>> Write the configuration to the user's ~/.emacs in the same manner as "
>> ;; custom-set-variables was added by Custom." or ";; Added by
>> Package.el."  I'm not a huge fan of this option for the sole reason that
>> I don't appreciate packages automatically editing a file I manually
>> edit.
>
> AFAIK people who don't like/want Emacs to edit their manually-edited
> config file (such as myself) should and do set `custom-file` accordingly.

Over the years, the people I've helped set up Emms have almost always
been people who don't know elisp at all (makes sense when you think
about it). I think that the people who know about, and use `custom-file'
are also the people who don't need help setting up Emms.

However, that doesn't mean that you are wrong.

> So the better option seems very definitely to just save the config via
> Custom: that's what it's for.

I'll look at cus-edit.el to see how I can leverage Custom to do the
saving and loading for me outside of the customize interface. I don't
use it and am ignorant of it.

>> Write the configuration to ~/.emacs.d/emms/auto-config.el. Emms would
>> then look for that configuration file there during startup. This is
>> cleaner, and can have the benefit of Emms being configured without a
>> single line needing to be added by the user to their ~/.emacs.
>
> I personally dislike it when packages do such things because it's never
> completely clear how it interacts with the settings I put into my own
> manually-edited init file.
>
> Custom suffers from the same problems, of course, but once you've
> learned how it works, then this carries over to all the packages
> that use it.
>
>> I know that a bunch of packages store information in ~/.emacs.d/, just
>> as Emms does.  But is it acceptable practice to store configuration
>> there too?
>
> There's no law against it.  But as a user, I'd vote against it.

That vote is important. Thank you for taking the time and effort to cast
it.

-- 
   "Cut your own wood and it will warm you twice"

Re: best practices for implementing Emms configuration

[Visuwesh]

[சனி டிசம்பர் 10, 2022] Yoni Rabkin wrote:

> I'll look at cus-edit.el to see how I can leverage Custom to do the
> saving and loading for me outside of the customize interface. I don't
> use it and am ignorant of it.

For saving, I think you are looking for custom-save-variables (it is
used by warnings.el to suppress a specific type of warning).

Re: best practices for implementing Emms configuration

[Visuwesh]

[சனி டிசம்பர் 10, 2022] Visuwesh wrote:

> [சனி டிசம்பர் 10, 2022] Yoni Rabkin wrote:
>
>> I'll look at cus-edit.el to see how I can leverage Custom to do the
>> saving and loading for me outside of the customize interface. I don't
>> use it and am ignorant of it.
>
> For saving, I think you are looking for custom-save-variables (it is
                                           ^^^^^^^^^^^^^^^^^^^^^^
Typo: I meant customize-save-variable.  Sorry for the noise.                                           
> used by warnings.el to suppress a specific type of warning).

RE: [External] : Re: best practices for implementing Emms configuration

[Drew Adams]

> > AFAIK people who don't like/want Emacs to edit their manually-edited
> > config file (such as myself) should and do set `custom-file` accordingly.
> 
> Over the years, the people I've helped set up Emms have almost always
> been people who don't know elisp at all (makes sense when you think
> about it). I think that the people who know about, and use `custom-file'
> are also the people who don't need help setting up Emms.
> However, that doesn't mean that you are wrong.

There were a few long threads about changing to have
use of `custom-file' be the default behavior.  See, e.g.,

https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00484.html

https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00772.html

> > So the better option seems very definitely to just save the config via
> > Custom: that's what it's for.
> 
> I'll look at cus-edit.el to see how I can leverage Custom to do the
> saving and loading for me outside of the customize interface. I don't
> use it and am ignorant of it.

This might also be of interest or help:

https://www.emacswiki.org/emacs/CustomizingAndSaving

Re: best practices for implementing Emms configuration

[tomas]

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

On Sat, Dec 10, 2022 at 08:54:02AM -0500, Yoni Rabkin wrote:

[...]

> Over the years, the people I've helped set up Emms have almost always
> been people who don't know elisp at all (makes sense when you think
> about it). I think that the people who know about, and use `custom-file'
> are also the people who don't need help setting up Emms.

And then there are the in-betweens, who do look at what customize has
written to extend their Emacs knowledge. Perhaps not a priority, but
it'd be a plus if there is a ramp there...

cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: best practices for implementing Emms configuration

[Björn Bidar]

Yoni Rabkin <yoni@rabkins.net> writes:

> Hello all,
>
> We are trying to make Emms (https://www.gnu.org/software/emms/) better
> out of the box.
>
> The idea is to have the user invoke "M-x emms-setup", have Emms ask some
> questions (check which player binaries the user has installed, which
> metadata programs are installed, where the music is located, etc.), and
> have Emms generate and write the appropriate elisp configuration.
> I can think of two approaches. I am wondering which, if any, would be
> considered best practice:

I was in that situation a month ago, I want to add what would make this
easier.

Emms is quite flexible which makes the initial setup a little more
complicated.

For example if I want to setup as an mpd client I would want some
defaults that make sense and that can be changed if needed.

I think would make more sense to have defaults for common use cases such
as these then writing a configuration, simplifying the configuration
rather than making it easier to configure.

For example Circe provides defaults for common IRC server's than can be
adjusted individually.

Emms could provide similar defaults.

Br,

Björn

Re: best practices for implementing Emms configuration

[Yoni Rabkin]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Yoni Rabkin <yoni@rabkins.net> writes:
>
>> Hello all,
>>
>> We are trying to make Emms (https://www.gnu.org/software/emms/) better
>> out of the box.
>>
>> The idea is to have the user invoke "M-x emms-setup", have Emms ask some
>> questions (check which player binaries the user has installed, which
>> metadata programs are installed, where the music is located, etc.), and
>> have Emms generate and write the appropriate elisp configuration.
>> I can think of two approaches. I am wondering which, if any, would be
>> considered best practice:
>
> I was in that situation a month ago, I want to add what would make this
> easier.
>
> Emms is quite flexible which makes the initial setup a little more
> complicated.
>
> For example if I want to setup as an mpd client I would want some
> defaults that make sense and that can be changed if needed.
>
> I think would make more sense to have defaults for common use cases such
> as these then writing a configuration, simplifying the configuration
> rather than making it easier to configure.
>
> For example Circe provides defaults for common IRC server's than can be
> adjusted individually.
>
> Emms could provide similar defaults.

No reason why mpd configuration can't be a part of the y-or-n-p type of
easy configuration I'm thinking about.

But this thread should be picked up in emms-help@gnu.org.

-- 
   "Cut your own wood and it will warm you twice"

Re: best practices for implementing Emms configuration

[Björn Bidar]

Yoni Rabkin <yoni@rabkins.net> writes:

>> I think would make more sense to have defaults for common use cases such
>> as these then writing a configuration, simplifying the configuration
>> rather than making it easier to configure.
>>
>> For example Circe provides defaults for common IRC server's than can be
>> adjusted individually.
>>
>> Emms could provide similar defaults.
>
> No reason why mpd configuration can't be a part of the y-or-n-p type of
> easy configuration I'm thinking about.

Why focus on that "wizard" or dialog when the base emms configuration
could use some simplification?

The two main ways of configuration in Emacs are either manual
configuration with setq or setopt preferably with use-package (Emacs
29+) or the custom interface.

The configuration should be simple enough that selecting a profile with
either should be good enough.

> But this thread should be picked up in emms-help@gnu.org.

Posting to emms-help would be good then, there wasn't a post in that
list.


Br,

Björn