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

[Okamsn <okamsn@protonmail.com>]

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.