Objed maintenance

Objed maintenance

[Amy Grinn]

Hi Clemens!

First of all, I want to extend my appreciation for your innovative work
on the objed package.  It is by far and away my favorite modal editing
package.

I have been maintaining a fork of objed for about two years; it's
available here:

https://gitlab.com/grinn.amy/objed

I believe my addition of the C-g command and the objed-game tutorial can
be valuable to existing users.  The former allows for quickly entering
and exiting objed and the latter allows users to learn the whole
potential of the package.

I've also made improvements to existing commands such as slurp and barf,
organized the codebase, updated the documentation, and simplified the
build and testing process using eldev.

I would love to get your feedback on any of these improvements, however
I'm aware that this package is not at the forefront of your mind right
now.  In the absence of any activity over the past 4 years, I would
humbly suggest turning the project over to me.

Best,

Amy

Re: Objed maintenance

[Philip Kaludercic]

Amy Grinn <grinn.amy@gmail.com> writes:

> Hi Clemens!
>
> First of all, I want to extend my appreciation for your innovative work
> on the objed package.  It is by far and away my favorite modal editing
> package.
>
> I have been maintaining a fork of objed for about two years; it's
> available here:
>
> https://gitlab.com/grinn.amy/objed
>
> I believe my addition of the C-g command and the objed-game tutorial can
> be valuable to existing users.  The former allows for quickly entering
> and exiting objed and the latter allows users to learn the whole
> potential of the package.
>
> I've also made improvements to existing commands such as slurp and barf,
> organized the codebase, updated the documentation, and simplified the
> build and testing process using eldev.
>
> I would love to get your feedback on any of these improvements, however
> I'm aware that this package is not at the forefront of your mind right
> now.  In the absence of any activity over the past 4 years, I would
> humbly suggest turning the project over to me.

It is my impression, that Clemens isn't really active around Emacs any
more.  His last public contribution on GitHub was 2021 and his website
https://with-emacs.com/ now points to some gambling site (after a HTTPS
error).

I would say that after almost 3 years, enough time has passed that the
maintenance can be passed on, ans since you have some experience with
the package, there is probably no better person for the job right now.

We should make sure that after switching the repository, new versions of
the package shouldn't contain hard-breaks.  I only used the package
briefly a few years back, so it is difficult for me to evaluate this on
my own.  Perhaps someone here on the list has the package installed and
could try out Amy's fork?

> Best,
>
> Amy

-- 
	Philip Kaludercic on peregrine

Re: Objed maintenance

[Amy Grinn]

Philip Kaludercic <philipk@posteo.net> writes:

> Amy Grinn <grinn.amy@gmail.com> writes:

> I would say that after almost 3 years, enough time has passed that the
> maintenance can be passed on, ans since you have some experience with
> the package, there is probably no better person for the job right now.
>

Great, thank you!

> We should make sure that after switching the repository, new versions
> of
> the package shouldn't contain hard-breaks.  I only used the package
> briefly a few years back, so it is difficult for me to evaluate this
> on
> my own.  Perhaps someone here on the list has the package installed
> and
> could try out Amy's fork?

Any feedback would be appreciated!

There were a number of changes in version 0.8.3:

*** Add binding for symbol object "y"
*** Change binding for forward-until from "`" to "'"
*** Change binding for expand-block from "v" to "h"
*** Swap bindings for forward-defun ("E") and beginning-of-defun ("A")
*** Swap binding for del-insert from "i" to "c"
*** "i" exits objed
*** Swap binding for objed-last from "u" to "l"
*** Add objed-undo command "u"
*** C-g toggles objed activation
*** Swap binding for objed-object-map from "c" to "o"
*** Swap binding for objed-expand-context from "o" to "O" (capital "o")

In retrospect this should've been v0.9.0 according to the semver scheme
Clemens is using.  But we live and learn.



Philip, I am using an unpublished dependency called key-game, which I
wrote, which I thought might be useful for other modal editing packages,
or for large packages like gnus.  Anyways I will try to submit that
package for publishing on GNU ELPA before objed is updated.

Re: Objed maintenance

[Philip Kaludercic]

Amy Grinn <grinn.amy@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Amy Grinn <grinn.amy@gmail.com> writes:
>
>> I would say that after almost 3 years, enough time has passed that the
>> maintenance can be passed on, ans since you have some experience with
>> the package, there is probably no better person for the job right now.
>>
>
> Great, thank you!
>
>> We should make sure that after switching the repository, new versions
>> of
>> the package shouldn't contain hard-breaks.  I only used the package
>> briefly a few years back, so it is difficult for me to evaluate this
>> on
>> my own.  Perhaps someone here on the list has the package installed
>> and
>> could try out Amy's fork?
>
> Any feedback would be appreciated!
>
> There were a number of changes in version 0.8.3:
>
> *** Add binding for symbol object "y"
> *** Change binding for forward-until from "`" to "'"
> *** Change binding for expand-block from "v" to "h"
> *** Swap bindings for forward-defun ("E") and beginning-of-defun ("A")
> *** Swap binding for del-insert from "i" to "c"
> *** "i" exits objed
> *** Swap binding for objed-last from "u" to "l"
> *** Add objed-undo command "u"
> *** C-g toggles objed activation
> *** Swap binding for objed-object-map from "c" to "o"
> *** Swap binding for objed-expand-context from "o" to "O" (capital "o")

