[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: Forwards-Compatibility Library for Emacs
From: |
Arthur Miller |
Subject: |
Re: Proposal: Forwards-Compatibility Library for Emacs |
Date: |
Tue, 21 Sep 2021 16:18:25 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Philip Kaludercic <philipk@posteo.net> writes:
> 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).
Ah, ok, sorry I wasn't running any code; just so the advised directory-files and
that directory-empty-p used one with the counter. My bad.
>> 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.
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
Re: Proposal: Forwards-Compatibility Library for Emacs, Philip Kaludercic, 2021/09/22