From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Friendlier dired experience [CODE INCLUDED] Date: Sun, 8 Nov 2020 08:48:27 -0800 (PST) Message-ID: <6d8882a5-23aa-4fab-b222-30928dc17eb9@default> References: <20201105092232.fk4r5dexnay3eyln@E15-2016.optimum.net> <20201105143800.7vt5jfr4gg2wigyb@E15-2016.optimum.net> <20201106091525.mzkxrssm7o43jvff@E15-2016.optimum.net> <20201108093604.rb3lpyqw4mvmwtdt@E15-2016.optimum.net> <20201108124020.jmxb4luvq6fot7xg@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35385"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Arthur Miller , Emacs-Devel List To: Jean Louis , Boruch Baum Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 08 17:51:29 2020 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 1kbnub-00096O-D5 for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Nov 2020 17:51:29 +0100 Original-Received: from localhost ([::1]:44832 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kbnua-0000Dz-EI for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Nov 2020 11:51:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48820) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kbntk-0008EB-B9 for emacs-devel@gnu.org; Sun, 08 Nov 2020 11:50:36 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:38968) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kbnti-0005fA-6I for emacs-devel@gnu.org; Sun, 08 Nov 2020 11:50:36 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0A8GoDTS069231; Sun, 8 Nov 2020 16:50:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=9nbWhxu3mYjWqYwdGR7e5hFzgPmO2xd6QTmgzmkJdB8=; b=lseaPiBHsFP/BX5zKcHHSUHe/gest9DT5x/VJiCIBQ1qtO4E6DOEFg1C1QtyN8pUhdy1 WTSDVVVyaNpIi9qMpmcd+YX8H/kYGe5SuF87Cf4RFpg72uOitL7eUc97O4LaPR20QN/M Xc4CDI2maoUkgXtixh6i8IpF71Sz5KpcFS5OXX2YJQzpdl8hUnlYYO0y1Jew2//dW0mP HM+OSS8EoHu2vcySDWft+gUHGxEnwgk3s84JSQDOomw0pGaHSp2BjSlDNqzfWknUffwx L0zp5ULwPZabs+NtqtX2ZZzYmddZVFgX//wNIbmuZXQ3H8veRpKvr1d6H9TSVuLzVhgf 2A== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 34p72e92nx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 08 Nov 2020 16:50:30 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0A8GjMvH132233; Sun, 8 Nov 2020 16:48:29 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 34p55jyw98-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 08 Nov 2020 16:48:29 +0000 Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0A8GmSTp026347; Sun, 8 Nov 2020 16:48:28 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5071.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9799 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011080119 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9799 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 priorityscore=1501 spamscore=0 impostorscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011080119 Received-SPF: pass client-ip=156.151.31.85; envelope-from=drew.adams@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/08 11:50:32 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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.23 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:258912 Archived-At: > > It does presume a 'segregationist' mind-set > > that I clearly have and many on this list don't, > > ie. it didn't occur to me that people find it > > desirable to mix up bookmark types. 1. If there are no specific handlers, so the default handler is always used, then there are, generally speaking, no bookmark types. The most-default default behavior is to treat all bookmarks the same. 2. Even when there are multiple bookmark types (and there are, even in `emacs -Q' - Info bookmarks, for instance), nothing _requires_ someone to "mix" bookmarks of different types in the same bookmark file. It's simple to have a bookmark file for Info bookmarks, another for EWW bookmarks, another for image bookmarks, another for man bookmarks, etc. IOW, it's not either/or: one hard-coded camp of "segregationists" vs another one of "integrationists". Anyone can use bookmarks either way: mix or match. ___ And bookmarks can not only be "hard-code" separated by type into different bookmark files. If you use Bookmark+ then you can mix them in a given bookmark file but still separate them wrt access, display, etc. A function can use bookmarks of any specific type, by using the function that returns only bookmarks of that type: `bmkp--alist-only'.=20 > > Now, if one can argue that it's *objectively* better to mix > > bookmarks, then one can clearly reject the diredc system, but once > > it becomes a subjective issue of expectation and personal > > preference, the diredc system isn't so easy to reject. >From my point of view, it's objectively better to be able to mix _or_ keep separate. And that, in different ways, only one of which involves physical separation into different files. Just one opinion. The real point is that, even with vanilla Emacs, nothing obliges anyone to mix bookmarks of different types in the same file. > That is why I am looking into those handlers Drew > mentioned, but still did not find clear way to go. > It is gluing two bookmark systems together.=20 If you mean using bookmark handlers, in general, then no, that has nothing particular to do with me or Bookmark+. That's basic to the vanilla-Emacs design of bookmarks, and it has been so since Day One. There's a default behavior, AND you can add bookmark types with their own behavior. > Comments on Bookmark+: there are new things to learn, for example > non-existent bookmarks for which I did not even now they are > non-existent, "no such buffer now", bookmarkes to sequence or variable > list, function, there are annotations which should be in every > bookmark system. Browsers mostly have it, some of them still don't. >=20 > There are functions to export and import bookmarks, > integrate. Thinking of knowledge management that is useful as one want > whole set or groups or tagged bookmarks exported and to give such to > other people. Bookmarks need not be only to location of files, > directories, bookmarks are pointers and hyperlinks to information. >=20 > https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Hyperlink__;!!G= qivP > Va7Brio!Nb65Jllzho8BuyZWUu8ZyRmcMOVajbyIWqIMGvH8zDbSbrgROMDMgX2pwMSVvVSL$ >=20 > In computing, a hyperlink, or simply a link, is a reference to data > that the user can follow by clicking or tapping.[1] A hyperlink points > to a whole document or to a specific element within a > document. Hypertext is text with hyperlinks. The text that is linked > from is called anchor text. A software system that is used for viewing > and creating hypertext is a hypertext system, and to create a > hyperlink is to hyperlink (or simply to link). A user following > hyperlinks is said to navigate or browse the hypertext. >=20 > Emacs bookmarks, bookmarks+ or diredc bookmarks or any similar system > fit into that definition of hypertext systems. Merging them together > or having unified search and filtering interface is useful. Yes, to all of that. The main characteristics of Emacs bookmarks are these, IMO: 1. They're persistent. (They don't have to be, but they can be.) 2. They can record nearly anything. 3. The info they store can be used in any way. In a nutshell, they're little, persistent bits of Lisp data.