unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Karl Fogel <kfogel@red-bean.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Kevin Ryde <user42@zip.com.au>, 13882@debbugs.gnu.org
Subject: bug#13882: 24.2; saveplace.el limit drop least recently used
Date: Thu, 07 Mar 2013 15:20:37 -0600	[thread overview]
Message-ID: <87a9qe52l6.fsf@kwarm.red-bean.com> (raw)
In-Reply-To: <874ngn5ioy.fsf@yandex.ru> (Dmitry Gutov's message of "Thu, 07 Mar 2013 19:32:45 +0400")

Dmitry Gutov <dgutov@yandex.ru> writes:
>Kevin Ryde <user42@zip.com.au> writes:
>> When saveplace.el reaches save-place-limit, the file positions retained
>> via ~/.emacs-places are the first limit-many in alphabetical order.
>> I hoped instead it would be the first limit-many most recently used.
>> Ie. drop the least recently visited files in order to enforce the limit.
>>
>> I struck this when I reached my save-place-limit with lots of files I
>> had visited long ago but which happened to be alphabetically before ones
>> I was visiting now.  The save-place feature no longer saved places
>> across sessions for files I now visited.
>> <example>
>
>I can confirm that this is a problem, and it doesn't look "minor" in the
>context of this package.
>
>> ...
>> I get some joy from not sorting save-place-alist when saving per change
>> below.
>>
>> I believe save-place-to-alist keeps save-place-alist in "most recent
>> first" order (by delq and re-push to move an existing entry to the
>> start), and that that order should be preserved when saving.
>
>I like the solution, but according to the ChangeLog the decision to sort
>the list was made at the request of a user, who apparently has to merge
>saveplace history files from time to time:
>
>2010-12-29  Karl Fogel  <kfogel@red-bean.com>
>
>	* saveplace.el (save-place-alist-to-file): Save list sorted and
>	pretty-printed, so that it is mergeable by line-based text merging,
>	as suggested by Iain Dalton <iain.dalton {_AT_} gmail.com>.
>
>Paging the author.
>
>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?

-Karl

>> 2013-03-04  Kevin Ryde  <user42@zip.com.au>
>>
>> 	* saveplace.el (save-place-alist-to-file): Don't `sort'
>> 	save-place-alist alphabetically, keep it in "most recent first" order.
>> 	This ensures save-place-limit drops the least recently visited files,
>> 	not the alphabetically last files.  Dropping alphabetically last files
>> 	had meant save-place stopped working across sessions after
>> 	.emacs-places filled with alphabetically early names.
>
>--Dmitry





  reply	other threads:[~2013-03-07 21:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05 20:49 bug#13882: 24.2; saveplace.el limit drop least recently used Kevin Ryde
2013-03-07 15:32 ` Dmitry Gutov
2013-03-07 21:20   ` Karl Fogel [this message]
2013-03-07 22:13     ` Dmitry Gutov
2013-03-10  0:57     ` Kevin Ryde
2013-03-10 22:09       ` Karl Fogel
2013-03-11 21:23         ` Kevin Ryde
2013-03-11 22:00           ` Karl Fogel
2013-03-11 22:08             ` Ian Dalton
2013-03-12  0:43               ` Kevin Ryde
2013-03-13 18:59                 ` Karl Fogel

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=87a9qe52l6.fsf@kwarm.red-bean.com \
    --to=kfogel@red-bean.com \
    --cc=13882@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=user42@zip.com.au \
    /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).