Re: bug#25365: 25.1; Coding system for bookmarks and desktop

[Dmitri Paduchikh <dpaduchikh@gmail.com>]

Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Dmitri Paduchikh <dpaduchikh@gmail.com>
>> Date: Thu, 05 Jan 2017 17:37:30 +0500
>> 
>> It appears that all Cyrillic text in my bookmarks file has been
>> corrupted. I wasn't able to reproduce such a corruption using emacs -Q,
>> so probably this is due to interference with my settings which I will
>> have to investigate. But in my opinion there is a problem with
>> bookmark.el as well since it ignores completely coding system when
>> saving bookmarks. Thus I have written the following two advices to fix
>> its behavior. It seems that they work as needed.
>> 
>> (advice-add 'bookmark-write-file :around
>>             #'(lambda (f &rest args)
>>                 (let ((coding-system-for-write (or coding-system-for-write 'utf-8-emacs)))
>>                   (apply f args)))
>>             '((name . "coding")))

> Thanks, I used something similar in the patch below, except that I
> think we should honor the existing coding cookie in the bookmark file,
> instead of forcing the user to override the default each time the file
> is saved.  So we should record the encoding when we load the file, and
> apply it when saving.  This way, the user could specify the
> non-default encoding only once, using "C-x RET c", and have that value
> honored by Emacs thereafter.

Thank you for taking a look. As far as I understand bookmark.el may load
bookmarks from several files. Using the coding system from last read file
makes the choice of coding system for future write dependent on the order of
bookmark load and thus difficult to keep track for user. Also setting coding
system through coding-system-for-write will make non-encodable characters
replaced by spaces. The safety check is being done somewhere else - I am not
familiar with the exact details yet. Hopefully you have taken this into
account. As I am concerned these complications are not needed at all.
Encoding arbitrary data when writing a file (i.e. with utf-8-emacs) and
specifying coding system in the file header for the data to be correctly
decoded back - is all that is needed in my opinion.

[...]

> I installed the patch below on the master branch.  Please try it
> (after removing your advices) and see if it gives good results.  If
> you see problems, please reopen this bug with the details.

Will check it out. Though I think that the situation will not repeat after I
have fixed my configuration.

>> Besides, although desktop.el specifies coding system in its file, it is
>> old one - emacs-mule. Shouldn't this be utf-8-emacs these days instead?

> I'm not sure how many users share the desktop files with older Emacs
> versions that didn't support utf-8-emacs. There's nothing wrong with
> using emacs-mule in recent Emacs versions, for files that aren't
> supposed to be read by programs that are not Emacs.

I am worried by its ability to encode arbitrary characters after switch to
UTF-8. If there are such characters which emacs-mule does not encode they
can be silently replaced by spaces upon writing of desktop data.

PS. Not sure whether it makes sense to send messages to a closed bug,
and so continuing in emacs-devel.

With best regards
Dmitri Paduchikh