From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Manuel Giraud Newsgroups: gmane.emacs.devel Subject: Re: [External] : [emacs bookmark.el] Sorting by last set Date: Sun, 05 Jun 2022 22:53:11 +0200 Message-ID: <875yle7ryg.fsf@elite.giraud> References: <875ylhvu4k.fsf@red-bean.com> <87a6ar84rn.fsf@elite.giraud> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21612"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) Cc: Karl Fogel , Lars Ingebrigtsen , Stefan Monnier , emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 05 22:55:20 2022 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 1nxxHM-0005Ta-5j for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jun 2022 22:55:20 +0200 Original-Received: from localhost ([::1]:43040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nxxHK-00021f-Ls for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jun 2022 16:55:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47096) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxxFP-0000XQ-IG for emacs-devel@gnu.org; Sun, 05 Jun 2022 16:53:19 -0400 Original-Received: from ledu-giraud.fr ([51.159.28.247]:21048) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxxFN-0003A1-5z for emacs-devel@gnu.org; Sun, 05 Jun 2022 16:53:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=v2fsvkxv1OvIbqPn 9T8GRMAKoOhEykvNFtEHtauzm4U=; h=in-reply-to:date:references:subject: cc:to:from; d=ledu-giraud.fr; b=TYedcu+WOtDybu679/91h9hSJ2CnDqTwbEngqZ HoDvmtoW8gfcMGhtC2m2VSKrupByQU8pTYY/i5aVzWkPvUlFgCLn2LX5By2pi32McwrM87 Wbriv13yKNIN73kRmHEFpkd3jlQNX8HuUPDjGyG/Njg6qT8ilOOM05x8iaAiLw8I+Mxlpe yEqueXMBYXhMHnAftz6DwrT6aC+8wygSYcsNdSCJwJ/uWatGIH1CcWKRyNwvps+dirvpI4 FVar0K3NwJM4XYHU7N0wgJLNZlnY5RHYF/1ROeSBMU4gqnFgkbw4sCLgRAfePArvcS0YeC CDNC5Btz/0rhS/5Y1mjYORdg== Original-Received: from elite.giraud ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id cf92c167 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 5 Jun 2022 22:53:14 +0200 (CEST) In-Reply-To: (Drew Adams's message of "Sun, 5 Jun 2022 17:33:50 +0000") Received-SPF: pass client-ip=51.159.28.247; envelope-from=manuel@ledu-giraud.fr; helo=ledu-giraud.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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" Xref: news.gmane.io gmane.emacs.devel:290747 Archived-At: Drew Adams writes: > I can't speak to whatever behavior you've > currently implemented. > > But why would _setting_ a bookmark be the only > modification that you want reflected in such a > property? > > And does this "setting" include RE-setting or > just initial setting (which I guess is about > the same as creating)? Hi, It works for this "setting" and RE-"setting" but not for annotations change nor renaming. Maybe "set" is not a good name. Why not "placed"? As a bookmark in book? [...] > But even just an annotation edit is a change, > and it might well be significant for a user. > Let's not belittle modification other than > setting. You're right and that is why it should be clear that this behaviour is for "placing" the bookmark only. Maybe other kind of modified field could be add later... or the current behaviour changed along with its documentation. > If you're going to introduce a last-modified > time property of some sort, I'd suggest that, > by default at least, it be updated for any > change to the bookmark - maybe even automatic > repositioning. > > But including automatic repositioning could > be a user decision (e.g., a user option, off > by default. Better is to have a (list value) > option that can cover all predefined kinds of > modification. A fully customizable "last-modified" sorting might be a bit too much for bookmark.el but trying to gather many modifications under one umbrella could be better than just "placed". What others think? For my usage, I prefer the "placed only" behaviour. [...] >> Why not... but we have to settle for good symbol names. I propose >> 'last-created (as nil) and 'alphabetical (as t). > > Would you please use `created', the same field > name that Bookmark+ uses? Occam's razor says > not to complicate things gratuitously. Why > not use the same name, for the same thing? > > There's only one creation of a given bookmark. > It makes no sense to talk of a "last" creation > time. Yes of course. But in what I proposed, 'created would only be a possible symbol for `bookmark-sort-flag' (or new name), nothing more. >> I prefer `bookmark-sort'. > > Please see what I wrote in my previous message, > if for no reason other than it provides useful > food for thought. I've read it. But I think that for the bundled bookmark.el having a predefined set of sorting functions could be enough. As for composability of sorting, I think keeping it to "one at a time" could also be enough. And for users that need more there is Bookmark+ Best regards, -- Manuel Giraud