I cannot comment on any of this, with the exception of the C-g change
that seems invasive.  Can you elaborate on that?

> In retrospect this should've been v0.9.0 according to the semver scheme
> Clemens is using.  But we live and learn.
>
>
>
> Philip, I am using an unpublished dependency called key-game, which I
> wrote, which I thought might be useful for other modal editing packages,
> or for large packages like gnus.  Anyways I will try to submit that
> package for publishing on GNU ELPA before objed is updated.

That sounds good, just inferring from the name it sounds like wizard or
training program?  Is this going to be a hard dependency or a weak one?

-- 
	Philip Kaludercic on peregrine

Re: Objed maintenance

[Amy Grinn]

Philip Kaludercic <philipk@posteo.net> writes:

> Amy Grinn <grinn.amy@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> We should make sure that after switching the repository, new
>>> versions
>>> of
>>> the package shouldn't contain hard-breaks.  I only used the package
>>> briefly a few years back, so it is difficult for me to evaluate
>>> this
>>> on
>>> my own.  Perhaps someone here on the list has the package installed
>>> and
>>> could try out Amy's fork?
>>
>> Any feedback would be appreciated!
>>
>> There were a number of changes in version 0.8.3:
>>
>> *** Add binding for symbol object "y"
>> *** Change binding for forward-until from "`" to "'"
>> *** Change binding for expand-block from "v" to "h"
>> *** Swap bindings for forward-defun ("E") and beginning-of-defun
>> ("A")
>> *** Swap binding for del-insert from "i" to "c"
>> *** "i" exits objed
>> *** Swap binding for objed-last from "u" to "l"
>> *** Add objed-undo command "u"
>> *** C-g toggles objed activation
>> *** Swap binding for objed-object-map from "c" to "o"
>> *** Swap binding for objed-expand-context from "o" to "O" (capital
>> "o")
>
> I cannot comment on any of this, with the exception of the C-g change
> that seems invasive.  Can you elaborate on that?
>

The normal C-g behavior does not change but objed activation is also
toggled.  It's something you kinda have to experience firsthand to
realize how non-invasive it is.

>> In retrospect this should've been v0.9.0 according to the semver
>> scheme
>> Clemens is using.  But we live and learn.
>>
>>
>>
>> Philip, I am using an unpublished dependency called key-game, which
>> I
>> wrote, which I thought might be useful for other modal editing
>> packages,
>> or for large packages like gnus.  Anyways I will try to submit that
>> package for publishing on GNU ELPA before objed is updated.
>
> That sounds good, just inferring from the name it sounds like wizard
> or
> training program?  Is this going to be a hard dependency or a weak
> one?

Yes, it's a utility package to help create key-based or command-based
tutorial games.  It's not a user-facing package, similar to boxy; I
wouldn't want users to have to install it explicitly.  To answer a
potential followup, I also wouldn't want to split up the objed tutorial
game into a separate package.  That would hinder discoverability and
make the installation of objed more complex.  All that to say I believe
key-game will be a hard dependency.

Re: Objed maintenance

[Philip Kaludercic]

Amy Grinn <grinn.amy@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Amy Grinn <grinn.amy@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> We should make sure that after switching the repository, new
>>>> versions
>>>> of
>>>> the package shouldn't contain hard-breaks.  I only used the package
>>>> briefly a few years back, so it is difficult for me to evaluate
>>>> this
>>>> on
>>>> my own.  Perhaps someone here on the list has the package installed
>>>> and
>>>> could try out Amy's fork?
>>>
>>> Any feedback would be appreciated!
>>>
>>> There were a number of changes in version 0.8.3:
>>>
>>> *** Add binding for symbol object "y"
>>> *** Change binding for forward-until from "`" to "'"
>>> *** Change binding for expand-block from "v" to "h"
>>> *** Swap bindings for forward-defun ("E") and beginning-of-defun
>>> ("A")
>>> *** Swap binding for del-insert from "i" to "c"
>>> *** "i" exits objed
>>> *** Swap binding for objed-last from "u" to "l"
>>> *** Add objed-undo command "u"
>>> *** C-g toggles objed activation
>>> *** Swap binding for objed-object-map from "c" to "o"
>>> *** Swap binding for objed-expand-context from "o" to "O" (capital
>>> "o")
>>
>> I cannot comment on any of this, with the exception of the C-g change
>> that seems invasive.  Can you elaborate on that?
>
> The normal C-g behavior does not change but objed activation is also
> toggled.  It's something you kinda have to experience firsthand to
> realize how non-invasive it is.

I trust you if you say it is so.

