Subject: Re: bug#65055: 30.0.50; save-place-abbreviation-file-names :set fails for saveplace-pdf-view places

From: Visuwesh <[email-masked]>
Date: Sat, 05 Aug 2023 09:07:06 +0530

[வெள்ளி ஆகஸ்ட் 04, 2023] Eli Zaretskii wrote:

>> Unfortunately, that's only half the story.  save-place-alist can also
>> have elements such as
>> 
>>     ("SOME-DIRECTORY" (dired-filename . "SOME-FILENAME"))
>> 
>> to save the place for dired buffers.
>
> Where is this documented

It is not.  The only way to know how this comes to be is to read
`save-place-to-alist'.  BTW, another specially handled major-mode is
hexl-mode.

>, and when the change to support this
> extension was added?

In commit d4466a91f271db0b414a605ede1a7befd403b950.

    commit d4466a91f271db0b414a605ede1a7befd403b950
    Author: Ivan Kanis <[email-masked]>
    Date:   Fri Jun 14 11:32:01 2013 +0200

        Add support for dired in saveplace.

> And in any way, the form you show above, which is used by
> saveplace-pdf-view, is not even of that extended format, or am I again
> missing something?

No, you are not missing anything.

>> But instead of checking if the second element of the place's cdr is a
>> string, the :set function simply assumes that it will be always be a
>> string.  This is not wrong as such since that's the only allowed format
>> as far as core Emacs is concerned but I think having the check in place
>> would help expand the save-place-alist format as the user desires.
>
> I don't think we should tweak our code to support save-place-alist
> formats that violate the documented formats.  If the documented format
> is not followed, how do you know which elements of which parts of the
> data structures are file names in the first place?

I understand your point,

> The right way of extending such data structures is to allow functions
> as the values, and let those functions deal with non-standard formats.
> The way saveplace-pdf-view does it, IIUC, is simply wrong: it just
> happened to work by sheer luck with previous versions because Emacs
> never actually acted on the assumption that a file name is in a
> certain place in the data stricture.

That was my idea two years back and till now but I simply didn't/don't
have the motivation to come up with a patch since I don't use saveplace
for anything but pdf buffers and saveplace-pdf-view did the job good
enough for me to not worry about a better way™.  In the absence of such
motivation, I will solve the problem in saveplace-pdf-view's side and
call it a day.  If/when the motivation returns, I guess we can revisit
this issue.
This report can be closed if you wish.