From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: activities Date: Fri, 26 Jan 2024 15:59:20 -0600 Message-ID: <3c51c1aa-ebe5-4dd3-b7cd-a12c972cee12@alphapapa.net> References: <86frykbksh.fsf@gnu.org> <8634ukb7hv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20461"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 26 23:00:26 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rTUFN-00053q-Hk for ged-emacs-devel@m.gmane-mx.org; Fri, 26 Jan 2024 23:00:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTUEV-0004ye-Vk; Fri, 26 Jan 2024 16:59:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTUES-0004yO-Ct for emacs-devel@gnu.org; Fri, 26 Jan 2024 16:59:28 -0500 Original-Received: from seahorse.cherry.relay.mailchannels.net ([23.83.223.161]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTUEP-0001ri-Mp; Fri, 26 Jan 2024 16:59:28 -0500 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C32E2541B49; Fri, 26 Jan 2024 21:59:22 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a316.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 64090541C6E; Fri, 26 Jan 2024 21:59:22 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1706306362; a=rsa-sha256; cv=none; b=yfDJ07rMWBfOxgPntbqKoas8sxCLUtr/dtknJ0f5VIjutDZ5Vv8PysthHR0Go3qJUYe0Vi B5WUu5ImNmQjXo4XHyrU2fDdixgUv74fn0YMiKIWa3y27o4Xnv6B0wpRj6wLLWarOhuvzR iKOH+6DfYZNrzUEbv+VN8/PZoCc1edeOOesrecFOSWTcouN10kLbLqMRF5A7+PbHutdQtE gWIuuCUOubd/br48Xnwy6wu1njK73ab2pU7HMNc0G12yY/cN3w/lMwHlakGM6Q/iZcFZIk lta2MDZnwgSwhGrRf79cEIBsTQnHZTPLIP8YJ4F0pZFa08IAxBK6RCWVg2EWgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1706306362; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=apucL3gag0qbHUoUDYmNtnUyd1lpYe5tNvrOXHkiFrk=; b=LJLtyFqoL3j+VvLvSfDibIeku0oBqSaPjsEfdd4zudYssOXEAPMi7hL9KL4d3jl0+xgZ9x IKHyswAyh/dgCnPBHKdrQuRTBkZIOxZX+MIRg/5kg8g6mB8F4DQ6G9MZU+HLOMcQgx0Vec hNeoNakCsUev/baPI2XEOM/1wwWh+DKoNA4nt/re3YbvfVMMxIyg+SUGtWh/P3aGus9fGs xEOHzuVBc8DL3PrfMVvrbPUVnnNnVacglO5kH0/wtsMreahcgaXDqahnG7SvD+foAgpznl MCAH/l7+ZMKCHBZp0TJJvByNjbgSuoA640ne4e7eBfAbuxVCnyNRqM16+A9+wQ== ARC-Authentication-Results: i=1; rspamd-9c9494d96-sdwt4; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Language-Fearful: 6db466ea32eb25c5_1706306362650_3018847770 X-MC-Loop-Signature: 1706306362650:462253233 X-MC-Ingress-Time: 1706306362650 Original-Received: from pdx1-sub0-mail-a316.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.127.213.198 (trex/6.9.2); Fri, 26 Jan 2024 21:59:22 +0000 Original-Received: from [10.66.2.86] (unknown [91.193.232.98]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a316.dreamhost.com (Postfix) with ESMTPSA id 4TMBRs6RdVz6g; Fri, 26 Jan 2024 13:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1706306362; bh=apucL3gag0qbHUoUDYmNtnUyd1lpYe5tNvrOXHkiFrk=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=MACRzzlx+KvBSYL6cHhP0DKTZL4oYLLDPR88rT5AInHnu7MAhYn14YVuVndQgHLGW xwxFzxpp7t2IxQcjjHKeam43qT7qR4ExIy9arX6jqQxFjVMiS7VYGVmczxikVinPIv 9YQ9B1eLceu0VNhdqSwVWrKo50osNGgqWd7vZa5pQOh+gL5Q3dbQPS4QL3oQn2ESkf whhKIcvphXdwlsdkvhRtST/b24sr094Dym2sMpRTTQ/BZvxjOyf59nYJjMJhXCU4ge ZEhTORhorcOlruSv6DbXq2cLZ093hYqMDJnv/dyd7p5gvP5Dt6wQAOE2Pn2Uum+ZAl 1tLtFaACtIjwQ== Content-Language: en-US In-Reply-To: <8634ukb7hv.fsf@gnu.org> Received-SPF: neutral client-ip=23.83.223.161; envelope-from=adam@alphapapa.net; helo=seahorse.cherry.relay.mailchannels.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315444 Archived-At: 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 >> >>> 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