>>> In retrospect this should've been v0.9.0 according to the semver
>>> scheme
>>> Clemens is using.  But we live and learn.
>>>
>>>
>>>
>>> Philip, I am using an unpublished dependency called key-game, which
>>> I
>>> wrote, which I thought might be useful for other modal editing
>>> packages,
>>> or for large packages like gnus.  Anyways I will try to submit that
>>> package for publishing on GNU ELPA before objed is updated.
>>
>> That sounds good, just inferring from the name it sounds like wizard
>> or
>> training program?  Is this going to be a hard dependency or a weak
>> one?
>
> Yes, it's a utility package to help create key-based or command-based
> tutorial games.  It's not a user-facing package, similar to boxy; I
> wouldn't want users to have to install it explicitly.  To answer a
> potential followup, I also wouldn't want to split up the objed tutorial
> game into a separate package.  That would hinder discoverability and
> make the installation of objed more complex.  All that to say I believe
> key-game will be a hard dependency.

That is a pity.  I try to advocate for minimising dependencies,
especially if these aren't required for the core functionality of a
package.  I don't know how your package is designed, but couldn't you
have a command like M-x objed-tutorial that reports an error if the
package is not installed (or proposes to install it)?  FWIW I don't
think having a separate package is a good idea either -- too much noise
in the package list.

-- 
	Philip Kaludercic on peregrine

Re: Objed maintenance

[Amy Grinn]

Philip Kaludercic <philipk@posteo.net> writes:

> Amy Grinn <grinn.amy@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>
>>>> Philip, I am using an unpublished dependency called key-game,
>>>> which
>>>> I
>>>> wrote, which I thought might be useful for other modal editing
>>>> packages,
>>>> or for large packages like gnus.  Anyways I will try to submit
>>>> that
>>>> package for publishing on GNU ELPA before objed is updated.
>>>
>>> That sounds good, just inferring from the name it sounds like
>>> wizard
>>> or
>>> training program?  Is this going to be a hard dependency or a weak
>>> one?
>>
>> Yes, it's a utility package to help create key-based or
>> command-based
>> tutorial games.  It's not a user-facing package, similar to boxy; I
>> wouldn't want users to have to install it explicitly.  To answer a
>> potential followup, I also wouldn't want to split up the objed
>> tutorial
>> game into a separate package.  That would hinder discoverability and
>> make the installation of objed more complex.  All that to say I
>> believe
>> key-game will be a hard dependency.
>
> That is a pity.  I try to advocate for minimising dependencies,
> especially if these aren't required for the core functionality of a
> package.  I don't know how your package is designed, but couldn't you
> have a command like M-x objed-tutorial that reports an error if the
> package is not installed (or proposes to install it)?  FWIW I don't
> think having a separate package is a good idea either -- too much
> noise
> in the package list.

Practically, the entrypoint for the objed tutorial game is a key-game
macro call, so it would be difficult to rewire.  Moreover, this would
cause a similar issue in all other packages which might use key-game.
This implies much more boilerplate which must be maintained separately
in all those packages.

I see your point that the tutorial is not *the* core feature of objed,
but in my opinion it is *a* core part, and one that is more likely to be
invoked by new users.  I don't want to put up roadblocks for them.  I
think peer dependencies can be useful for extending a package, and objed
already has such a dependency with avy, but this seems like an
unnecessary installation step instead.

I'm not as experienced with ELPA, so I would like to know more about the
thought process behind discouraging direct dependencies.  But again, I
don't think key-game has any intrinsic features which an end user may
want separate and apart from its use in other packages, and I would find
it odd to suggest users add it to their selected packages.

Re: Objed maintenance

[Philip Kaludercic]

Amy Grinn <grinn.amy@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Amy Grinn <grinn.amy@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>
>>>>> Philip, I am using an unpublished dependency called key-game,
>>>>> which
>>>>> I
>>>>> wrote, which I thought might be useful for other modal editing
>>>>> packages,
>>>>> or for large packages like gnus.  Anyways I will try to submit
>>>>> that
>>>>> package for publishing on GNU ELPA before objed is updated.
>>>>
>>>> That sounds good, just inferring from the name it sounds like
>>>> wizard
>>>> or
>>>> training program?  Is this going to be a hard dependency or a weak
>>>> one?
>>>
>>> Yes, it's a utility package to help create key-based or
>>> command-based
>>> tutorial games.  It's not a user-facing package, similar to boxy; I
>>> wouldn't want users to have to install it explicitly.  To answer a
>>> potential followup, I also wouldn't want to split up the objed
>>> tutorial
>>> game into a separate package.  That would hinder discoverability and
>>> make the installation of objed more complex.  All that to say I
>>> believe
>>> key-game will be a hard dependency.
>>
>> That is a pity.  I try to advocate for minimising dependencies,
>> especially if these aren't required for the core functionality of a
>> package.  I don't know how your package is designed, but couldn't you
>> have a command like M-x objed-tutorial that reports an error if the
>> package is not installed (or proposes to install it)?  FWIW I don't
>> think having a separate package is a good idea either -- too much
>> noise
>> in the package list.
>
> Practically, the entrypoint for the objed tutorial game is a key-game
> macro call, so it would be difficult to rewire.  Moreover, this would
> cause a similar issue in all other packages which might use key-game.
> This implies much more boilerplate which must be maintained separately
> in all those packages.
>
> I see your point that the tutorial is not *the* core feature of objed,
> but in my opinion it is *a* core part, and one that is more likely to be
> invoked by new users.  I don't want to put up roadblocks for them.  I
> think peer dependencies can be useful for extending a package, and objed
> already has such a dependency with avy, but this seems like an
> unnecessary installation step instead.
>
> I'm not as experienced with ELPA, so I would like to know more about the
> thought process behind discouraging direct dependencies.  But again, I
> don't think key-game has any intrinsic features which an end user may
> want separate and apart from its use in other packages, and I would find
> it odd to suggest users add it to their selected packages.

