From: Adam Porter <adam@alphapapa.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [ELPA] New package: activities
Date: Sat, 27 Jan 2024 02:46:10 -0600 [thread overview]
Message-ID: <cbac15ae-3716-4073-bc08-6b6057c4f67e@alphapapa.net> (raw)
In-Reply-To: <86cytn9rta.fsf@gnu.org>
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
next prev parent reply other threads:[~2024-01-27 8:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 0:59 [ELPA] New package: activities Adam Porter
2024-01-26 7:33 ` Philip Kaludercic
2024-01-26 10:36 ` Adam Porter
2024-01-29 19:50 ` Adam Porter
2024-01-30 7:16 ` Philip Kaludercic
2024-01-30 7:43 ` Adam Porter
2024-01-26 7:45 ` Eli Zaretskii
2024-01-26 10:42 ` Adam Porter
2024-01-26 12:32 ` Eli Zaretskii
2024-01-26 21:59 ` Adam Porter
2024-01-27 7:08 ` Eli Zaretskii
2024-01-27 8:46 ` Adam Porter [this message]
2024-01-27 14:53 ` Eric S Fraga
2024-01-27 15:32 ` Eli Zaretskii
2024-01-27 16:14 ` Sergey Organov
2024-01-28 11:25 ` Eric S Fraga
2024-01-29 10:45 ` Sergey Organov
2024-01-29 13:03 ` Philip Kaludercic
2024-01-29 22:23 ` Sergey Organov
2024-01-29 15:29 ` Fraga, Eric
2024-01-26 8:25 ` Eshel Yaron
2024-01-26 10:48 ` Adam Porter
2024-01-29 21:48 ` JD Smith
2024-01-30 0:08 ` Chris Van Dusen
2024-01-30 0:24 ` Adam Porter
2024-02-01 3:49 ` Richard Stallman
2024-01-30 2:50 ` JD Smith
-- strict thread matches above, loose matches on Subject: below --
2024-01-27 19:20 Drew Adams
2024-02-01 5:33 Joseph Turner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cbac15ae-3716-4073-bc08-6b6057c4f67e@alphapapa.net \
--to=adam@alphapapa.net \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.