Re: [ELPA] New package: activities

[Adam Porter]

Hello Eli,

On 1/27/24 01:08, Eli Zaretskii wrote:

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

"Activities" have no direct relation to directories or project.el-style 
projects (i.e. directories).  Some kind of integration with project.el 
may be possible and is under consideration (feedback welcome).

> > 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 don't know what you mean.  activities.el supports both frame- and 
tab-based activity associations, depending on whether 
activities-tabs-mode is enabled.  Future work is intended to allow 
further, per-activity customization (i.e. having one activity associated 
with a frame, while another is associated with a tab).

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

Like Emacs, desktop.el is decades old and full of cruft.  As often 
happens, a clean-slate design based on some new ideas is developed, and 
the fresh perspective allows further development.

Frankly, I've always found desktop.el to be a morass of confusing 
features, most of which do not support my needs, while it lacks the 
simple functionality I have always desired--which I have designed 
activities.el to perform.  activities.el's concepts are simple and do 
not interfere with other workflows or libraries.

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

I disagree.  A clean-slate design is definitely needed here, especially 
in light of developments in Emacs and its libraries since desktop.el was 
made.  If desktop.el were so refactored and trimmed down, it wouldn't be 
desktop.el anymore--and then would come the bug reports about changed, 
missing, or incompatible functionality.  (I don't know if 
desktop-file-version's value of 208 means that the file format was 
changed 208 times, but regardless, I'm not interested in trying to 
maintain compatibility with that legacy (it even has functionality to 
*downgrade* its file format).)

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

I think that after about 30 seconds of trying each package, users will 
have no problem deciding which is most useful for them.  (Or they may 
find some of desktop.el's features useful in addition to 
activities.el's-, because activities is designed to not interfere with 
any other tools.)

Regarding maintenance: I've been maintaining Emacs packages for about 8 
years, and I've no plans to stop anytime soon.

And there's virtually nothing to learn or re-learn here.  Two commands 
are all that's needed to use it: activities-new to define a new 
activity, and activities-resume to resume one.  The other commands 
provide convenience but are ancillary.  No configuration is required but 
some options are provided.  It has been carefully designed to be as 
simple as possible to use.

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

If you think I have no concern for Emacs's development as a whole, or 
its users, or its long-term design, that is not the case.  I hope that 
after incubating and maturing in ELPA for a few years that activities.el 
may become suitable for inclusion as a core package.  I think it 
provides features that have been missing for decades, not just in Emacs, 
but in personal computing as a whole--but only on a platform like Emacs 
do we really have the chance to rectify these problems.

Having used Emacs for over 10 years myself, it would not be an 
overstatement to say that activities.el is revolutionary to my daily 
use.  Although the implementation is simple, and the UI is as well 
(though I'm always seeking feedback to improve it), the functionality is 
profoundly useful, and it's taken years of development and design to get 
to this point.

So, no, I'm afraid that I'm not interested in refactoring a 30+ year-old 
library that's more than twice the size to provide equivalent 
functionality in addition to everything it already does.  I would like 
rather to add this package to ELPA, begin gathering feedback from wider 
usage, and continue its development.

Thanks,
Adam