[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: Forwards-Compatibility Library for Emacs
From: |
Philip Kaludercic |
Subject: |
Re: Proposal: Forwards-Compatibility Library for Emacs |
Date: |
Tue, 21 Sep 2021 13:54:03 +0000 |
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
Re: Proposal: Forwards-Compatibility Library for Emacs, Philip Kaludercic, 2021/09/21
Re: Proposal: Forwards-Compatibility Library for Emacs, Lars Ingebrigtsen, 2021/09/21
Re: Proposal: Forwards-Compatibility Library for Emacs, Lars Ingebrigtsen, 2021/09/21
Re: Proposal: Forwards-Compatibility Library for Emacs, João Távora, 2021/09/21
Re: Proposal: Forwards-Compatibility Library for Emacs, Stefan Monnier, 2021/09/21
Re: Proposal: Forwards-Compatibility Library for Emacs, Philip Kaludercic, 2021/09/21
Re: Proposal: Forwards-Compatibility Library for Emacs, Stefan Monnier, 2021/09/21