Abstractly: My advice is my advice, it is inherently biased.  I take
that position, because of my experience, which is why I refuse to
install packages with more than 1-~2 transitive dependencies (I was
recently once again shocked by "ement").  As everything I say that isn't
part of the ELPA rules, you can ignore it if you think you know better.
My motivation to help with ELPA is rooted in my own interest to have
good packages, given my own understanding of what makes packages good.

Concretely: I don't know how key-game looks like, so I cannot really say
if it makes sense or not.  I had something in mind like a generic wizard
framework, where you'd M-x key-game, then get prompted what game to play
(as defined by whatever package provides a game) and then it would play
that game.

-- 
	Philip Kaludercic on peregrine

Re: Objed maintenance

[Adam Porter]

Hi Philip,

> Abstractly: My advice is my advice, it is inherently biased.  I take
> that position, because of my experience, which is why I refuse to
> install packages with more than 1-~2 transitive dependencies (I was
> recently once again shocked by "ement").

Would you please explain what you mean here?

--Adam

Re: Objed maintenance

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

> Hi Philip,
>
>> Abstractly: My advice is my advice, it is inherently biased.  I take
>> that position, because of my experience, which is why I refuse to
>> install packages with more than 1-~2 transitive dependencies (I was
>> recently once again shocked by "ement").
>
> Would you please explain what you mean here?

Just that I recently wanted to try out ement, but decided not to do so
when I saw the list of dependencies.

> --Adam
>

-- 
	Philip Kaludercic on peregrine

Re: Objed maintenance

[Adam Porter]

On 5/2/24 01:02, Philip Kaludercic wrote:
> Adam Porter <adam@alphapapa.net> writes:
> 
>> Hi Philip,
>>
>>> Abstractly: My advice is my advice, it is inherently biased.  I take
>>> that position, because of my experience, which is why I refuse to
>>> install packages with more than 1-~2 transitive dependencies (I was
>>> recently once again shocked by "ement").
>>
>> Would you please explain what you mean here?
> 
> Just that I recently wanted to try out ement, but decided not to do so
> when I saw the list of dependencies.

I don't understand.  There are only a few, and they're all on GNU ELPA. 
Which ones do you object to, and why?

Re: Objed maintenance

[Amy Grinn]

Philip Kaludercic <philipk@posteo.net> writes:

> Amy Grinn <grinn.amy@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>
>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>
>>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>>
>>>>>> Philip, I am using an unpublished dependency called key-game,
>>>>>> which I wrote, which I thought might be useful for other modal
>>>>>> editing packages, or for large packages like gnus.  Anyways I
>>>>>> will try to submit that package for publishing on GNU ELPA before
>>>>>> objed is updated.
>>>>>
>>>>> That sounds good, just inferring from the name it sounds like
>>>>> wizard or training program?  Is this going to be a hard dependency
>>>>> or a weak one?
>>>>
>>>> Yes, it's a utility package to help create key-based or
>>>> command-based tutorial games.  It's not a user-facing package,
>>>> similar to boxy; I wouldn't want users to have to install it
>>>> explicitly.  To answer a potential followup, I also wouldn't want
>>>> to split up the objed tutorial game into a separate package.  That
>>>> would hinder discoverability and make the installation of objed
>>>> more complex.  All that to say I believe key-game will be a hard
>>>> dependency.
>>>
>>> That is a pity.  I try to advocate for minimising dependencies,
>>> especially if these aren't required for the core functionality of a
>>> package.  I don't know how your package is designed, but couldn't
>>> you have a command like M-x objed-tutorial that reports an error if
>>> the package is not installed (or proposes to install it)?  FWIW I
>>> don't think having a separate package is a good idea either -- too
>>> much noise in the package list.
>>
>> Practically, the entrypoint for the objed tutorial game is a key-game
>> macro call, so it would be difficult to rewire.  Moreover, this would
>> cause a similar issue in all other packages which might use key-game.
>> This implies much more boilerplate which must be maintained
>> separately in all those packages.
>>
>> I see your point that the tutorial is not *the* core feature of
>> objed, but in my opinion it is *a* core part, and one that is more
>> likely to be invoked by new users.  I don't want to put up roadblocks
>> for them.  I think peer dependencies can be useful for extending a
>> package, and objed already has such a dependency with avy, but this
>> seems like an unnecessary installation step instead.
>>
>> I'm not as experienced with ELPA, so I would like to know more about
>> the thought process behind discouraging direct dependencies.  But
>> again, I don't think key-game has any intrinsic features which an end
>> user may want separate and apart from its use in other packages, and
>> I would find it odd to suggest users add it to their selected
>> packages.
>
> Abstractly: My advice is my advice, it is inherently biased.  I take
> that position, because of my experience, which is why I refuse to
> install packages with more than 1-~2 transitive dependencies (I was
> recently once again shocked by "ement").  As everything I say that
> isn't part of the ELPA rules, you can ignore it if you think you know
> better.  My motivation to help with ELPA is rooted in my own interest
> to have good packages, given my own understanding of what makes
> packages good.
>
> Concretely: I don't know how key-game looks like, so I cannot really
> say if it makes sense or not.  I had something in mind like a generic
> wizard framework, where you'd M-x key-game, then get prompted what
> game to play (as defined by whatever package provides a game) and then
> it would play that game.

