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: Sun, 5 Nov 2017 10:41:44 -0800 (PST) Message-ID: References: <87h8udiqv3.fsf@gmail.com> <87fu9xioo6.fsf@gmail.com> <4c91d163-4d9b-4b0f-9592-264048dc77e5@default> <87efphi3oo.fsf@gmail.com> <290699e2-2140-4091-97ed-b2d5ef4dbf29@default> <87ineoojpc.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 1509907330 9513 195.159.176.226 (5 Nov 2017 18:42:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Nov 2017 18:42:10 +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 Sun Nov 05 19:42:06 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 1eBPrx-0002Jp-T3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Nov 2017 19:42:06 +0100 Original-Received: from localhost ([::1]:45353 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBPs5-00053b-4o for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Nov 2017 13:42:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBPry-00053K-Jj for bug-gnu-emacs@gnu.org; Sun, 05 Nov 2017 13:42:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBPrv-0004IK-Dn for bug-gnu-emacs@gnu.org; Sun, 05 Nov 2017 13:42:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43925) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eBPrv-0004IF-8V for bug-gnu-emacs@gnu.org; Sun, 05 Nov 2017 13:42:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eBPrt-0003kS-On for bug-gnu-emacs@gnu.org; Sun, 05 Nov 2017 13:42:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Nov 2017 18:42: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.150990731414391 (code B ref 29110); Sun, 05 Nov 2017 18:42:01 +0000 Original-Received: (at 29110) by debbugs.gnu.org; 5 Nov 2017 18:41:54 +0000 Original-Received: from localhost ([127.0.0.1]:52606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBPrl-0003k2-Na for submit@debbugs.gnu.org; Sun, 05 Nov 2017 13:41:53 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:19816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBPrk-0003jo-Oh for 29110@debbugs.gnu.org; Sun, 05 Nov 2017 13:41:53 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA5IfiXw030772 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 5 Nov 2017 18:41:45 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA5Ifi2J012745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 5 Nov 2017 18:41:44 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA5Ifi2c002853; Sun, 5 Nov 2017 18:41:44 GMT In-Reply-To: <87ineoojpc.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: userv0021.oracle.com [156.151.31.71] 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:139483 Archived-At: > >> 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. >=20 > I'm still skeptical about that one. That being said, > that's not a reason to remove the feature, you are right. Yes, you don't need to be convinced, as long as the proposal is abandoned. But FWIW, cycling order can be quite important for users, particularly for a situation, such as with vanilla Emacs cycling, where you have _no alternative_, where you cannot act on candidates (in this case visit bookmarks/marks) _selectively_, using direct access. For bookmarks - and the same goes for Emacs markers, two cycle orders that can be _particularly_ useful are: (1) order on the page, i.e., in the buffer, and (2) time order: of creation or last modification or last access. If you don't get that then I can only guess that you don't cycle among such marks very often. Or you might not get it if you use something (e.g. Helm?) that _does_ let you access candidates other than only by cycling, drone-like, through a huge list of candidates, in order. Another possibility is that the lists that you cycle through are relatively short. In that case, the order has little or no importance. For example, with vanilla Emacs Info `i' (`Info-index'),=20 it's not very bothersome that one can only cycle through multiple matches in a single, predefined order, using `,', because there are only a very few candidates (e.g. less than 5) to cycle among. Being limited to cycling becomes problematic when there are many candidates to choose from. UIs such as Icicles and Helm let you pare down the set of matching candidates, incrementally, and they (at least Icicles does) also let you access any number of them directly (e.g. click or hit a key). > Enough bike-shedding :) This isn't bike-shedding. It's more like discussing a proposal to remove the kitchen altogether because some users always eat out and no longer cook at home.=20 The epithet "bike-shedding" can be, BTW, a facile put-down, tossed out when one has nothing useful to add further to a discussion. It dismisses the discussion itself as unimportant, as a substitute for acknowledging a weak or abandoned argument. It confuses personally wanting to drop a discussion with the relative importance of the discussion. Whether you really care about your proposal is not so relevant, once it has been dropped, as whether it raises an important or useful question, i.e., whether the discussion of the proposal serves a purpose. The question of duplicate candidates, and more generally of cycling, and even more generally of how to choose and access candidates, is an important one. Removing duplicates _can_ be very useful. What we should avoid, IMO, is removing duplicates willy nilly, or in all cases. Less generally, systematically=20 removing duplicates for marker navigaion would be a mistake, IMO. But this general question is worth considering: How can Emacs provide users with the ability to remove duplicates when they want to, either on the fly (e.g. hit a key) or by configuration for a given feature. I don't think that vanilla Emacs has a good answer for that question. Icicles (and I assume other UIs that have since adopted a similar approach) lets users hit `C-$' to toggle the removal of duplicate candidates on the fly. You can also configure a given command, to have it remove duplicates from the get-go. Vanilla Emacs provides no on-the-fly user modification of the set of candidates or their order of access. That's really the rub scratched by the question in the Subject line here. A bug thread is not the main place to discuss such a problem thoroughly, but it can be a place to raise the question.