bug#13882: 24.2; saveplace.el limit drop least recently used

[Dmitry Gutov]

On 08.03.2013 1:20, Karl Fogel wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> > Karl, do you think this consideration is still important? I don't see a
> > reasonable way to keep the list easy to merge and still retain the
> > "most-recently used" information.
> >
> > You either keep the list unsorted (and continually shuffle the
> > elements), or store some timestamps, which will also be a source of
> > merge conflicts.
>
> Hmmm.  I see your point, and, of course, there are arguments both ways.
>
> We could supply an user-option to control the behavior, but that still
> leaves the question of which default we should choose...
>
> However, I think the answer to that is also clear: unsorted should be
> the default (or rather, chronologically sorted should be the default),
> and if a user wants the list alphabetized (for merge purposes), they can
> configure it so.  And this would be documented not only in the new
> variable, but also in the doc string of `save-place-limit'.
>
> What do you think?

We can do it this way, of course.

But I imagine that merging of place files can only be a once-in-a-while 
occurrence, and at all other times the user would prefer the 
chronological sorting (if they were aware of this issue, at all).

So maybe we should provide an export command instead, that would save 
the sorted places list to a file specified by the user, to do as they 
please.

Let's also ask the original reporter. Iain, any opinion?