Re: Objed maintenance

[Amy Grinn <grinn.amy@gmail.com>]

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.