unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Pierre Neidhardt <ambrevar@gmail.com>
Cc: 29110@debbugs.gnu.org
Subject: bug#29110: 25.2; Should push-mark allow duplicates?
Date: Thu, 2 Nov 2017 06:34:35 -0700 (PDT)	[thread overview]
Message-ID: <290699e2-2140-4091-97ed-b2d5ef4dbf29@default> (raw)
In-Reply-To: <87efphi3oo.fsf@gmail.com>

> > What part of "visiting them in order" wasn't clear?
> 
> 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.





  reply	other threads:[~2017-11-02 13:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 22:19 bug#29110: 25.2; Should push-mark allow duplicates? Pierre Neidhardt
2017-11-01 22:43 ` Drew Adams
2017-11-01 23:07   ` Pierre Neidhardt
2017-11-01 23:30     ` Noam Postavsky
2017-11-02  6:43       ` Pierre Neidhardt
2017-11-02  0:53     ` Drew Adams
2017-11-02  6:40       ` Pierre Neidhardt
2017-11-02 13:34         ` Drew Adams [this message]
2017-11-05 14:59           ` Pierre Neidhardt
2017-11-05 18:41             ` Drew Adams
2022-02-08  6:24 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=290699e2-2140-4091-97ed-b2d5ef4dbf29@default \
    --to=drew.adams@oracle.com \
    --cc=29110@debbugs.gnu.org \
    --cc=ambrevar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).