Re: Proposal: Forwards-Compatibility Library for Emacs

[Philip Kaludercic]

Arthur Miller <arthur.miller@live.com> writes:

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

Yes, I think cases where different versions switch back and forth are
hard to make compatible, so they should be left out of any attempt like
this.

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

>From what I know they are inspired by Clojure and try to provide better
compatibility with the various macros that dash provides (such as
threading), but I am not sure if they are direct translations from
Clojure's standard library.

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

That wouldn't even be advised. My definition

    (compat-defun directory-empty-p (dir)
      "Return t if DIR names an existing directory containing no other files.
    Return nil if DIR does not name a directory, or if there was
    trouble determining whether DIR is a directory or empty.

    Symbolic links to directories count as directories.
    See `file-symlink-p' to distinguish symlinks."
      :version "28.1"
      (and (file-directory-p dir)
           (null (directory-files dir nil directory-files-no-dot-files-regexp 
t))))

is expanded to

    (progn
      (declare-function compat--directory-empty-p "compat"
                        '(dir))
      (let nil
        (defun compat--directory-empty-p
            (dir)
          "[Compatibility function for `directory-empty-p', defined in Emacs 
28.1]\n\nReturn t if DIR names an existing directory containing no other 
files.\nReturn nil if DIR does not name a directory, or if there was\ntrouble 
determining whether DIR is a directory or empty.\n\nSymbolic links to 
directories count as directories.\nSee `file-symlink-p' to distinguish 
symlinks." nil
          (and
           (file-directory-p dir)
           (null
            (directory-files dir nil directory-files-no-dot-files-regexp t))))
        (compat-ignore
         (defalias 'directory-empty-p #'compat--directory-empty-p))))

which is more or less the same as what you do (setting aside the fact
that on my system, the installation via defalias is ignored).

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

-- 
        Philip Kaludercic