From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: activities Date: Sat, 27 Jan 2024 09:08:33 +0200 Message-ID: <86cytn9rta.fsf@gnu.org> References: <86frykbksh.fsf@gnu.org> <8634ukb7hv.fsf@gnu.org> <3c51c1aa-ebe5-4dd3-b7cd-a12c972cee12@alphapapa.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35801"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 27 08:09:29 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 1rTcoj-000986-L2 for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jan 2024 08:09:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTcnt-0002tx-PE; Sat, 27 Jan 2024 02:08:37 -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 1rTcns-0002tp-CG for emacs-devel@gnu.org; Sat, 27 Jan 2024 02:08:36 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTcnr-0005y0-U8; Sat, 27 Jan 2024 02:08:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Jym0eB6uXOvV6aHzeL9CFDM3lA/wjuXrTLBRBUDMVPg=; b=enLYyf6p0EIx bPrFnjEa3uc+xEgDqfFrcap6VLPWNlplYGP3VWMitJG2/wdtqOl7ye54Ew37dCoHJaySYksbhjYbG akhxHBb3/T7He2wFMdjihq2MZTXSqcU2SvOANnl91ZLUi8UsvvnhEVgkkun/qXfAKve4bOSs03O7Q B/xzrD9HkNgL24fpAtPSGY4ooXzb51J1D0miv8N03ukamAHSNHFZG/1tLHBAWBWiaA6IkGXmUiont ZkNSkY/y4YYzjyJqwd2JQ8hQ/4pvPsFwCjhtAXQu1uLe2585+klQyg1IWszW5EiBqBHBL3aTj/w/+ FIvczOIPNi2ECg23LLdPBQ==; In-Reply-To: <3c51c1aa-ebe5-4dd3-b7cd-a12c972cee12@alphapapa.net> (message from Adam Porter on Fri, 26 Jan 2024 15:59:20 -0600) 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:315466 Archived-At: > Date: Fri, 26 Jan 2024 15:59:20 -0600 > Cc: emacs-devel@gnu.org > From: Adam Porter > > >> 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.