Re: Proposal: Forwards-Compatibility Library for Emacs

[Arthur Miller]

Philip Kaludercic <philipk@posteo.net> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> By its very nature it is an intrusive package, as it defines functions,
>>> macros and advice outside of the "namespace", but I don't see any way
>>> around that if transparent compatibility is to be provided (anything
>>> else would just replicate dash, s, f, ...).
>>
>> I think this uncleanliness is a bit risky.  Better put the definitions
>> in their own namespace.
>
> Just to be on the same page, what exactly is the risk? I understand the
> issue on a gut-level, it goes against convention and recommendations,
> but the idea is that this package would do that, so that others don't
> have to.

It is not on a "gut-level" :). I was thinking about same, and wrote you a longer
answer I just sent. There were no replys when I started, I see now several
people replied.

There can be two functions defineing slightly different behaviour in different
version, there can also be 3rd party packages expecting certain behaviour, and
there is no need to advise too much, say windowing code if application need to
just check is directory-empty-p.

> Other than that, all the functions and macros are defined first using a
> "compat--" prefix, then perhaps are aliased to a symbol without a
> prefix.
>
>>  I don't think "transparent compatibility" is
>> worth the trouble here, and I don't think `s`, `f`, ... solve the
>> same problem.
>
> Of course not, s, f, and the rest of the dash-adjacent ecosystem have
> different intentions, it is only as a side effect that they provide more
> functionality than older versions of Emacs do.

They define different API from Emacs, more used by people comming from different
Lisp(s), clojure if I am correct?

> Most of the examples I provide in the file I attached above are simple
> or slower reimplementations that make programming more convenient, but
> where "transparent compatibility" becomes interesting is when providing
> noop compatibility that allows package developers to make use of newer
> features that are not backwards compatible, such as the additional
> interactive argument. The infrastructure doesn't exist to handle this
> information, but package developers will hold back from using these new
> features because they don't want to abandon all users that aren't on
> 28.1.
>
> I don't see how examples like these could be handled without transparent
> compatibility.

When it comes to providing newly intoduced functionality, there shouldn't be a
problem, it should always be possible to just add a function, like
dired-empty-p:


(when (version< emacs-version "28")
  (defun directory-empty-p (file-name)
    "Check if a directory contains any other files then dot-files"
    (when (file-directory-p file-name)
      (null (directory-files file-name nil
                             directory-files-no-dot-files-regexp t)))))

You don't even need to advise directory-files for that.

But for already existing functions that might lead to problems. I think so at
least. In the answer I sent you, I was thinking of buffer-local function
variables instead of advices which are global.