[Top][All Lists]

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

Re: bug#15329: saveplace restores dired positions to random places

From: Karl Fogel
Subject: Re: bug#15329: saveplace restores dired positions to random places
Date: Thu, 12 Sep 2013 11:12:58 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Juri Linkov wrote:
>> An obvious solution to this problem is to save the
>> current file name in Dired instead of its point.
>> It seems saving information other than point doesn't contradict
>> the purpose of saveplace.el that automatically saves places where
>> visiting them later automatically moves point to the saved position.
>> Also elements of `save-place-alist' are (FILENAME . POSITION),
>> not more limited (FILENAME . POINT).  So saving a string to
>> POSITION would be consistent with the design of saveplace.el.
>I realized this is not backward-compatible change, i.e.
>older Emacs versions won't be able to read saved places
>in the new format.  Unfortunately, Dired filename positions
>can't be added to the current format that uses an alist
>with cons pair cells.  I mean (FILENAME . POINT)
>because older Emacs versions will fail to read them.
>The only solution that I see is to save two alists to the places file:
> ...)
> ...)
>Then the current code:
>  (with-demoted-errors
>    (car (read-from-string
>      (buffer-substring (point-min) (point-max)))))
>will read the first alist without problems,
>and additional code in newer versions like
>  (with-demoted-errors
>    (cadr (read-from-string
>      (buffer-substring (point-min) (point-max)))))
>will read the second alist with more information
>about the context of saved places (like bookmarks).

Well, rather, we could use that as an upgrade strategy for the saveplace
format as a whole.  In other words, starting now and for a few versions
of Emacs into the future, write the old format to the first part of the
file, and then a more flexible new format to the second part.  The
modern format would have a more extensible structure, similarly to how
bookmark.el does it.  Say, a sublist whose first element is the type of
the record, and the rest of which is the data for that record.  Like:

  ((FILE_OR_DIR_NAME_1 ('position (position information goes here)))
   (FILE_OR_DIR_NAME_2 ('dired-position (different kind of information)))




reply via email to

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