That's an interesting idea, kind of like man pages except for tutorial
games.  Centralizing the entrypoint for all key games is not exactly the
direction I took though, in the current implementation each package is
responsible for creating a separate entrypoint.

I'll have to give it some more thought but I have a few concerns
already.  It probably doesn't address the boilerplate code issue I
brought up but more importantly it seems like a dual dependency:
objed-game requires key-game for its implementation and key-game
requires objed-game to register itself as a valid game.  If only one of
the packages is loaded it would necessarily load the other I think?
Currently, the command objed-game resides in a separate file which is
autoloaded (along with key-game) IFF a user invokes it.

When you have the time, I would like to know if you have a specific
autoload/dependency scheme in mind and if there are any similar packages
already in ELPA which act as a centralized interface for interacting
with other packages.

-- 
Best,

Amy

Re: Objed maintenance

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

> On 5/2/24 01:02, Philip Kaludercic wrote:
>> Adam Porter <adam@alphapapa.net> writes:
>> 
>>> Hi Philip,
>>>
>>>> Abstractly: My advice is my advice, it is inherently biased.  I take
>>>> that position, because of my experience, which is why I refuse to
>>>> install packages with more than 1-~2 transitive dependencies (I was
>>>> recently once again shocked by "ement").
>>>
>>> Would you please explain what you mean here?
>> Just that I recently wanted to try out ement, but decided not to do
>> so
>> when I saw the list of dependencies.
>
> I don't understand.  There are only a few, and they're all on GNU
> ELPA. Which ones do you object to, and why?

I am trying to give Amy an example of why to avoid dependencies, because
people like me don't look at

   Requires: emacs-27.1, map-2.1, persist-0.5, plz-0.6, taxy-0.10,
   taxy-magit-section-0.13, svg-lib-0.2.5, transient-0.3.7

and say it is only a few, if my limit is at 1-2 /transitive/
dependencies.  (In addition to that, you know that I have strong
opinions on Emacs package names and do not what to install a package
called "taxy", even though I know that this is probably just my
opinion).

-- 
	Philip Kaludercic on peregrine

Re: Objed maintenance

[Adam Porter]

Hi Philip,

On 5/2/24 12:09, Philip Kaludercic wrote:
> Adam Porter <adam@alphapapa.net> writes:
> 
>> On 5/2/24 01:02, Philip Kaludercic wrote:
>>> Adam Porter <adam@alphapapa.net> writes:
>>> 
>>>> Hi Philip,
>>>> 
>>>>> Abstractly: My advice is my advice, it is inherently biased.
>>>>> I take that position, because of my experience, which is why
>>>>> I refuse to install packages with more than 1-~2 transitive
>>>>> dependencies (I was recently once again shocked by "ement").
>>>> 
>>>> Would you please explain what you mean here?
>>> Just that I recently wanted to try out ement, but decided not to
>>> do so when I saw the list of dependencies.
>> 
>> I don't understand.  There are only a few, and they're all on GNU 
>> ELPA. Which ones do you object to, and why?
> 
> I am trying to give Amy an example of why to avoid dependencies,
> because people like me don't look at
> 
> Requires: emacs-27.1, map-2.1, persist-0.5, plz-0.6, taxy-0.10, 
> taxy-magit-section-0.13, svg-lib-0.2.5, transient-0.3.7
> 
> and say it is only a few, if my limit is at 1-2 /transitive/ 
> dependencies.  (In addition to that, you know that I have strong 
> opinions on Emacs package names and do not what to install a package 
> called "taxy", even though I know that this is probably just my 
> opinion).

Thanks for explaining your view.

Of note, one of those dependencies is Emacs itself, and two others are 
included with Emacs, i.e. map and transient.  That leaves 5 ELPA 
dependencies: persist is commonly used and works very well (and until 
multisession is improved a bit further, it seems like a better choice); 
plz is now a stable, reliable library that's becoming more widely used; 
svg-lib, by Nicolas Rougier, is very useful for what it does, but it 
could be made an optional dependency, I suppose.

