bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karl Fogel
Subject: bug#13882: 24.2; saveplace.el limit drop least recently used
Date: Mon, 11 Mar 2013 17:00:49 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Kevin Ryde <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]