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

[Karl Fogel]

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)
>can't be changed to (FILENAME POINT DIRED-FILENAME-POSITION)
>because older Emacs versions will fail to read them.
>
>The only solution that I see is to save two alists to the places file:
>
>((FILENAME1 . POINT1)
> (FILENAME2 . POINT2)
> ...)
>((FILENAME1 DIRED-FILENAME-POSITION1)
> (FILENAME2 DIRED-FILENAME-POSITION2)
> ...)
>
>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)))
   ...)

etc.

Thoughts?

-Karl