Adding package "Loopy" to Non-GNU Devel?

Adding package "Loopy" to Non-GNU Devel?

[Okamsn]

[-- Attachment #1: Type: text/plain, Size: 4336 bytes --]

Hello,

I am the author of the package "loopy", which provides macros similar to
~cl-loop~ and Common Lisp's =iterate=.  It is located here:

https://github.com/okamsn/loopy

For those not willing to browse GitHub, I have copied the main points 
from the
README.org file. I have attached the README and the Org documentation file.

Visually, Loopy differs by using parentheses instead of keywords like 
~cl-loop~.
For example,

#+begin_src emacs-lisp
   ;; A use of `cl-loop':
   (cl-loop for i from 1 to 10
            if (cl-evenp i) collect i into evens
            else collect i into odds
            end ; This `end' keyword is optional here.
            finally return (list odds evens))

   ;; How it could be done using `loopy':
   (loopy (numbers i :from 1 :to 10)
          (if (cl-evenp i)
              (collect evens i)
            (collect odds i))
          (finally-return odds evens))
#+end_src


Non-visually, these are I think the main improvements:

- Better destructuring than =cl-lib=, in that it can destructure arrays and
   supports destructuring in accumulations (like ~collect~) as well as in
   iteration.  I recently added a Pcase pattern for this outside of the 
~loopy~ macro.

   #+begin_src emacs-lisp
     ;; => (8 10 12 14 16 18)
     (loopy (list list-elem '(([1 2 3] [4 5 6])
                              ([7 8 9] [10 11 12])))
            (sum ([sum1 sum2 sum3] [sum4 sum5 sum6])
                 list-elem)
            (finally-return sum1 sum2 sum3 sum4 sum5 sum6))
   #+end_src

- Better control over accumulations, in that one can declare that an
   accumulation is "optimized" (for example, using the ~push~-~nreverse~ 
pattern
   instead of the ~append~-~list~ pattern) for named variables, allowing to
   efficiently accumulate for multiple values and to declare beforehand 
whether
   adding to the front or the end of the list should be preferred.

   The below expands into two instances of the ~push~-~nreverse~ pattern:

   #+begin_src emacs-lisp
     ;; Separate the elements of sub-list:
     ;; => ((1 3) (2 4))
     (loopy (accum-opt elem1 elem2)
            (list i '((1 2) (3 4)))
            (collect (elem1 elem2) i)
            (finally-return elem1 elem2))
   #+end_src

- A way to embed the looping constructs in arbitrary code like in Common 
Lisp's
   Iterate:

   #+begin_src emacs-lisp
     (require 'loopy-iter)

     ;; Things to note:
     ;; => ((-9 -8 -7 -6 -5 -4 -3 -2 -1)
     ;;     (0)
     ;;     (1 2 3 4 5 6 7 8 9 10 11))
     (loopy-iter (accum-opt positives negatives zeroes)
                 (numbering i :from -10 :to 10)
                 ;; Normal `let' and `pcase', not Loopy constructs:
                 (let ((var (1+ i)))
                   (pcase var
                     ((pred cl-plusp)  (collecting positives var))
                     ((pred cl-minusp) (collecting negatives var))
                     ((pred zerop)     (collecting zeroes var))))
                 (finally-return negatives zeroes positives))
   #+end_src