That leaves taxy and taxy-magit-section, which are fundamental to the 
room list feature and its dynamic, user-programmable grouping.  The name 
"taxy" is short for "taxonomy" (which might seem to imply a biological 
purpose), or "taxonomical-programmable-grouping" (which would be a bit 
long).

If the name puts you off so much as to not even let it be installed as a 
dependency, and to explore what functionality it offers (which IMHO is 
unique and powerful), that is a bit disappointing to hear--if I removed 
the software with unusual or non-obvious names on my system, we wouldn't 
be having this conversation--but to each his own.

--Adam

Re: Objed maintenance

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

> Hi Philip,
>
> On 5/2/24 12:09, Philip Kaludercic wrote:
>> Adam Porter <adam@alphapapa.net> writes:
>> 
>>> On 5/2/24 01:02, Philip Kaludercic wrote:
>>>> Adam Porter <adam@alphapapa.net> writes:
>>>> 
>>>>> Hi Philip,
>>>>> 
>>>>>> Abstractly: My advice is my advice, it is inherently biased.
>>>>>> I take that position, because of my experience, which is why
>>>>>> I refuse to install packages with more than 1-~2 transitive
>>>>>> dependencies (I was recently once again shocked by "ement").
>>>>> Would you please explain what you mean here?
>>>> Just that I recently wanted to try out ement, but decided not to
>>>> do so when I saw the list of dependencies.
>>> I don't understand.  There are only a few, and they're all on GNU
>>> ELPA. Which ones do you object to, and why?
>> I am trying to give Amy an example of why to avoid dependencies,
>> because people like me don't look at
>> Requires: emacs-27.1, map-2.1, persist-0.5, plz-0.6, taxy-0.10,
>> taxy-magit-section-0.13, svg-lib-0.2.5, transient-0.3.7
>> and say it is only a few, if my limit is at 1-2 /transitive/
>> dependencies.  (In addition to that, you know that I have strong
>> opinions on Emacs package names and do not what to install a package
>> called "taxy", even though I know that this is probably just my
>> opinion).
>
> Thanks for explaining your view.
>
> Of note, one of those dependencies is Emacs itself, and two others are
> included with Emacs, i.e. map and transient.  That leaves 5 ELPA
> dependencies: persist is commonly used and works very well (and until
> multisession is improved a bit further, it seems like a better
> choice); plz is now a stable, reliable library that's becoming more
> widely used; svg-lib, by Nicolas Rougier, is very useful for what it
> does, but it could be made an optional dependency, I suppose.
>
> That leaves taxy and taxy-magit-section, which are fundamental to the
> room list feature and its dynamic, user-programmable grouping.  The
> name "taxy" is short for "taxonomy" (which might seem to imply a
> biological purpose), or "taxonomical-programmable-grouping" (which
> would be a bit long).
>
> If the name puts you off so much as to not even let it be installed as
> a dependency, and to explore what functionality it offers (which IMHO
> is unique and powerful), that is a bit disappointing to hear--if I
> removed the software with unusual or non-obvious names on my system,
> we wouldn't be having this conversation--but to each his own.

I refused to use grep at first, and it took me a bit to get over that
inhibition.  There have been multiple packages I decided not to install
after apt/dnf/... displayed the dependencies it would install.

This is not to defend my position, or a call to change my mind.  I just
want to illustrate that people like me exist and that I'd appreciate it
if these preferences aren't totally ignored.

BTW. I checked on my one non-development laptop, and all the recursive
dependencies I have installed were by Magit.

> --Adam

-- 
	Philip Kaludercic on peregrine

Re: Objed maintenance

[Philip Kaludercic]

