Re: Emms and old Emacsen

Petteri Hintsanen <[email protected]> writes:

> Hello Yoni,
>
> There are two new features in Emacs 28 pertinent to emms-info-native:
>
> - Shorthands: we could use these to shorten long symbols, e.g.
>   `emms-info-native-mp3-FOO' to `einm-FOO'.  It would make the code more
>   readable and easier to type.

My understanding of shorthands was that they were added as a way for
emacs to incorporate some strangely named libraries (s.el), and not as a
way to name libraries strangely. Shorthands is a way of renaming poorly
named libraries in order to make them behave in the larger emacs
namespace. Therefore, I don't think they should be used to solve the
readability problem.

Here is what Eli had to say about shorthands back in the day (30 Oct
2022):

    """Before everyone starts presenting here that we made some
     nonsensical decision when we added shorthands, let me remind us
     that it was added to allow us to use packages like "s"
     (https://github.com/magnars/s.el), "f"
     (https://github.com/rejeep/f.el) and other similar ones, which use
     "problematic" function names.  We wanted to be able to use packages
     which have dependencies of those, while at the same time providing
     reasonably-named aliases for them.  (Gerd wasn't around back then,
     so he is excused, but the rest of us were here, so please let's not
     pretend those discussions never happened.)"""

Shorthands, and the larger question of packages in elisp, are a sticky
subject for sure. I don't think that the discussion is going away
anytime soon.

To my mind, one solution would be a package which displays text
"emms-info-native-mp3-FOO" as "einm-FOO" but leaves the underlying
string untouched. This way the programmer would have a tidier screen,
and the reader/compiler would be none the wiser. In other words,
something implemented at the level of the display and not the
reader. Does something like that already exist? In any case, that isn't
the problem shorthands was designed to solve.

> - Reworked bindat package, which is cleaner and more amenable to byte
>   compilation than earlier versions.  There is a talk in EmacsConf 2021
>   about this: https://emacsconf.org/2021/talks/bindat/
>
> I think these could be beneficial, especially the new bindat package.
> But they would work only with Emacs 28 and newer, so backward
> compatibility with older Emacsen would be broken.  What do you think
> about this?

This sounds very useful, but I can't find anything about this change to
bindat. Do you have a link to the emacs-devel thread or similar? I
assume there is a list of compatibility issues for developers to check
out.

> For bindat we could perhaps hack some compatibility layer, but for
> shorthands I don't think it is possible because it interacts with the
> Lisp reader.
>
>
> Thanks,
> Petteri
>

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