bug#29110: 25.2; Should push-mark allow duplicates?

[Drew Adams]

> >> 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.
> 
> 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'), 
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. 

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 
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.