[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why EMMS is not in GNU ELPA?
From: |
Yoni Rabkin |
Subject: |
Re: Why EMMS is not in GNU ELPA? |
Date: |
Fri, 24 Apr 2020 16:14:27 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) |
Fran Burstall <address@hidden> writes:
> 4. Maybe an alternative to emms-print-metadata would be more
> attractive. It seems that there are a zillion wrappers to taglib out
> there. One example is https://pypi.org/project/pytaglib/ which comes
> with a tag reader pyprinttags which (a) works and (b) was easy to
> install: pip install pytaglib (assuming that libtag is already
> present on the system). All that would need to be done to use this
> in emms would be to get emms-info-libtag to parse the output.
I've also written to emacs-devel asking them if they have any input on
how we can streamline access to taglib for Emms.
Unless the people from emacs-devel come up with some brilliant idea we
should try instead, we should try pytaglib on people after releasing 5.4
(first of May).
> ---Fran
>
>
> On Fri, 10 Apr 2020 at 19:47, Yoni Rabkin <address@hidden> wrote:
>
> Bruno Félix Rezende Ribeiro <address@hidden> writes:
>
> > Yoni Rabkin <address@hidden> writes:
> >
> >> I've personally never used ELPA and don't understand the point
> of it.
> >
> > Why do you say that you “don't understand the point of it”?
>
> ...because I don't (I'm usure of what you are asking here
> though.)
>
> However, I'll try to get Emms into ELPA if that is what people
> want. I'm
> maintaining Emms on behalf of GNU; not just for my own personal
> benefit.
>
>
> >> One issue would be to figure out how to ship the src/
> directory with
> >> the non-elisp parts and how to get those compiled.
> >
> > How these work? I presume they are compiled and used as
> sub-processes.
> > Would not the new modules[1] support be more appropriate here?
> Indeed,
> > we’d have to figure out how those architecture-dependent parts
> are
> > supposed to get distributed. I think packages that use them
> have a
> > compilation script written in Lisp that is triggered on-demand
> in the
> > first use.
> >
> >
> > Footnotes:
> > [1] (info "(elisp) Writing Dynamic Modules")
>
> There are a few ways of doing this.
>
> Ideally, I would want to get rid of emms-print-metadata in favor
> of
> calling:
>
> * a library linked to emacs when it was compiled, or
> dynamically
> called by emacs
>
> * a command line tool that can be easily installed on an
> endorsed
> gnu/linux distribution
>
> The current situation of needing to compile a bespoke piece of
> software
> for taglib is suboptimal and confuses many people (based on
> questions
> I've received over the years). Moreover, "automating" the
> compilation
> won't work unless you also have a way of automating the
> installation of
> compilation tools onto the machine as well.
>
> It's still better than bongo's method of relying on filenames,
> but that
> isn't saying a whole lot.
>
> Perhaps the "modules" method is good, but depending on how new it
> is, it
> may leave behind everyone who wants to enjoy Emms but is stuck on
> an
> older emacs. I'll have to look into it.
>
> ...it seems like we have a worthy target for the 6.x release for
> Emms.
>
> --
> "Cut your own wood and it will warm you twice"
>
>
>
>
--
"Cut your own wood and it will warm you twice"