[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ELPA] New package: activities
From: |
Adam Porter |
Subject: |
Re: [ELPA] New package: activities |
Date: |
Fri, 26 Jan 2024 15:59:20 -0600 |
User-agent: |
Mozilla Thunderbird |
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
- [ELPA] New package: activities, Adam Porter, 2024/01/25
- Re: [ELPA] New package: activities, Philip Kaludercic, 2024/01/26
- Re: [ELPA] New package: activities, Eli Zaretskii, 2024/01/26
- Re: [ELPA] New package: activities, Adam Porter, 2024/01/26
- Re: [ELPA] New package: activities, Eli Zaretskii, 2024/01/26
- Re: [ELPA] New package: activities,
Adam Porter <=
- Re: [ELPA] New package: activities, Eli Zaretskii, 2024/01/27
- Re: [ELPA] New package: activities, Adam Porter, 2024/01/27
- Re: [ELPA] New package: activities, Eric S Fraga, 2024/01/27
- Re: [ELPA] New package: activities, Eli Zaretskii, 2024/01/27
- Re: [ELPA] New package: activities, Sergey Organov, 2024/01/27
- Re: [ELPA] New package: activities, Eric S Fraga, 2024/01/28
- Re: [ELPA] New package: activities, Sergey Organov, 2024/01/29
- Re: [ELPA] New package: activities, Philip Kaludercic, 2024/01/29
- Re: [ELPA] New package: activities, Sergey Organov, 2024/01/29
- Re: [ELPA] New package: activities, Fraga, Eric, 2024/01/29