From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#29110: 25.2; Should push-mark allow duplicates? Date: Thu, 2 Nov 2017 06:34:35 -0700 (PDT) Message-ID: <290699e2-2140-4091-97ed-b2d5ef4dbf29@default> References: <87h8udiqv3.fsf@gmail.com> <87fu9xioo6.fsf@gmail.com> <4c91d163-4d9b-4b0f-9592-264048dc77e5@default> <87efphi3oo.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1509629719 9953 195.159.176.226 (2 Nov 2017 13:35:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Nov 2017 13:35:19 +0000 (UTC) Cc: 29110@debbugs.gnu.org To: Pierre Neidhardt Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 02 14:35:16 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAFeI-00026V-Gj for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Nov 2017 14:35:10 +0100 Original-Received: from localhost ([::1]:60407 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAFeP-0005fm-PI for geb-bug-gnu-emacs@m.gmane.org; Thu, 02 Nov 2017 09:35:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAFeD-0005fG-JA for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2017 09:35:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAFeA-0001O4-FV for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2017 09:35:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38339) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eAFeA-0001O0-As for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2017 09:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eAFeA-0003hY-17 for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2017 09:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2017 13:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29110 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29110-submit@debbugs.gnu.org id=B29110.150962968614200 (code B ref 29110); Thu, 02 Nov 2017 13:35:01 +0000 Original-Received: (at 29110) by debbugs.gnu.org; 2 Nov 2017 13:34:46 +0000 Original-Received: from localhost ([127.0.0.1]:47020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAFdt-0003gw-Qq for submit@debbugs.gnu.org; Thu, 02 Nov 2017 09:34:46 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:46012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAFds-0003gj-34 for 29110@debbugs.gnu.org; Thu, 02 Nov 2017 09:34:44 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA2DYbss013810 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 13:34:37 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA2DYa5w028425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 13:34:37 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA2DYaXa004984; Thu, 2 Nov 2017 13:34:36 GMT In-Reply-To: <87efphi3oo.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:139360 Archived-At: > > What part of "visiting them in order" wasn't clear? >=20 > Why visiting in order? Why not? You asked for a possible use case. To me that is one. You mark spots to visit, then you cycle among them. The order of marking determines the (default) order of cycling. Duplicates determine when and how often you visit a particular node in the cycle. The point is this: If Emacs automatically always removes duplicates then, well, you cannot take advantage of anything that duplicates can give you. But if Emacs does not remove duplicates then you can - and you can always remove/prevent duplicates. A sequence with duplicates gives you more possibilities than a sequence without duplicates, simply because you can always remove duplicates but you cannot easily add them. That is, you cannot add them if Emacs keeps automatically removing/preventing them. Why impose that? > I understand why rings should preserve the order in general, but what is > the user's intention when visiting marks in order? Why does order > matter in this specific case? Why going A-B-A? T-U-V-a-B-C-D-a-E-F-G-H-I lets you visit `a' more easily, more often, and quicker. Whatever. Whatever use someone or some code might put duplicates to. Why should Emacs prevent such a possibility out of the box, especially since it is so easy for anyone or any code to not allow duplicates. > Maybe the problem is that I see marks as "bookmarked > position in text", and in this case it makes little > sense to have a bookmark order. I too see them that way. And there is every reason to have a bookmark order - that can be very useful. Multiple bookmarks in a buffer, in buffer order, let you cycle among them in buffer order. In alpha order by, say, the thingie definitions that they mark gives you alpha-order navigation. Any number of orders are possible. Different orders for different purposes and different users. Isn't that what Helm & Ivy give you: easy ways to navigate among the markers in different orders? If they don't let you easily switch navigation orders then they should (IMHO). (In Icicles, at lease, it it is simple and immediate to change to a different order.) _Cycling_ navigation is in fact largely about _order_. Put differently: order makes a big difference if you need to cycle to get to something. Order can impose inconvenience. Imagine cycling through every name in the phone book (remember phone books?), in alphabetic order starting at A, just to get to the name Neidhardt. Not fun, especially if it is a large phone book. That's why interfaces such as Icicles, Helm, etc. also let you _filter_, to reduce the sequence to cycle through. And it's why they also let you go _directly_ to a given element in the navigation list, e.g., by name.