Re: [ELPA] New package: activities

[Adam Porter <adam@alphapapa.net>]

Hello Eli,

On 1/26/24 06:32, Eli Zaretskii wrote:
>> Date: Fri, 26 Jan 2024 04:42:26 -0600
>> Cc: emacs-devel@gnu.org
>> From: Adam Porter <adam@alphapapa.net>
>>
>>>   From the user-facing POV, how is this different from desktop.el's
>>> ability to save/restore Emacs sessions to/from separate desktop files?
>>
>> As the documentation explains:
>>
>>     How does this differ from the built-in ~desktop-mode~? :: As best
>> this author can tell, ~desktop-mode~ saves and restores one set of
>> buffers, with various options to control its behavior.  It does not use
>> ~bookmark~ internally, which prevents it from restoring non-file-backed
>> buffers.
> 
> This could be added to desktop.el as a (relatively simple)
> enhancement.

I've looked at desktop.el's code.  I don't think it would be very simple 
to do so.

>> As well, it is not intended to be used on-demand to switch
>> between sets of buffers, windows, or frames (i.e. "activities").
> 
> Maybe I don't understand what this means, but desktop.el can be told
> to restore a session recorded in a specific directory, which allows
> the user to have several desktops recorded, and to restore each one
> when necessary.  Are you talking about something else?

1.  desktop.el seems to have the concept of one desktop being active at 
a time.  A desktop can be switched to, which kills and clears the active 
one.

activities.el has no such limitation.  A user can have as many 
activities active as needed and can switch between them independently at 
any time.

2. desktop.el works by the unusual concept of choosing a directory in 
which to save "a desktop file."  As a user, I have no interest in 
choosing a directory into which to save an activity's state file.  This 
should be transparent to the user.

activities.el stores activities in an alist which is stored with 
persist.el.  It's UI is far simpler and more intuitive.

>> In addition to that, activities.el provides a mode to automatically save
>> an activity's last window configuration in addition to its default.
> 
> Not sure what "in addition to its default" is about, but desktop.el
> also saves the current session regularly and automatically (see
> desktop-auto-save-timeout).

desktop.el allows a single desktop to be active at one time.

activities.el allows any number of activities to be active.

As well, activities.el does not "enforce" its paradigm upon the user, 
which means that frames/tabs that are not associated with an activity 
are left alone.

>> And it provides integration with tab-bar-mode, as well as other
>> conveniences and interactive commands.
> 
> Is that missing from desktop.el?  If so, can you tell what is missing?

desktop.el supports tab-bar-mode in one sense only: when it restores a 
frame containing a tab-bar, it enables tab-bar-mode.

activities.el supports tab-bar-mode more directly with 
activities-tabs-mode: activities are restored to and associated with 
tab-bar tabs.

>> Finally, activities.el is designed to be independent of other
>> features and co-exist with them, avoiding interference with other
>> libraries.  It's only a few days old, but is based on another
>> library of mine; I intend to continue developing it with user
>> feedback to allow further extension and integration with other
>> tools.
> 
> I wish people would extend existing features instead of reinventing
> them from scratch.  Would you perhaps consider extending desktop.el to
> add whatever you think is missing there?  If not, why not?

I generally agree with you.  However, desktop.el is a library nearly 
twice the size of activites.el and dating back 30 years.  It does many 
things that are now better served by other libraries (e.g. restoring 
variables' values is covered by tools like savehist.el).  It is 
complicated and full of anachronisms (like its own bespoke code to write 
variables and values to files with `setq' forms).  It would take much 
longer to refactor desktop.el to do what activities.el does, and 
impractical to do so while preserving its existing UI, which users have 
used for decades (not to mention the inevitable many hours of bug and 
compatibility fixing which such refactoring would entail).

activities.el is intended to be an alternative to desktop.el.  It is 
inspired by other software systems.  It's not intended to follow any of 
desktop.el's paradigms.

As well, I put this together in a few days, based on research done in 
some of my other packages over the last few years.  It's simple and 
seems to work well, and is designed in an extensible, flexible way.  A 
project to refactor desktop.el to encompass similar changes would be 
more than I have the time or interest to work on.

So I would like to add activities.el to ELPA as-is.

Thanks,
Adam