From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: On improving Bookmarks Date: Wed, 16 Nov 2022 11:37:52 -0600 Message-ID: <87bkp66brj.fsf@red-bean.com> References: Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="822"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Gabriel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 16 18:38:45 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 1ovMN3-000AXB-AN for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Nov 2022 18:38:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovMMK-00027X-1S; Wed, 16 Nov 2022 12:38:00 -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 1ovMMH-00027L-GH for emacs-devel@gnu.org; Wed, 16 Nov 2022 12:37:57 -0500 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovMMF-0007hN-8x for emacs-devel@gnu.org; Wed, 16 Nov 2022 12:37:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Type:MIME-Version:Message-ID:Date: Reply-To:References:In-Reply-To:Subject:Cc:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ntJ3zL+N0FEI7JLVmt02SnDK9r8C0QkmZpPciMfPHXM=; t=1668620274; x=1669829874; b=LnPRCdNuvMgtuchfVpuJnJv9UP4P1KqymvuSbhL0lkfOPQKjLTpZpgEtvqUo6KNzyEOQbyaKMWI opXsvc+rb0Syot9vFOUfA/q3WiyT/RbvaBmjmB75uLU8DKvZemjNA7l9hvH4BQHrHKAGHN13lOBlL DixWKPDawQAGvYUt3faaPfr1+J9+U60RCJgoO8rnrU8LOyv0btMFazorKt6grCn2nkImt80dkvzlH yhnuK5tvqa7ru9oVRSkfD85urvaFW/Y3X5JRsEHY2DHQrTzJ+NSqa4YFPvrFUHcaESnd2ltsxgPLC IL+9TYFWTgn2h9+CgW5Wvga8NG7ttYUwnqPg==; Original-Received: from [12.106.183.66] (port=58441 helo=hummy) by sanpietro.red-bean.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ovMMD-008BCn-61; Wed, 16 Nov 2022 17:37:53 +0000 In-Reply-To: (Gabriel's message of "Wed, 16 Nov 2022 02:25:20 -0300") Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=sanpietro.red-bean.com 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 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299961 Archived-At: [This is the second part of my reply in this thread. The first part was posted as part of a parallel reply to Bug #59212 and can be seen here: https://mail.gnu.org/archive/html/emacs-devel/2022-11/msg01053.html .] On 16 Nov 2022, Gabriel wrote: >3) Add Type to bookmark-sort-flag > >A simple suggestion to add Type to the choices of >bookmark-sort-flag. +1. I'm not sure how often people would actually use it, but if a column is present, it should be sortable on. >4) Make R (bookmark-relocate) work for all Types > >The R (bookmark-relocate) currently does not seem to work with >Types >other than regular "Files" and "Directories". It causes the >following >error: > >bookmark-relocate: Wrong type argument: stringp, nil > >Would be nice to make it work for all types. I am not sure what >would >be the best way to implement it and the required effort. Perhaps >similar to how VC handles different backends or similar to how >currently >bookmarks handles 'bookmark-handler-type. See also comment from >2010 in >bookmark-location. As a simple remediation in case this change >is not >added to Bookmarks, Emacs could report a better error message for >users, >e.g.: "bookmark-relocate is not supported for type EWW". I think starting by just improving the error would be great. The larger effort can be tackled on a case-by-case basis -- it doesn't have to be all solved all at once. >5) Ability to open Bookmarks with external applications > >Add choice to open bookmarks in Emacs using the default >bookmark-handler-type or using an external application (e.g. open >a PDF >with xdg-open rather than DocView or open an URL with Firefox >rather >than EWW). Not sure what would be the best way to implement it, >though. That's a very interesting idea. +1 to the concept. But does Emacs already have a generic mechanism for saying "open things of type X with program Y"? If so, Bookmark should just rely on that mechanism, rather than have some Bookmark-specific mechanism. And if there isn't such a generic mechanism in Emacs, perhaps it be better to create that than to do something special for Bookmark. >6) Add minibuffer completion details to C-x r b (bookmark-jump) > >A simple suggestion to add minibuffer completion details to >bookmark-jump so users can know, for example, the Type and >Location. It >could be controlled by defcustom completions-detailed. Again, +1 to the concept. >7) Add Tags > >A "simple" feature that would make Bookmarks much more powerful. >In >simple terms, a list of tags would be saved with each bookmark in >bookmark-default-file, and could be used for better filtering and >navigation. Well... I hesitate on this one. Tagging mechanisms often turn out to be half-baked solutions to sets of only partially-related problems. And in the case of bookmarks, we already have a lot of information we could work with, even without tags: * The bookmark's name Its path Its type Its creation date The * front and back context strings I guess I would ask: have you personally encountered situations with your bookmarks where tags would have been the best solution? I.e., is this idea based on directly-experienced need, or is it speculative? On 16 Nov 2022, Matthias Meulien replied to Gabriel: >Let me mention two things I have in my wishlist: > >8) Hability to scope bookmarks to Projects. > >When setting a bookmark from a buffer attached to a project, I'd >like to >have the choice of a bookmark scope: global or current project. > >When jumping to a bookmark from a buffer attached to a project, >I'd then >expect to have choice from bookmarks with global scope and >bookmarks >with scoped to current project. > >A project-bookmark-bmenu-list command could be created that >displays >bookmarks with global scope and scoped to current project. > >I don't know whether one should extend bookmarks with a scope >property >or store bookmarks in projects (using .dir-locals.el or a >dedicated >file?). Whew. This would complexify Bookmark considerably -- it starts to transform into a project management system. You can already use different bookmark-files for this kind of scoping, with a little bit of UI overhead (which we could improve, without having to fundamentally change how Bookmark works). Aha, you touch on that below!... >9) Improve support for multiple bookmark files > >I first thought 8) wouldn't be a problem if I maintained a >bookmark file >in each project. Unfortunately when you press the s key from >bookmark >BMenu, the default bookmark file is overwritten with bookmarks >coming >from multiple sources... > >And when jumping there's no way to select the bookmark source... Maybe just designing a fix for that -- a better UI flow -- is the solution to the scoping need? Best regards, -Karl