Re: [ELPA] New package: activities

[Eli Zaretskii]

> Date: Fri, 26 Jan 2024 15:59:20 -0600
> Cc: emacs-devel@gnu.org
> From: Adam Porter <adam@alphapapa.net>
> 
> >>     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.

Can you elaborate why you think so?

> 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.

desktop.el sees the current session as a unit, and saves/restores all
of it.  Thus, by definition, there's "only one desktop active" at any
given time.  However, it should be possible to extend desktop.el to
allow the user to specify a subset of the session and give it a name,
so that subsets could be manipulated independently.  IOW, it could be
a natural extension of desktop.el.

> 2. desktop.el works by the unusual concept of choosing a directory in 
> which to save "a desktop file."

It might sound less "unusual" if you think about each directory as a
top-level directory of a separate project.  As one advantage,
integration between desktop.el and project.el, if and when it is
desired, should be a simple matter, AFAIU.

> >> 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.

See above: a natural extension of desktop.el would allow saving
user-specified portions of a session.

> 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.

desktop.el uses frameset.el to save and restore frames.  frameset.el
implements a mechanism for filtering frames that are saved and
restored.  Selective saving can be easily based on that mechanism.

> >> 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.

So this is the same "only one desktop at a time" argument again.

> > 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).

Replace "desktop.el" here with "Emacs", and you get the argument we
see on various forums why stick to Emacs after all those years and all
the cruft Emacs accumulated.  And yet we do stick to it, for very good
reasons.  One of those reasons is that it takes a long time to learn a
sophisticated tool and adapt one's workflows to its concepts, and
therefore extending that tool in compatible ways favors the users by
not requiring them to re-learn the basics and modify the workflows in
significant ways every Monday and Thursday.

> 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).

Yes.  But the users will be benefited much more.  (And I submit that
desktop.el's code is not hard to understand and modify; we have quite
a few packages in Emacs which are much harder to penetrate.)

> 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.

But now users will have a dilemma of which they should have as few as
possible: do I stay with desktop.el or do I switch to activities.el,
pray that it will be actively developed and maintained for years to
come, and re-learn from scratch how to save and restore my session?

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

Of course you would.