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: Sat, 27 Jan 2024 02:46:10 -0600 Message-ID: References: <86frykbksh.fsf@gnu.org> <8634ukb7hv.fsf@gnu.org> <3c51c1aa-ebe5-4dd3-b7cd-a12c972cee12@alphapapa.net> <86cytn9rta.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="4058"; 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 Sat Jan 27 09:47:08 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 1rTeLD-0000rJ-Bp for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jan 2024 09:47:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTeKY-0004kf-1F; Sat, 27 Jan 2024 03:46:26 -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 1rTeKV-0004k8-Py for emacs-devel@gnu.org; Sat, 27 Jan 2024 03:46:23 -0500 Original-Received: from gt-egress-004.relay.mailchannels.net ([172.255.62.11] helo=relay.mailchannels.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTeKQ-0004xc-Cj; Sat, 27 Jan 2024 03:46:21 -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 380D29015A2; Sat, 27 Jan 2024 08:46:12 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a203.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D13C890220B; Sat, 27 Jan 2024 08:46:11 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1706345171; a=rsa-sha256; cv=none; b=gWR8b3PQBRHlrTcJ7x94B8oTaQxXnKhlEGd63X1oQ/4oNQWwMjyHxJJ0ZybyXcDchHEj10 dBTjo9X8xGlaDfn7hE4Zf2T4kaz7vl1iZ//BzGyuYCgqgZBc0L8yWtP1spq+BQWyocm0h/ ESmW0uQpA0sSBR+51fzAhilEAniZ6gwbjhvChYQUsvm7ACteysBkCBZhParBJTvgBF18Wd IbfYnncVbt5sK0c75oBKPdzVijoLBnZNMIGej7TVR8LEOzuCXTicaTM3cgg4lQFrV9eL7M 8vjo/Dg5R2JKzUdN6d1qDlJqjiGht1/5cSFpYgrRnoSvaTPlX02A1X2c3IbCNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1706345171; 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=3LviKJHx5Z++Rd6NAyoHdzQIzhySg/mPoPipdnx09qA=; b=fHhJdt+K50q7S9CsPWp0fUB+fH5zixcTgV3b9QVODqiluFIyqis+CGd9ipMxuEDYUsarR+ Sp/FvvIMrppgY1pWskjVXwWFY69w82pxFBQjM9mtG5gufATK1aIHmkjYzbq7SBBSrOSRft aYawYlokPzydgBz7Xc5tX2fWMXsrt6xGFAt1A+4ZYzOu2nSzPjasxMTfBpV9A0APVA6qP2 dbEzPuH6SzNIAklVftd9+VrUmzyt6mvfo7sntbn455HTt9Oqs/h8b/SOQvxjPkvWnPZ+xQ sJo975X8MfsFWCA7VsJlIBkZ0geeXpZgOPkTquP7t2xB9VhnUx1CI0q1TuAjFw== ARC-Authentication-Results: i=1; rspamd-6fdd97fffb-cml8d; 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-Thread-Decisive: 061c083f33933673_1706345172092_2015387155 X-MC-Loop-Signature: 1706345172092:2664349438 X-MC-Ingress-Time: 1706345172092 Original-Received: from pdx1-sub0-mail-a203.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.110.105.71 (trex/6.9.2); Sat, 27 Jan 2024 08:46:12 +0000 Original-Received: from [10.43.3.134] (unknown [193.56.116.15]) (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-a203.dreamhost.com (Postfix) with ESMTPSA id 4TMSpC2fDkz3J; Sat, 27 Jan 2024 00:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1706345171; bh=3LviKJHx5Z++Rd6NAyoHdzQIzhySg/mPoPipdnx09qA=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=OI3gR5TjzQTISUXqFSMLcLkaNJktjm4d39d/PNuHDtZLvCZZoNUbmxjdiGahv3yb5 eTpzQQRyPmNheS+8Ui8DLz4LPA3pmEwP5jlPld5zGspGxZND+5LF2XIyuLb3DYmKAb 46PP6ttunW+QLhRdBL7QCyjXMsCkb6RAQmYfJK8xYb/D9U0arKOymmxaLI8vyo9lD3 bYTI2Jxk54Ja/RBx0effNzXe9TsRg2Om8ZBRu2leuY3fhY/t46X1/NHsuX9vGY7m8V /6Tcl/rperyBvZsv84NBZVr4zMc/bpoIWN2IFwYyuNcTWriayHNbK9sZ69sZG5v0Va eCGuldmWlLBlQ== Content-Language: en-US In-Reply-To: <86cytn9rta.fsf@gnu.org> Received-SPF: neutral client-ip=172.255.62.11; envelope-from=adam@alphapapa.net; helo=relay.mailchannels.net X-Spam_score_int: -2 X-Spam_score: -0.3 X-Spam_bar: / X-Spam_report: (-0.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, FORGED_SPF_HELO=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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:315471 Archived-At: 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