Re: Emms and old Emacsen

[Petteri Hintsanen]

Yoni Rabkin <yoni@rabkins.net> writes:

> 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.

I learned shorthands from Emacs Lisp manual.  Here is an excerpt from
Section 9.5:

  It is useful to think of shorthands as _abbreviating_ the full names
  of intended symbols.  [...]  Shorthands make Emacs Lisp’s “namespacing
  etiquette” easier to work with.  Since all symbols are stored in a
  single obarray, programmers commonly prefix each symbol name with the
  name of the library where it originates.  [...]  By properly prefixing
  symbol names, one effectively prevents clashes between similarly named
  symbols which belong to different libraries and thus do different
  things.  However, this practice commonly originates very long symbols
  names, which are inconvenient to type and read after a while.
  Shorthands solve these issues in a clean way.

That text quite clearly states that the intended purpose of shorthands
is abbreviating.  That was also my proposal: we would use shorthands to
abbreviate long prefixes like `emms-info-native-this-and-that' to
`eintat-' or something like that.

But OTOH I can also see their usefulness in the case Eli explained here:

>     """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.

I guess in those cases shorthands could be used to expand symbol names
instead of abbreviating them.  Mailing list threads are far too long
for me to dig out what was actually done.

But I think we can leave this one out for now.  Shorthands would be used
just for convenience and we can live without them.

>> - 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/
> 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.

I learned about new Bindat from that EmacsConf talk linked above.  There
is also a short mention in Emacs NEWS.28 file.  I'm not aware of any
mailing list thread about it.

The new Bindat package in Emacs 28.1 did not bring compatibility issues,
because:

- it added a new, independent mechanism, so called "bindat type
  expression" description language, and

- it obsoleted the old data layout mechanism (which we currently use in
  Emms).

Of course obsoleting does not mean that the old mechanism stopped
working: Emms works well in Emacs 28 and later.  It is the new mechanism
that would bring benefits, but it is only available in Emacs 28+.

What we perhaps could do is to add compatibility code like

  (if (< emacs-major-version 28)
      (use-old-bindat-features)
    (use-new-bindat-features)

to places where bindat features differ between Emacs versions.  There
shouldn't be too many of them.

Thanks,
Petteri