* Adding package "Loopy" to Non-GNU Devel?
@ 2024-02-20 2:15 Okamsn
2024-02-20 8:09 ` Philip Kaludercic
0 siblings, 1 reply; 9+ messages in thread
From: Okamsn @ 2024-02-20 2:15 UTC (permalink / raw)
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adding package "Loopy" to Non-GNU Devel?
2024-02-20 2:15 Adding package "Loopy" to Non-GNU Devel? Okamsn
@ 2024-02-20 8:09 ` Philip Kaludercic
2024-02-22 3:20 ` Okamsn
0 siblings, 1 reply; 9+ messages in thread
From: Philip Kaludercic @ 2024-02-20 8:09 UTC (permalink / raw)
To: Okamsn; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adding package "Loopy" to Non-GNU Devel?
2024-02-20 8:09 ` Philip Kaludercic
@ 2024-02-22 3:20 ` Okamsn
2024-02-25 17:56 ` Okamsn
0 siblings, 1 reply; 9+ messages in thread
From: Okamsn @ 2024-02-22 3:20 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adding package "Loopy" to Non-GNU Devel?
2024-02-22 3:20 ` Okamsn
@ 2024-02-25 17:56 ` Okamsn
2024-02-25 20:50 ` Philip Kaludercic
0 siblings, 1 reply; 9+ messages in thread
From: Okamsn @ 2024-02-25 17:56 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: emacs-devel
[-- 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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Adding package "Loopy" to Non-GNU Devel?
2024-02-25 17:56 ` Okamsn
@ 2024-02-25 20:50 ` Philip Kaludercic
2024-02-28 1:34 ` Okamsn
0 siblings, 1 reply; 9+ messages in thread
From: Philip Kaludercic @ 2024-02-25 20:50 UTC (permalink / raw)
To: Okamsn; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adding package "Loopy" to Non-GNU Devel?
2024-02-25 20:50 ` Philip Kaludercic
@ 2024-02-28 1:34 ` Okamsn
2024-03-14 18:52 ` Philip Kaludercic
0 siblings, 1 reply; 9+ messages in thread
From: Okamsn @ 2024-02-28 1:34 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adding package "Loopy" to Non-GNU Devel?
2024-02-28 1:34 ` Okamsn
@ 2024-03-14 18:52 ` Philip Kaludercic
2024-09-22 15:36 ` Philip Kaludercic
0 siblings, 1 reply; 9+ messages in thread
From: Philip Kaludercic @ 2024-03-14 18:52 UTC (permalink / raw)
To: Okamsn; +Cc: emacs-devel
(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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adding package "Loopy" to Non-GNU Devel?
2024-03-14 18:52 ` Philip Kaludercic
@ 2024-09-22 15:36 ` Philip Kaludercic
2024-09-22 19:12 ` Okamsn
0 siblings, 1 reply; 9+ messages in thread
From: Philip Kaludercic @ 2024-09-22 15:36 UTC (permalink / raw)
To: Okamsn; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adding package "Loopy" to Non-GNU Devel?
2024-09-22 15:36 ` Philip Kaludercic
@ 2024-09-22 19:12 ` Okamsn
0 siblings, 0 replies; 9+ messages in thread
From: Okamsn @ 2024-09-22 19:12 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2024-09-22 19:12 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-20 2:15 Adding package "Loopy" to Non-GNU Devel? Okamsn
2024-02-20 8:09 ` Philip Kaludercic
2024-02-22 3:20 ` Okamsn
2024-02-25 17:56 ` Okamsn
2024-02-25 20:50 ` Philip Kaludercic
2024-02-28 1:34 ` Okamsn
2024-03-14 18:52 ` Philip Kaludercic
2024-09-22 15:36 ` Philip Kaludercic
2024-09-22 19:12 ` Okamsn
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.