GNU bug report logs - #13882
24.2; saveplace.el limit drop least recently used

Previous Next

Full log

Message #26 received at 13882 <at> debbugs.gnu.org (full text, mbox):

From: Karl Fogel <kfogel <at> red-bean.com>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: iain.dalton <at> gmail.com, 13882 <at> debbugs.gnu.org,
	Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#13882: 24.2; saveplace.el limit drop least recently used
Date: Mon, 11 Mar 2013 17:00:49 -0500

Kevin Ryde <user42 <at> zip.com.au> writes:
>> I'm happy to address a concrete proposal,
>I would say take away the `sort', and don't have an option for it.

Ah, okay.  So you're saying the merge use case is not worth supporting,
it sounds like?

>> How would the user hook in to run the sort, unless we provide some
>> option in saveplace.el?
>
>I presume a user has two .emacs-places files and wants to merge them.
>Was that the motivation for the sort?

Right, I think so.  I think it's typically that they keep their
.emacs-places under version control, and they do an update ("pull") and
get changes that need to be merged.  So they want the file to work well
with the usual merge algorithms.

>If yes then I would say the files can be sorted easily enough at that
>time, no need to always save sorted.  In fact I would say keeping
>most-recent-first order might be desirable when merging two files
>anyway.

Yes, now that you mention it, it makes me wonder why there was a merge
problem in the first place...

>The second part I wondered what happens if I have two running copies of
>emacs, both with save-place enabled.  When the first one exits it writes
>.emacs-places.  When the second one exits it too writes .emacs-places.
>I suspect the second overwrites the first.  Was such a situation the
>motivation for the sort to "merge"?

No; I think it was the above (version control) scenario.

Best,
-Karl

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.