- An =at= feature to manipulate containing loops, such as moving to the next
   iteration step or accumulating into a variable:

   #+begin_src emacs-lisp
     (loopy outer
            (array i [(1 2) (3 4) (5 6)])
            (loopy (with (sum (apply #'+ i)))
                   (list j i)
                   (at outer (collect (+ sum j)))))
   #+end_src

- It should be easy to add new looping features.  The documentation has 
examples of this.


The package and an extension package (to use Dash's destructuring instead of
that of Loopy, Pcase, or Seq) has been available on MELPA for a few 
years now.
I am asking about Non-GNU Devel instead of just the normal Non-GNU archive
because I am still making breaking changes to the package as I reduce
duplication and improve on the ideas, but those changes are coming less
frequently now.

Is it possible to add this package and the extension package to the archive?

I keep the extension package in the same GitHub repo as the main package for
testing purposes.  The Dash functionality was requested by a user, but 
Dash is
not used by the rest of the package.  Because of that, I put the Dash
functionality in a small separate package.

Thank you.

[-- Attachment #2: README.org --]
[-- Type: application/vnd.lotus-organizer, Size: 13961 bytes --]

[-- Attachment #3: loopy-doc.org --]
[-- Type: application/vnd.lotus-organizer, Size: 199806 bytes --]

Re: Adding package "Loopy" to Non-GNU Devel?

[Philip Kaludercic]

Okamsn <okamsn@protonmail.com> writes:

> Hello,
>
> I am the author of the package "loopy", which provides macros similar to
> ~cl-loop~ and Common Lisp's =iterate=.  It is located here:
>
> https://github.com/okamsn/loopy

(Obligatory question here, as to why we don't also name the package
iterate?)

> For those not willing to browse GitHub, I have copied the main points 
> from the
> README.org file. I have attached the README and the Org documentation file.
>
> Visually, Loopy differs by using parentheses instead of keywords like 
> ~cl-loop~.
> For example,
>
> #+begin_src emacs-lisp
>    ;; A use of `cl-loop':
>    (cl-loop for i from 1 to 10
>             if (cl-evenp i) collect i into evens
>             else collect i into odds
>             end ; This `end' keyword is optional here.
>             finally return (list odds evens))
>
>    ;; How it could be done using `loopy':
>    (loopy (numbers i :from 1 :to 10)
>           (if (cl-evenp i)
>               (collect evens i)
>             (collect odds i))
>           (finally-return odds evens))
> #+end_src
>
> Non-visually, these are I think the main improvements:
>
> - Better destructuring than =cl-lib=, in that it can destructure arrays and
>    supports destructuring in accumulations (like ~collect~) as well as in
>    iteration.  I recently added a Pcase pattern for this outside of the 
> ~loopy~ macro.
>
>    #+begin_src emacs-lisp
>      ;; => (8 10 12 14 16 18)
>      (loopy (list list-elem '(([1 2 3] [4 5 6])
>                               ([7 8 9] [10 11 12])))
>             (sum ([sum1 sum2 sum3] [sum4 sum5 sum6])
>                  list-elem)
>             (finally-return sum1 sum2 sum3 sum4 sum5 sum6))
>    #+end_src

Where is pcase being used here?

>
> - Better control over accumulations, in that one can declare that an
>    accumulation is "optimized" (for example, using the ~push~-~nreverse~ 
> pattern
>    instead of the ~append~-~list~ pattern) for named variables, allowing to
>    efficiently accumulate for multiple values and to declare beforehand 
> whether
>    adding to the front or the end of the list should be preferred.
>
>    The below expands into two instances of the ~push~-~nreverse~ pattern:
>
>    #+begin_src emacs-lisp
>      ;; Separate the elements of sub-list:
>      ;; => ((1 3) (2 4))
>      (loopy (accum-opt elem1 elem2)
>             (list i '((1 2) (3 4)))
>             (collect (elem1 elem2) i)
>             (finally-return elem1 elem2))
>    #+end_src
>
>
> - A way to embed the looping constructs in arbitrary code like in Common 
> Lisp's
>    Iterate:
>
>    #+begin_src emacs-lisp
>      (require 'loopy-iter)
>
>      ;; Things to note:
>      ;; => ((-9 -8 -7 -6 -5 -4 -3 -2 -1)
>      ;;     (0)
>      ;;     (1 2 3 4 5 6 7 8 9 10 11))
>      (loopy-iter (accum-opt positives negatives zeroes)
>                  (numbering i :from -10 :to 10)
>                  ;; Normal `let' and `pcase', not Loopy constructs:
>                  (let ((var (1+ i)))
>                    (pcase var
>                      ((pred cl-plusp)  (collecting positives var))
>                      ((pred cl-minusp) (collecting negatives var))
>                      ((pred zerop)     (collecting zeroes var))))
>                  (finally-return negatives zeroes positives))
>    #+end_src
>
>
> - An =at= feature to manipulate containing loops, such as moving to the next
>    iteration step or accumulating into a variable:
>
>    #+begin_src emacs-lisp
>      (loopy outer
>             (array i [(1 2) (3 4) (5 6)])
>             (loopy (with (sum (apply #'+ i)))
>                    (list j i)
>                    (at outer (collect (+ sum j)))))
>    #+end_src
>
> - It should be easy to add new looping features.  The documentation has 
> examples of this.
>
>
> The package and an extension package (to use Dash's destructuring instead of
> that of Loopy, Pcase, or Seq) has been available on MELPA for a few 
> years now.
> I am asking about Non-GNU Devel instead of just the normal Non-GNU archive
> because I am still making breaking changes to the package as I reduce
> duplication and improve on the ideas, but those changes are coming less
> frequently now.

If you want to prevent a package from being released, you just need to
make sure keep some negative version suffix like -rc in the version tag.

But in general, I wouldn't advise regarding NonGNU ELPA devel as a
proper package archive for users, but more as a preview for developers
to see how the ELPA build server is processing your package.  Or that is
at least my take.

> Is it possible to add this package and the extension package to the archive?
>
> I keep the extension package in the same GitHub repo as the main package for
> testing purposes.  The Dash functionality was requested by a user, but 
> Dash is
> not used by the rest of the package.  Because of that, I put the Dash
> functionality in a small separate package.

You are talking about the loopy-dash.el file in the same branch, right?
If possible, it would be better if you could at least maintain it in a
separate branch.

> Thank you.

Re: Adding package "Loopy" to Non-GNU Devel?

[Okamsn]

Philip Kaludercic wrote:
> Okamsn <okamsn@protonmail.com> writes:
> 
>> Hello,
>>
>> I am the author of the package "loopy", which provides macros similar to
>> ~cl-loop~ and Common Lisp's =iterate=.  It is located here:
>>
>> https://github.com/okamsn/loopy
> 
> (Obligatory question here, as to why we don't also name the package
> iterate?)

To be clear, Loopy isn't a copy of Iterate. I originally set out to make 
a more featureful version of something like `cl-loop` and learned about 
Iterate the first time I asked that Loopy be added to MELPA 
(https://github.com/melpa/melpa/pull/7253). Note that Loopy is much 
improved since that discussion.

The macro for embedding the loop constructs in arbitrary code (see my 
previous e-mail for an example) I called `loopy-iter`, because I learned 
about the idea from Iterate (and because naming is hard), but it was 
written a few months after that MELPA discussion.

>> - Better destructuring than =cl-lib=, in that it can destructure arrays and
>>     supports destructuring in accumulations (like ~collect~) as well as in
>>     iteration.  I recently added a Pcase pattern for this outside of the
>> ~loopy~ macro.
>>
>>     #+begin_src emacs-lisp
>>       ;; => (8 10 12 14 16 18)
>>       (loopy (list list-elem '(([1 2 3] [4 5 6])
>>                                ([7 8 9] [10 11 12])))
>>              (sum ([sum1 sum2 sum3] [sum4 sum5 sum6])
>>                   list-elem)
>>              (finally-return sum1 sum2 sum3 sum4 sum5 sum6))
>>     #+end_src
> 
> Where is pcase being used here?

It is being use underneath, via `pcase-compile-patterns` on modern 
Emacs.  Previously, I was using custom functions to destructure the 
value. I am currently making an effort to simplify the package by 
removing the (then- or now-) re-invented wheels.

The Pcase pattern can be used directly in `pcase`:

#+begin_src emacs-lisp
   ;; => (1 2 3
   ;;     4 5 t
   ;;     (:k1 111 :k2 222)
   ;;     111 t
   ;;     222
   ;;     111
   ;;     333 nil
   ;;     4444 5555)
   (pcase (list 1 2 3 4 5 :k1 111 :k2 222)
     ((loopy ( a b c
               &optional
               d
               (e nil e-supplied)
               &rest
               r
               &key
               ((:k1 k1) nil k1-supplied)
               k2
               &map
               (:k1 map1)
               [:k3 map3 333 map3-supplied]
               &aux
               [x1 4444] (x2 5555)))
      (list a b c
            d
            e e-supplied
            r
            k1 k1-supplied
            k2
            map1
            map3 map3-supplied
            x1 x2)))
#+end_src

See the file `loopy-destructure.el` for its current implementation.

>> I am asking about Non-GNU Devel instead of just the normal Non-GNU archive
>> because I am still making breaking changes to the package as I reduce
>> duplication and improve on the ideas, but those changes are coming less
>> frequently now.
> 
> If you want to prevent a package from being released, you just need to
> make sure keep some negative version suffix like -rc in the version tag.


Would the workflow be to commit a change to increase the stable-version 
number and then to commit another change to change the version number to 
one with an "-rc" suffix to continue development?

> But in general, I wouldn't advise regarding NonGNU ELPA devel as a
> proper package archive for users, but more as a preview for developers
> to see how the ELPA build server is processing your package.  Or that is
> at least my take.

OK. Thank you for the explanation.

>> Is it possible to add this package and the extension package to the archive?
>>
>> I keep the extension package in the same GitHub repo as the main package for
>> testing purposes.  The Dash functionality was requested by a user, but
>> Dash is
>> not used by the rest of the package.  Because of that, I put the Dash
>> functionality in a small separate package.
> 
> You are talking about the loopy-dash.el file in the same branch, right?

Yes.

> If possible, it would be better if you could at least maintain it in a
> separate branch.

If I added the file "loopy-dash.el" to an ".elpaignore" file in the main 
branch and used GitHub Actions to push any changes from the main branch 
to another branch containing the file "loopy-dash.el", would that be 
acceptable?

Re: Adding package "Loopy" to Non-GNU Devel?

[Okamsn]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

Okamsn wrote:
> Philip Kaludercic wrote:
>> Okamsn <okamsn@protonmail.com> writes:
>>> I keep the extension package in the same GitHub repo as the main package for
>>> testing purposes.  The Dash functionality was requested by a user, but
>>> Dash is
>>> not used by the rest of the package.  Because of that, I put the Dash
>>> functionality in a small separate package.
>>
>> You are talking about the loopy-dash.el file in the same branch, right?
> 
> Yes.
> 
>> If possible, it would be better if you could at least maintain it in a
>> separate branch.
> 
> If I added the file "loopy-dash.el" to an ".elpaignore" file in the main
> branch and used GitHub Actions to push any changes from the main branch
> to another branch containing the file "loopy-dash.el", would that be
> acceptable?
> 

Hello,

I figured out how to make GitHub automatically copy changes of the file 
to another branch when the master branch changes, and have listed the 
file `loopy-dash.el` in the `.elpaignore` file on the master branch.

I successfully installed the packages locally using the instructions in 
the ELPA readme.

I have attached a patch file. Are there any other changes that you would 
like made?

Thank you.

[-- Attachment #2: 0001-Add-Loopy-and-Loopy-Dash-to-Non-GNU-ELPA.patch --]
[-- Type: text/x-patch, Size: 1113 bytes --]

From 9401cb85dab45dc292df3ccbd98580523e5249ef Mon Sep 17 00:00:00 2001
From: Earl Hyatt <okamsn@protonmail.com>
Date: Sun, 25 Feb 2024 12:12:56 -0500
Subject: [PATCH] Add Loopy and Loopy Dash to Non-GNU ELPA.

* elpa-packages (loopy): New package
* elpa-packages (loopy-dash): New package
---
 elpa-packages | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 6c772af..eb65119 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -412,6 +412,15 @@
  (kotlin-mode		:url "https://github.com/Emacs-Kotlin-Mode-Maintainers/kotlin-mode"
   :ignored-files ("doc" "test" "Cask" "Makefile"))
 
+ (loopy                 :url "https://github.com/okamsn/loopy"
+                        :news "CHANGELOG.md"
+                        :main-file "loopy.el"
+                        :readme "README.org"
+                        :doc "doc/loopy.texi")
+
+ (loopy-dash            :url "https://github.com/okamsn/loopy"
+                        :branch "loopy-dash-only")
+
  (lorem-ipsum           :url "https://github.com/jschaf/emacs-lorem-ipsum"
   :readme "README.md")
 
-- 
2.34.1

Re: Adding package "Loopy" to Non-GNU Devel?

[Philip Kaludercic]

Okamsn <okamsn@protonmail.com> writes:

> Okamsn wrote:
>> Philip Kaludercic wrote:
>>> Okamsn <okamsn@protonmail.com> writes:
>>>> I keep the extension package in the same GitHub repo as the main package for
>>>> testing purposes.  The Dash functionality was requested by a user, but
>>>> Dash is
>>>> not used by the rest of the package.  Because of that, I put the Dash
>>>> functionality in a small separate package.
>>>
>>> You are talking about the loopy-dash.el file in the same branch, right?
>> 
>> Yes.
>> 
>>> If possible, it would be better if you could at least maintain it in a
>>> separate branch.
>> 
>> If I added the file "loopy-dash.el" to an ".elpaignore" file in the main
>> branch and used GitHub Actions to push any changes from the main branch
>> to another branch containing the file "loopy-dash.el", would that be
>> acceptable?

Sorry for not answering earlier, this doesn't really solve the issue,
since the root issue is that when using package-vc or elpa-admin, you
still have two versions of the file in `load-path'.

>
> Hello,
>
> I figured out how to make GitHub automatically copy changes of the file 
> to another branch when the master branch changes, and have listed the 
> file `loopy-dash.el` in the `.elpaignore` file on the master branch.

If we were to disregard examples as those mentioned above, then this
would be an acceptable solution, but I'd rather not, unless you
categorically reject having two separate and disjoint branches.

> I successfully installed the packages locally using the instructions in 
> the ELPA readme.
>
> I have attached a patch file. Are there any other changes that you would 
> like made?

I don't think there is anything else (the only thing I can vainly try to
bring up is that having a diminutive as the name of a macro is something
I find peculiar, and I can imagine would keep a number of other people
from using the otherwise nice package, but it seems it is too late for
that now?)

> Thank you.

Re: Adding package "Loopy" to Non-GNU Devel?

[Okamsn]

Philip Kaludercic wrote:
> Okamsn <okamsn@protonmail.com> writes:
> 
>> Okamsn wrote:
>>> Philip Kaludercic wrote:
>>>> Okamsn <okamsn@protonmail.com> writes:
>>>>> I keep the extension package in the same GitHub repo as the main package for
>>>>> testing purposes.  The Dash functionality was requested by a user, but
>>>>> Dash is
>>>>> not used by the rest of the package.  Because of that, I put the Dash
>>>>> functionality in a small separate package.
>>>>
>>>> You are talking about the loopy-dash.el file in the same branch, right?
>>>
>>> Yes.
>>>
>>>> If possible, it would be better if you could at least maintain it in a
>>>> separate branch.
>>>
>>> If I added the file "loopy-dash.el" to an ".elpaignore" file in the main
>>> branch and used GitHub Actions to push any changes from the main branch
>>> to another branch containing the file "loopy-dash.el", would that be
>>> acceptable?
> 
> Sorry for not answering earlier, this doesn't really solve the issue,
> since the root issue is that when using package-vc or elpa-admin, you
> still have two versions of the file in `load-path'.
> 
>>
>> Hello,
>>
>> I figured out how to make GitHub automatically copy changes of the file
>> to another branch when the master branch changes, and have listed the
>> file `loopy-dash.el` in the `.elpaignore` file on the master branch.
> 
> If we were to disregard examples as those mentioned above, then this
> would be an acceptable solution, but I'd rather not, unless you
> categorically reject having two separate and disjoint branches.

I would like to keep the development of the packages together, since I 
still change the implementation details. Having them together makes 
testing for breakage much easier.

What if I also had GitHub copy changes into a separate branch that only 
contained the Loopy package and the documentation files? This would 
avoid having the two copies of `loopy-dash.el`. Would that work for 
Package VC?

>> I have attached a patch file. Are there any other changes that you would
>> like made?
> 
> I don't think there is anything else (the only thing I can vainly try to
> bring up is that having a diminutive as the name of a macro is something
> I find peculiar, and I can imagine would keep a number of other people
> from using the otherwise nice package, but it seems it is too late for
> that now?)

I think that it is too late, because it has existed on MELPA for a few 
years with that name. If it helps, I was not thinking of it as a 
diminutive, just the normal adjective and the slang usage: 
https://www.thefreedictionary.com/loopy. I acknowledge that your point 
probably also applies for the slang definition, but I still like the name.

Re: Adding package "Loopy" to Non-GNU Devel?

[Philip Kaludercic]

(Sorry for the late response)

Okamsn <okamsn@protonmail.com> writes:

> Philip Kaludercic wrote:
>> Okamsn <okamsn@protonmail.com> writes:
>> 
>>> Okamsn wrote:
>>>> Philip Kaludercic wrote:
>>>>> Okamsn <okamsn@protonmail.com> writes:
>>>>>> I keep the extension package in the same GitHub repo as the main package for
>>>>>> testing purposes.  The Dash functionality was requested by a user, but
>>>>>> Dash is
>>>>>> not used by the rest of the package.  Because of that, I put the Dash
>>>>>> functionality in a small separate package.
>>>>>
>>>>> You are talking about the loopy-dash.el file in the same branch, right?
>>>>
>>>> Yes.
>>>>
>>>>> If possible, it would be better if you could at least maintain it in a
>>>>> separate branch.
>>>>
>>>> If I added the file "loopy-dash.el" to an ".elpaignore" file in the main
>>>> branch and used GitHub Actions to push any changes from the main branch
>>>> to another branch containing the file "loopy-dash.el", would that be
>>>> acceptable?
>> 
>> Sorry for not answering earlier, this doesn't really solve the issue,
>> since the root issue is that when using package-vc or elpa-admin, you
>> still have two versions of the file in `load-path'.
>> 
>>>
>>> Hello,
>>>
>>> I figured out how to make GitHub automatically copy changes of the file
>>> to another branch when the master branch changes, and have listed the
>>> file `loopy-dash.el` in the `.elpaignore` file on the master branch.
>> 
>> If we were to disregard examples as those mentioned above, then this
>> would be an acceptable solution, but I'd rather not, unless you
>> categorically reject having two separate and disjoint branches.
>
> I would like to keep the development of the packages together, since I 
> still change the implementation details. Having them together makes 
> testing for breakage much easier.

One last idea would be to use worktrees, i.e. basically keep development
in separate branches that are simultaneously checked.

> What if I also had GitHub copy changes into a separate branch that only 
> contained the Loopy package and the documentation files? This would 
> avoid having the two copies of `loopy-dash.el`. Would that work for 
> Package VC?

No, since upon installing loopy as a VC package, you'll still have the
loopy-dash.el file as part of the checked out repository and the
loopy-dash.el provided by the dependency.

>>> I have attached a patch file. Are there any other changes that you would
>>> like made?
>> 
>> I don't think there is anything else (the only thing I can vainly try to
>> bring up is that having a diminutive as the name of a macro is something
>> I find peculiar, and I can imagine would keep a number of other people
>> from using the otherwise nice package, but it seems it is too late for
>> that now?)
>
> I think that it is too late, because it has existed on MELPA for a few 
> years with that name. If it helps, I was not thinking of it as a 
> diminutive, just the normal adjective and the slang usage: 
> https://www.thefreedictionary.com/loopy. I acknowledge that your point 
> probably also applies for the slang definition, but I still like the name.

In that case forget my comment.

-- 
	Philip Kaludercic on peregrine

Re: Adding package "Loopy" to Non-GNU Devel?

[Philip Kaludercic]

Philip Kaludercic <philipk@posteo.net> writes:

> (Sorry for the late response)
>
> Okamsn <okamsn@protonmail.com> writes:
>
>> Philip Kaludercic wrote:
>>> Okamsn <okamsn@protonmail.com> writes:
>>> 
>>>> Okamsn wrote:
>>>>> Philip Kaludercic wrote:
>>>>>> Okamsn <okamsn@protonmail.com> writes:
>>>>>>> I keep the extension package in the same GitHub repo as the main package for
>>>>>>> testing purposes.  The Dash functionality was requested by a user, but
>>>>>>> Dash is
>>>>>>> not used by the rest of the package.  Because of that, I put the Dash
>>>>>>> functionality in a small separate package.
>>>>>>
>>>>>> You are talking about the loopy-dash.el file in the same branch, right?
>>>>>
>>>>> Yes.
>>>>>
>>>>>> If possible, it would be better if you could at least maintain it in a
>>>>>> separate branch.
>>>>>
>>>>> If I added the file "loopy-dash.el" to an ".elpaignore" file in the main
>>>>> branch and used GitHub Actions to push any changes from the main branch
>>>>> to another branch containing the file "loopy-dash.el", would that be
>>>>> acceptable?
>>> 
>>> Sorry for not answering earlier, this doesn't really solve the issue,
>>> since the root issue is that when using package-vc or elpa-admin, you
>>> still have two versions of the file in `load-path'.
>>> 
>>>>
>>>> Hello,
>>>>
>>>> I figured out how to make GitHub automatically copy changes of the file
>>>> to another branch when the master branch changes, and have listed the
>>>> file `loopy-dash.el` in the `.elpaignore` file on the master branch.
>>> 
>>> If we were to disregard examples as those mentioned above, then this
>>> would be an acceptable solution, but I'd rather not, unless you
>>> categorically reject having two separate and disjoint branches.
>>
>> I would like to keep the development of the packages together, since I 
>> still change the implementation details. Having them together makes 
>> testing for breakage much easier.
>
> One last idea would be to use worktrees, i.e. basically keep development
> in separate branches that are simultaneously checked.
>
>> What if I also had GitHub copy changes into a separate branch that only 
>> contained the Loopy package and the documentation files? This would 
>> avoid having the two copies of `loopy-dash.el`. Would that work for 
>> Package VC?
>
> No, since upon installing loopy as a VC package, you'll still have the
> loopy-dash.el file as part of the checked out repository and the
> loopy-dash.el provided by the dependency.

Ping?

>>>> I have attached a patch file. Are there any other changes that you would
>>>> like made?
>>> 
>>> I don't think there is anything else (the only thing I can vainly try to
>>> bring up is that having a diminutive as the name of a macro is something
>>> I find peculiar, and I can imagine would keep a number of other people
>>> from using the otherwise nice package, but it seems it is too late for
>>> that now?)
>>
>> I think that it is too late, because it has existed on MELPA for a few 
>> years with that name. If it helps, I was not thinking of it as a 
>> diminutive, just the normal adjective and the slang usage: 
>> https://www.thefreedictionary.com/loopy. I acknowledge that your point 
>> probably also applies for the slang definition, but I still like the name.
>
> In that case forget my comment.

-- 
	Philip Kaludercic on siskin

Re: Adding package "Loopy" to Non-GNU Devel?

[Okamsn]

Philip Kaludercic wrote:
> Ping?
> 
> --
> 	Philip Kaludercic on siskin

Hello,

I currently think that I will separate them into 2 repos. I created a PR 
to add a Pcase pattern that works like `-let` to Dash 
(https://github.com/magnars/dash.el/pull/413). I am waiting to see how 
that goes before separating the files into 2 repos.

Depending on how it goes, I might instead combine the files into a 
single package.

Thank you.