[ELPA] New package: activities

[ELPA] New package: activities

[Adam Porter]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

Hi,

I'd like to add a new package to ELPA, activities.el.  It's hosted at:

   https://github.com/alphapapa/activities.el

Here's the description; please see the readme/manual for more details.

   Inspired by Genera's and KDE's concepts of "activities", this library 
allows the user to select an "activity", the loading of which restores a 
window configuration and/or frameset, along with the buffers shown in 
each window.  Saving an activity saves the state for later restoration. 
Switching away from an activity saves the last-used state for later 
switching back to, while still allowing the activity's initial or 
default state to be restored on demand.  Resuming an activity loads the 
last-used state, or the initial/default state when a universal argument 
is provided.

   The implementation uses the bookmark system to save buffers' 
states–that is, any major mode that supports the bookmark system is 
compatible.  A buffer whose major mode does not support the bookmark 
system (or does not support it well enough to restore useful state) is 
not compatible and can't be fully restored, or perhaps not at all; but 
solving that is as simple as implementing bookmark support for the mode, 
which is usually trivial.

   Integration with Emacs's `tab-bar-mode' is provided: a window 
configuration or frameset can be restored to a window or set of frames, 
or to a tab or set of tabs.

   Various hooks are (or will be–feedback is welcome) provided, both 
globally and per-activity, so that the user can define functions to be 
called when an activity is saved, restored, or switched from/to.  For 
example, this could be used to limit the set of buffers offered for 
switching to within an activity, or to track the time spent in an activity.

Please see the attached patch to elpa-packages.

Thanks,
Adam

[-- Attachment #2: 0001-elpa-packages-activities-New-package.patch --]
[-- Type: text/x-patch, Size: 730 bytes --]

From 96e673cb20366758e4b928f72e7a1491039fa635 Mon Sep 17 00:00:00 2001
From: Adam Porter <adam@alphapapa.net>
Date: Thu, 25 Jan 2024 18:53:38 -0600
Subject: [PATCH] elpa-packages (activities): New package

---
 elpa-packages | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index c73e8a066b..c77b650592 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -35,6 +35,9 @@
 
 ((ace-window		:url "https://github.com/abo-abo/ace-window")
  (ack			:url "https://github.com/leoliu/ack-el")
+ (activities           	:url "https://github.com/alphapapa/activities.el.git"
+   :release-branch "stable"
+   :doc "README.org")
  (ada-mode		:url nil
   :doc ("ada-mode.texi")
   :release-branch t)
-- 
2.30.2

Re: [ELPA] New package: activities

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

> Hi,
>
> I'd like to add a new package to ELPA, activities.el.  It's hosted at:

Nice name ;)

>   https://github.com/alphapapa/activities.el

I don't have much to add on the code, just that if you are depending on
Emacs 29, you might be able to use `define-multisession-variable'
instead of having to depend on persist?

[...]

> + (activities           	:url "https://github.com/alphapapa/activities.el.git"
> +   :release-branch "stable"
> +   :doc "README.org")

There is no need to track the .info file in the repository, the build
server will generate that from :doc and overwrite it anyway.

Re: [ELPA] New package: activities

[Adam Porter]

Hi Philip,

On 1/26/24 01:33, Philip Kaludercic wrote:
> Adam Porter <adam@alphapapa.net> writes:
> 
>> Hi,
>>
>> I'd like to add a new package to ELPA, activities.el.  It's hosted at:
> 
> Nice name ;)

Well, I can't take credit for it, as I was inspired by similar projects 
outside of Emacsland.  :)

>>    https://github.com/alphapapa/activities.el
> 
> I don't have much to add on the code, just that if you are depending on
> Emacs 29, you might be able to use `define-multisession-variable'
> instead of having to depend on persist?

Unfortunately, I spent several hours trying to make `multisession' work 
before I ended up filing this bug on it: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68482  Thankfully, 
`persist' works perfectly.

>> + (activities           	:url "https://github.com/alphapapa/activities.el.git"
>> +   :release-branch "stable"
>> +   :doc "README.org")
> 
> There is no need to track the .info file in the repository, the build
> server will generate that from :doc and overwrite it anyway.

I understand, but having the Info file in the repository allows it to be 
installed with tools like Quelpa.

Thanks,
Adam

Re: [ELPA] New package: activities

[Adam Porter]

Hi Philip,

Is there anything else I need to do before activities.el can be added to 
GNU ELPA?  The activities.info file is already in the .elpaignore file, 
which I think should cover your feedback.

Thanks,
Adam

Re: [ELPA] New package: activities

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

> Hi Philip,
>
> Is there anything else I need to do before activities.el can be added
> to GNU ELPA?  The activities.info file is already in the .elpaignore
> file, which I think should cover your feedback.

Nothing, it's just the end of my semester, so I have slight difficulties
catching up to my non-uni backlog :)