Amy Grinn <grinn.amy@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Amy Grinn <grinn.amy@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>
>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>>
>>>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>>>
>>>>>>> Philip, I am using an unpublished dependency called key-game,
>>>>>>> which I wrote, which I thought might be useful for other modal
>>>>>>> editing packages, or for large packages like gnus.  Anyways I
>>>>>>> will try to submit that package for publishing on GNU ELPA before
>>>>>>> objed is updated.
>>>>>>
>>>>>> That sounds good, just inferring from the name it sounds like
>>>>>> wizard or training program?  Is this going to be a hard dependency
>>>>>> or a weak one?
>>>>>
>>>>> Yes, it's a utility package to help create key-based or
>>>>> command-based tutorial games.  It's not a user-facing package,
>>>>> similar to boxy; I wouldn't want users to have to install it
>>>>> explicitly.  To answer a potential followup, I also wouldn't want
>>>>> to split up the objed tutorial game into a separate package.  That
>>>>> would hinder discoverability and make the installation of objed
>>>>> more complex.  All that to say I believe key-game will be a hard
>>>>> dependency.
>>>>
>>>> That is a pity.  I try to advocate for minimising dependencies,
>>>> especially if these aren't required for the core functionality of a
>>>> package.  I don't know how your package is designed, but couldn't
>>>> you have a command like M-x objed-tutorial that reports an error if
>>>> the package is not installed (or proposes to install it)?  FWIW I
>>>> don't think having a separate package is a good idea either -- too
>>>> much noise in the package list.
>>>
>>> Practically, the entrypoint for the objed tutorial game is a key-game
>>> macro call, so it would be difficult to rewire.  Moreover, this would
>>> cause a similar issue in all other packages which might use key-game.
>>> This implies much more boilerplate which must be maintained
>>> separately in all those packages.
>>>
>>> I see your point that the tutorial is not *the* core feature of
>>> objed, but in my opinion it is *a* core part, and one that is more
>>> likely to be invoked by new users.  I don't want to put up roadblocks
>>> for them.  I think peer dependencies can be useful for extending a
>>> package, and objed already has such a dependency with avy, but this
>>> seems like an unnecessary installation step instead.
>>>
>>> I'm not as experienced with ELPA, so I would like to know more about
>>> the thought process behind discouraging direct dependencies.  But
>>> again, I don't think key-game has any intrinsic features which an end
>>> user may want separate and apart from its use in other packages, and
>>> I would find it odd to suggest users add it to their selected
>>> packages.
>>
>> Abstractly: My advice is my advice, it is inherently biased.  I take
>> that position, because of my experience, which is why I refuse to
>> install packages with more than 1-~2 transitive dependencies (I was
>> recently once again shocked by "ement").  As everything I say that
>> isn't part of the ELPA rules, you can ignore it if you think you know
>> better.  My motivation to help with ELPA is rooted in my own interest
>> to have good packages, given my own understanding of what makes
>> packages good.
>>
>> Concretely: I don't know how key-game looks like, so I cannot really
>> say if it makes sense or not.  I had something in mind like a generic
>> wizard framework, where you'd M-x key-game, then get prompted what
>> game to play (as defined by whatever package provides a game) and then
>> it would play that game.
>
> That's an interesting idea, kind of like man pages except for tutorial
> games.  Centralizing the entrypoint for all key games is not exactly the
> direction I took though, in the current implementation each package is
> responsible for creating a separate entrypoint.

Right, I recall there was a discussion on creating a configuration
wizard a few years back, and I'd imagine that it might look something
like that as well.

> I'll have to give it some more thought but I have a few concerns
> already.  It probably doesn't address the boilerplate code issue I
> brought up but more importantly it seems like a dual dependency:
> objed-game requires key-game for its implementation and key-game
> requires objed-game to register itself as a valid game.  If only one of
> the packages is loaded it would necessarily load the other I think?
> Currently, the command objed-game resides in a separate file which is
> autoloaded (along with key-game) IFF a user invokes it.

Why not just wrap it in a with-eval-after-load inside of objed-game?
I am not familiar with the boiler-plate code (have you sent me the code
and did I just miss it?) but if your input is just data, then you could
add it to a list that key-game queries.

> When you have the time, I would like to know if you have a specific
> autoload/dependency scheme in mind and if there are any similar packages
> already in ELPA which act as a centralized interface for interacting
> with other packages.

Perhaps the built-in VC package?  My autocrypt package is also built up
in a way that would support this kind of usage, but these tackle
different issues. 

-- 
	Philip Kaludercic on peregrine

Re: Objed maintenance

[Amy Grinn]

Philip Kaludercic <philipk@posteo.net> writes:

