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