Regardless, I've added your package specification, and it should appear
shortly on the archive.

> Thanks,
> Adam

Re: [ELPA] New package: activities

[Adam Porter]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

Thanks, Philip!

--Adam

On Tue, Jan 30, 2024, 01:16 Philip Kaludercic <philipk@posteo.net> wrote:

> Adam Porter <adam@alphapapa.net> writes:
>
> > Hi Philip,
> >
> > Is there anything else I need to do before activities.el can be added
> > to GNU ELPA?  The activities.info file is already in the .elpaignore
> > file, which I think should cover your feedback.
>
> Nothing, it's just the end of my semester, so I have slight difficulties
> catching up to my non-uni backlog :)
>
> Regardless, I've added your package specification, and it should appear
> shortly on the archive.
>
> > Thanks,
> > Adam
>

[-- Attachment #2: Type: text/html, Size: 1154 bytes --]

Re: [ELPA] New package: activities

[Eli Zaretskii]

> Date: Thu, 25 Jan 2024 18:59:42 -0600
> From: Adam Porter <adam@alphapapa.net>
> 
> I'd like to add a new package to ELPA, activities.el.  It's hosted at:
> 
>    https://github.com/alphapapa/activities.el
> 
> Here's the description; please see the readme/manual for more details.
> 
>    Inspired by Genera's and KDE's concepts of "activities", this library 
> allows the user to select an "activity", the loading of which restores a 
> window configuration and/or frameset, along with the buffers shown in 
> each window.  Saving an activity saves the state for later restoration. 
> Switching away from an activity saves the last-used state for later 
> switching back to, while still allowing the activity's initial or 
> default state to be restored on demand.  Resuming an activity loads the 
> last-used state, or the initial/default state when a universal argument 
> is provided.

From the user-facing POV, how is this different from desktop.el's
ability to save/restore Emacs sessions to/from separate desktop files?

Thanks.

Re: [ELPA] New package: activities

[Adam Porter]

Hi Eli,

On 1/26/24 01:45, Eli Zaretskii wrote:
>> Date: Thu, 25 Jan 2024 18:59:42 -0600
>> From: Adam Porter <adam@alphapapa.net>
>>
>> I'd like to add a new package to ELPA, activities.el.  It's hosted at:
>>
>>     https://github.com/alphapapa/activities.el
>>
>> Here's the description; please see the readme/manual for more details.
>>
>>     Inspired by Genera's and KDE's concepts of "activities", this library
>> allows the user to select an "activity", the loading of which restores a
>> window configuration and/or frameset, along with the buffers shown in
>> each window.  Saving an activity saves the state for later restoration.
>> Switching away from an activity saves the last-used state for later
>> switching back to, while still allowing the activity's initial or
>> default state to be restored on demand.  Resuming an activity loads the
>> last-used state, or the initial/default state when a universal argument
>> is provided.
> 
>  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.  As well, it is not intended to be used on-demand to switch 
between sets of buffers, windows, or frames (i.e. "activities").

In addition to that, activities.el provides a mode to automatically save 
an activity's last window configuration in addition to its default.  And 
it provides integration with tab-bar-mode, as well as other conveniences 
and interactive commands.  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.

Thanks,
Adam

Re: [ELPA] New package: activities

[Eli Zaretskii]

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

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

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

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

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

Thanks.

Re: [ELPA] New package: activities

[Adam Porter]

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

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.

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

Re: [ELPA] New package: activities

[Eric S Fraga]

As a very (and I do mean very) long time user, I would like to comment
on this thread.  I hope that's okay despite the fact that I do not
contribute much to the actual code in emacs.

I have never found desktop.el to be useful.  I do not start emacs from
different directories so find the whole idea of a desktop counter to my
use case.  I start emacs and then use it for days, working on different
completely unrelated projects or activities (teaching, coding, writing,
admin, email, whatever).  Emacs, these days, is usually also my window
manager (exwm).

The proposed activities package (which I have not yet had time to try)
appeals, given its description.  And that appeal would increase further
were it integrated or linked with project.el as the latter is more
sympathetic with how I use emacs.  I'm sure I'm not the only one that
works this way.  The power of Emacs is that it works for so many
different people and allows one to use it the way you want it, not the
other way around.

Building on top of desktop.el seems, to me, to be using the wrong
starting point.  If you believe that new packages should somehow build
on existing packages, then start with project.el which is more aligned
to the proposed package.  I would love to be able to type

C-x p p <choose project> a

with "a" for activity, say, taking me back to where I was last with that
project.

I'll go back to lurking now. ;-)

Thank you,
eric

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2

Re: [ELPA] New package: activities

[Eli Zaretskii]

> From: Eric S Fraga <e.fraga@ucl.ac.uk>
> Date: Sat, 27 Jan 2024 14:53:21 +0000
> 
> As a very (and I do mean very) long time user, I would like to comment
> on this thread.  I hope that's okay despite the fact that I do not
> contribute much to the actual code in emacs.
> 
> I have never found desktop.el to be useful.  I do not start emacs from
> different directories so find the whole idea of a desktop counter to my
> use case.  I start emacs and then use it for days, working on different
> completely unrelated projects or activities (teaching, coding, writing,
> admin, email, whatever).  Emacs, these days, is usually also my window
> manager (exwm).
> 
> The proposed activities package (which I have not yet had time to try)
> appeals, given its description.  And that appeal would increase further
> were it integrated or linked with project.el as the latter is more
> sympathetic with how I use emacs.  I'm sure I'm not the only one that
> works this way.  The power of Emacs is that it works for so many
> different people and allows one to use it the way you want it, not the
> other way around.
> 
> Building on top of desktop.el seems, to me, to be using the wrong
> starting point.

If you don't consider desktop.el useful and don't use it, then,
indeed, whether activities.el is a compatible extension of desktop.el
or a completely new package developed from ground up on a different
basis should be of no importance for you.  My worries are for people
who do use desktop.el and might also be interested in the features
offered by activities.el that are not currently present in desktop.el.

Re: [ELPA] New package: activities

[Sergey Organov]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:


[...]

> I have never found desktop.el to be useful.  I do not start emacs from
> different directories so find the whole idea of a desktop counter to my
> use case.  I start emacs and then use it for days, working on different
> completely unrelated projects or activities (teaching, coding, writing,
> admin, email, whatever).  Emacs, these days, is usually also my window
> manager (exwm).

That's how I use Emacs as well, yet I've built a package based on
deskstop.el and session.el a long time ago that I've called desksess.el,
and I'm still using it.

[...]

> Building on top of desktop.el seems, to me, to be using the wrong
> starting point.

Maybe, maybe not. It was much easier for me to glue two existing
packages together using a bit of simple code than to re-invent the
wheel. Yes, it overrides desktop.el's idea of where to get desktop
files, and which file to load, but that's only a little bit of gluing on
top of rather big package.

> If you believe that new packages should somehow build
> on existing packages, then start with project.el which is more aligned
> to the proposed package.  I would love to be able to type
>
> C-x p p <choose project> a

C-c d l <project>

in my case

C-c d l runs the command desksess-load

>
> with "a" for activity, say, taking me back to where I was last with that
> project.

Exactly how desksess.el works, and it loads last visited desktop on
startup, no matter what is current directory.

-- 
Sergey Organov

Re: [ELPA] New package: activities

[Eric S Fraga]

On Saturday, 27 Jan 2024 at 19:14, Sergey Organov wrote:
> That's how I use Emacs as well, yet I've built a package based on
> deskstop.el and session.el a long time ago that I've called desksess.el,
> and I'm still using it.

Interesting.  Are you able to share?

Thank you,
eric
-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2

Re: [ELPA] New package: activities

[Sergey Organov]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Saturday, 27 Jan 2024 at 19:14, Sergey Organov wrote:
>> That's how I use Emacs as well, yet I've built a package based on
>> deskstop.el and session.el a long time ago that I've called desksess.el,
>> and I'm still using it.
>
> Interesting.  Are you able to share?

Sure,

https://drive.google.com/file/d/1U3TKybt8f7eiOGpyeoW_gFE8dDkFtASf/view?usp=sharing

-- Sergey Organov

Re: [ELPA] New package: activities

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

Sergey Organov <sorganov@gmail.com> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Saturday, 27 Jan 2024 at 19:14, Sergey Organov wrote:
>>> That's how I use Emacs as well, yet I've built a package based on
>>> deskstop.el and session.el a long time ago that I've called desksess.el,
>>> and I'm still using it.
>>
>> Interesting.  Are you able to share?
>
> Sure,
>
> https://drive.google.com/file/d/1U3TKybt8f7eiOGpyeoW_gFE8dDkFtASf/view?usp=sharing

I hope you don't mind me reposting the code here, because I know that
many here won't be able or willing to follow that link:


[-- Attachment #2: desksess.el --]
[-- Type: application/emacs-lisp, Size: 25563 bytes --]

Re: [ELPA] New package: activities

[Sergey Organov]

Philip Kaludercic <philipk@posteo.net> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>>
>>> On Saturday, 27 Jan 2024 at 19:14, Sergey Organov wrote:
>>>> That's how I use Emacs as well, yet I've built a package based on
>>>> deskstop.el and session.el a long time ago that I've called desksess.el,
>>>> and I'm still using it.
>>>
>>> Interesting.  Are you able to share?
>>
>> Sure,
>>
>> https://drive.google.com/file/d/1U3TKybt8f7eiOGpyeoW_gFE8dDkFtASf/view?usp=sharing
>
> I hope you don't mind me reposting the code here, because I know that
> many here won't be able or willing to follow that link:

Yep, sure! I rather thought attachment might cause a problem on the
list.

Thanks,
-- Sergey Organov

Re: [ELPA] New package: activities

[Fraga, Eric]

Thank you.  I'll have a look.
-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-07-11) on Debian bullseye/sid

Re: [ELPA] New package: activities

[Eshel Yaron]

Hello,

Adam Porter <adam@alphapapa.net> writes:

> Hi,
>
> I'd like to add a new package to ELPA, activities.el.  It's hosted at:
>
>   https://github.com/alphapapa/activities.el

Look interesting!

FWIW, I think a spot a small mistake in `activities-completing-read`:
passing the value of the history variable to `completing-read` instead
of the variable name.  Also, it seems like the commands that use this
function expect an existing "activity", so would it make sense to accept
only matching inputs?  That is, making the following change:

diff --git a/activities.el b/activities.el
index 60bbcaf..8ea687b 100644
--- a/activities.el
+++ b/activities.el
@@ -638,7 +638,7 @@ (cl-defun activities-completing-read
   "Return an activity read with completion from ACTIVITIES.
 PROMPT is passed to `completing-read', which see."
   (let* ((names (activities-names activities))
-         (name (completing-read prompt names nil nil nil activities-completing-read-history)))
+         (name (completing-read prompt names nil t nil 'activities-completing-read-history)))
     (or (map-elt activities-activities name)
         (make-activities-activity :name name))))

Re: [ELPA] New package: activities

[Adam Porter]

Hi Eshel,

> FWIW, I think a spot a small mistake in `activities-completing-read`:
> passing the value of the history variable to `completing-read` instead
> of the variable name.  Also, it seems like the commands that use this
> function expect an existing "activity", so would it make sense to accept
> only matching inputs?  That is, making the following change:

Thanks for catching those.  I pushed a fix and mentioned you in the 
commit message.

--Adam

Re: [ELPA] New package: activities

[JD Smith]

> On Jan 25, 2024, at 7:59 PM, Adam Porter <adam@alphapapa.net> wrote:
> 
> Hi,
> 
> I'd like to add a new package to ELPA, activities.el.  It's hosted at:
> 
>  https://github.com/alphapapa/activities.el
> 
> Here's the description; please see the readme/manual for more details.


I've given activities a try and am very impressed.  None of desktop.el/framesets/burly/bufler ever stuck for me.  And project.el is great but many activities span projects.  Activities is literally already a one key interface for me: <f10> to jump to an activity from anywhere, C-<f10> to revert the current one (OK two keys).  I think people are going to love it, and I can very much imagine it migrating to core someday.  Strong support for including in ELPA.  

PS: I personally feel that by the time a package author presents a well-written and fairly complete package for inclusion into ELPA, it is too late to make the argument that they should have instead contributed that functionality to a built-in package.  If you can convince them earlier in the process, of course, but it certainly adds to the outside impression that ELPA is a gauntlet that must be run, which I think all agree is not desired.

Re: [ELPA] New package: activities

[Chris Van Dusen]

> On Jan 29, 2024, at 15:49, JD Smith <jdtsmith@gmail.com> wrote:
> 
> 
> 
> PS: I personally feel that by the time a package author presents a well-written and fairly complete package for inclusion into ELPA, it is too late to make the argument that they should have instead contributed that functionality to a built-in package.  If you can convince them earlier in the process, of course, but it certainly adds to the outside impression that ELPA is a gauntlet that must be run, which I think all agree is not desired.

I’m not sure I follow. Most of the time package authors don’t ssy anything until they want to publish the package, so how can the maintainers suggest to them to contribute to  an existing package?

An alternative would be for potential package authors to post to emacs-devel, stating that they would like to see feature foo in package bar.  If it turns out that it is not feasible to implement the feature, then sure, a new package can be created. 

Chris. 

Re: [ELPA] New package: activities

[Adam Porter]

On 1/29/24 18:08, Chris Van Dusen wrote:

>> PS: I personally feel that by the time a package author presents a well-written and fairly complete package for inclusion into ELPA, it is too late to make the argument that they should have instead contributed that functionality to a built-in package.  If you can convince them earlier in the process, of course, but it certainly adds to the outside impression that ELPA is a gauntlet that must be run, which I think all agree is not desired.
> 
> I’m not sure I follow. Most of the time package authors don’t ssy anything until they want to publish the package, so how can the maintainers suggest to them to contribute to  an existing package?
> 
> An alternative would be for potential package authors to post to emacs-devel, stating that they would like to see feature foo in package bar.  If it turns out that it is not feasible to implement the feature, then sure, a new package can be created.

Please don't forget the possibility that the author has already 
considered and rejected the idea to modify an existing library.  I 
reached this decision over 3 years ago, before I started working on 
burly.el, which has led me to finally develop activities.el.  Sometimes 
it is best to start with a fresh perspective, rather than trying to 
shoehorn ideas into an existing framework.

Re: [ELPA] New package: activities

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I’m not sure I follow. Most of the time package authors don’t
  > > ssy anything until they want to publish the package, so how can
  > > the maintainers suggest to them to contribute to an existing
  > > package?
  > > 
  > > An alternative would be for potential package authors to post to
  > > emacs-devel, stating that they would like to see feature foo in
  > > package bar.  If it turns out that it is not feasible to
  > > implement the feature, then sure, a new package can be created.

  > Please don't forget the possibility that the author has already 
  > considered and rejected the idea to modify an existing library.  I 
  > reached this decision over 3 years ago, before I started working on 
  > burly.el, which has led me to finally develop activities.el.  Sometimes 
  > it is best to start with a fresh perspective, rather than trying to 
  > shoehorn ideas into an existing framework.

First, I have no opinions about what to do with activities.el in
particular.  It could potentially be useful for many users, but it
probably won't be useful for me on a Linux console.  It doesn't seem
to affect Emacs at a deeper level.  So I decided to leave its design
issues to others.  I'm writing only about this broader question.

I am glad that you first considered adding the feature to an existing
package.  Thinking about that was a wise thing to do.

You reached the conclusion that it was better to make a new, separate
package.  Maybe that is right.  (I don't know the details so I have no
opinion about it.)

Nonetheless, it would be good if everyone considering a new feature
were to ask for advice on emacs-devel about the best way to implement
it before starting to write it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [ELPA] New package: activities

[JD Smith]

> On Jan 29, 2024, at 7:08 PM, Chris Van Dusen <cavandusen@gmail.com> wrote:
> 
>> On Jan 29, 2024, at 15:49, JD Smith <jdtsmith@gmail.com> wrote:
>> 
>> PS: I personally feel that by the time a package author presents a well-written and fairly complete package for inclusion into ELPA, it is too late to make the argument that they should have instead contributed that functionality to a built-in package.  If you can convince them earlier in the process, of course, but it certainly adds to the outside impression that ELPA is a gauntlet that must be run, which I think all agree is not desired.
> 
> I’m not sure I follow.  Most of the time package authors don’t ssy anything until they want to publish the package, so how can the maintainers suggest to them to contribute to  an existing package?

That's a different issue than how to receive new packages with advancements that might have, in an alternate Universe, been contributed to core.   But it's a fair point.

I'm not sure I have a solution to the chicken and egg problem.  Advertising "low-hanging fruit" capabilities that core packages need, and providing starter packs for aspiring package developers?   Perhaps with the explicit offer of the occasional core developer's ear for questions?  I mean the quality of answers here is usually off-scale good.

> An alternative would be for potential package authors to post to emacs-devel, stating that they would like to see feature foo in package bar.  If it turns out that it is not feasible to implement the feature, then sure, a new package can be created.

I could also imagine a yearly "meet and greet with core developers" type of event, where new ideas get passed around, people talk about the packages they'd love to build next, and others in the know can mention how those may relate to or potentially extend core packages.  An old-fashioned spit-balling session.

Re: [ELPA] New package: activities

[Drew Adams]

Just one comment about desktop.el, FWIW.

I've said this more than once over the
decades, but I'll mention it again since
the question of desktop files being limited
by being directory-based has come up again
in this thread (as only one small part of
this thread).

There's no reason desktop files should be
limited in this way.  You should be able to
have multiple desktop files in a directory.
There's no necessary relation between a
desktop file and any particular directory.

It's a design bug, IMO.

I fixed this long ago, in order to let you
bookmark desktops flexibly.  A trivial fix
lets you load an arbitrary desktop file.

This 2019 post covers this, but there are
likely older posts by me that do the same:

https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00571.html

Here again is the code that fixes this
design oversight, FWIW:

(defun bmkp-desktop-save (desktop-file)
  "Save current desktop in DESKTOP-FILE."
  (let ((desktop-base-file-name
         (file-name-nondirectory desktop-file))
        (desk-dir
         (file-name-directory desktop-file))
        (desktop-restore-eager  t)) ; Don't bother w/ lazy.
    (desktop-save desk-dir 'RELEASE 'AUTOSAVE)))

;; Derived from code in `desktop-read'.
;;
 (defun bmkp-desktop-read (file)
  "Load desktop-file FILE, then run `desktop-after-read-hook'.
Return t if FILE was loaded, nil otherwise."
  (interactive)
  (when (file-directory-p file)
    (error "`%s' is a directory, not a file" file))
  (setq desktop-dirname  (file-name-directory file))
  (if (not (file-readable-p file))
      nil ; Return nil: not loaded.
    (let ((desktop-restore-eager      t) ; Don't bother w/ lazy.
          (desktop-first-buffer       nil)
          (desktop-buffer-ok-count    0)
          (desktop-buffer-fail-count  0)
          ;; Prevent desktop-saving for eval of desktop buffer.
          (desktop-save               nil))
      (desktop-lazy-abort)
      (load file t t t)
      (setq desktop-file-modtime (nth 5 (file-attributes file)))
      (mapc 'bury-buffer
            (nreverse (cdr (memq desktop-first-buffer
                                 (nreverse (buffer-list))))))
      (switch-to-buffer (car (buffer-list)))
      (run-hooks 'desktop-delay-hook)
      (setq desktop-delay-hook  ())
      (run-hooks 'desktop-after-read-hook)
      (message "Desktop: %d buffer%s restored%s%s."
               desktop-buffer-ok-count
               (if (= 1 desktop-buffer-ok-count) "" "s")
               (if (< 0 desktop-buffer-fail-count)
                   (format ", %d failed to restore"
                           desktop-buffer-fail-count)
                 "")
               (if desktop-buffer-args-list
                   (format ", %d to be restored lazily"
                           (length desktop-buffer-args-list))
                 ""))
      t))) ; Return t: successfully loaded.

Re: [ELPA] New package: activities

[Joseph Turner]

Hello!

I find activities.el's ideas and its implementation useful.

I'm glad ELPA accepts packages that overlap with core functionality.

With activities.el available on ELPA, I wonder if it's more likely that
someone will find it, appreciate its ideas, and extend desktop.el.

Everybody wins :)

Thank you!!

Joseph