> Amy Grinn <grinn.amy@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>
>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>
>>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>>
>>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>>>
>>>>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>>>>
>>>>>>>> Philip, I am using an unpublished dependency called key-game,
>>>>>>>> which I wrote, which I thought might be useful for other modal
>>>>>>>> editing packages, or for large packages like gnus.  Anyways I
>>>>>>>> will try to submit that package for publishing on GNU ELPA
>>>>>>>> before
>>>>>>>> objed is updated.
>>>>>>>
>>>>>>> That sounds good, just inferring from the name it sounds like
>>>>>>> wizard or training program?  Is this going to be a hard
>>>>>>> dependency
>>>>>>> or a weak one?
>>>>>>
>>>>>> Yes, it's a utility package to help create key-based or
>>>>>> command-based tutorial games.  It's not a user-facing package,
>>>>>> similar to boxy; I wouldn't want users to have to install it
>>>>>> explicitly.  To answer a potential followup, I also wouldn't
>>>>>> want
>>>>>> to split up the objed tutorial game into a separate package.
>>>>>> That
>>>>>> would hinder discoverability and make the installation of objed
>>>>>> more complex.  All that to say I believe key-game will be a hard
>>>>>> dependency.
>>>>>
>>>>> That is a pity.  I try to advocate for minimising dependencies,
>>>>> especially if these aren't required for the core functionality of
>>>>> a
>>>>> package.  I don't know how your package is designed, but couldn't
>>>>> you have a command like M-x objed-tutorial that reports an error
>>>>> if
>>>>> the package is not installed (or proposes to install it)?  FWIW I
>>>>> don't think having a separate package is a good idea either --
>>>>> too
>>>>> much noise in the package list.
>>>>
>>>> Practically, the entrypoint for the objed tutorial game is a
>>>> key-game
>>>> macro call, so it would be difficult to rewire.  Moreover, this
>>>> would
>>>> cause a similar issue in all other packages which might use
>>>> key-game.
>>>> This implies much more boilerplate which must be maintained
>>>> separately in all those packages.
>>>>
>>>> I see your point that the tutorial is not *the* core feature of
>>>> objed, but in my opinion it is *a* core part, and one that is more
>>>> likely to be invoked by new users.  I don't want to put up
>>>> roadblocks
>>>> for them.  I think peer dependencies can be useful for extending a
>>>> package, and objed already has such a dependency with avy, but
>>>> this
>>>> seems like an unnecessary installation step instead.
>>>>
>>>> I'm not as experienced with ELPA, so I would like to know more
>>>> about
>>>> the thought process behind discouraging direct dependencies.  But
>>>> again, I don't think key-game has any intrinsic features which an
>>>> end
>>>> user may want separate and apart from its use in other packages,
>>>> and
>>>> I would find it odd to suggest users add it to their selected
>>>> packages.
>>>
>>> Abstractly: My advice is my advice, it is inherently biased.  I
>>> take
>>> that position, because of my experience, which is why I refuse to
>>> install packages with more than 1-~2 transitive dependencies (I was
>>> recently once again shocked by "ement").  As everything I say that
>>> isn't part of the ELPA rules, you can ignore it if you think you
>>> know
>>> better.  My motivation to help with ELPA is rooted in my own
>>> interest
>>> to have good packages, given my own understanding of what makes
>>> packages good.
>>>
>>> Concretely: I don't know how key-game looks like, so I cannot
>>> really
>>> say if it makes sense or not.  I had something in mind like a
>>> generic
>>> wizard framework, where you'd M-x key-game, then get prompted what
>>> game to play (as defined by whatever package provides a game) and
>>> then
>>> it would play that game.
>>
>> That's an interesting idea, kind of like man pages except for
>> tutorial
>> games.  Centralizing the entrypoint for all key games is not exactly
>> the
>> direction I took though, in the current implementation each package
>> is
>> responsible for creating a separate entrypoint.
>
> Right, I recall there was a discussion on creating a configuration
> wizard a few years back, and I'd imagine that it might look something
> like that as well.
>
>> I'll have to give it some more thought but I have a few concerns
>> already.  It probably doesn't address the boilerplate code issue I
>> brought up but more importantly it seems like a dual dependency:
>> objed-game requires key-game for its implementation and key-game
>> requires objed-game to register itself as a valid game.  If only one
>> of
>> the packages is loaded it would necessarily load the other I think?
>> Currently, the command objed-game resides in a separate file which
>> is
>> autoloaded (along with key-game) IFF a user invokes it.
>
> Why not just wrap it in a with-eval-after-load inside of objed-game?

That is a possibility, but wouldn't that make the key-game command very
slow the first time?  If a dozen packages implement key-games, they will
all be loaded at the same time.

> I am not familiar with the boiler-plate code (have you sent me the
> code and did I just miss it?)

To circle back, the discussion was about making key-game an optional
dependency.  So each package which implements a key game must have the
same boilerplate code that asks the user to install key-game and then
loads the full implementation.

> but if your input is just data, then you could add it to a list that
> key-game queries.

But key-game may not have been installed, so this would need to be a
with-eval-after-load situation as well.  And in order to make objed-game
visible to key-game even in the situation where objed hasn't been
loaded, the form must also be autoloaded.

>> When you have the time, I would like to know if you have a specific
>> autoload/dependency scheme in mind and if there are any similar
>> packages
>> already in ELPA which act as a centralized interface for interacting
>> with other packages.
>
> Perhaps the built-in VC package?  My autocrypt package is also built
> up
> in a way that would support this kind of usage, but these tackle
> different issues.

VC can always just be required by its dependents without installing
anything, so I don't think that is a particularly helpful example to me.
With autocrypt I see it has the ability to be extended but I couldn't
find any actual extension packages.  Nevertheless, if an autocrypt
extension was submitted to GNU ELPA, would you also suggest the author
not rely directly on autocrypt?

...

I understand and share your concern about packages like ement.
Particularly having a dependency like taxy-magit-section, which has no
real semantic meaning and has dependencies of its own which have their
OWN dependencies.  Since key-game will be the first dependency of objed,
has no dependencies of its own, and it's clear what the package does, I
don't think this is a directly comparable situation.

My overarching concern with your suggestions so far is that it would
complicate the dependency structure and make it more difficult to
develop and maintain key-game implementations.  That is the exact
opposite of the purpose of key-game, which is meant to simplify the
development of key based tutorial games.

I appreciate your time and thoughts but I think I'm going to keep the
dependency scheme as it is now: key-game will have no knowledge of where
it is being used and each implementation will depend directly on it.

-- 
Best,

Amy