desktop.el problem [Re: X-Symbol 4.0e; Emacs port (fwd)]

desktop.el problem [Re: X-Symbol 4.0e; Emacs port (fwd)]

[Kenichi Handa]

In article <67B8CED503F3D511BB9F0008C75DAD660212AE84@dbwdfx17.wdf.sap-ag.de>, "Wedler, Christoph" <christoph.wedler@sap.com> writes:
> Desktop also writes the contents of `kill-ring' and `register-alist',
> and probably some history variables which could contain such
> characters.

Oops...

Then, it's a general problem of desktop.  If a user define a
new charset in a session, and there's a string containing
that charset in kill-ring, he always fails in the next
session while recovering the previous session.

It seems that the only way to solve it is to save also those
charset definitions.  But, saving it in .emacs.desktop is
useless.  We must save it in a file that is loaded before
.emacs.desktop is loaded.

Another workaround is not to save such strings that contains
a characters of newly defined charsets.

What do people think?  I prefer the latter method because
the former method is not robust.  It won't be able to deal
with the situation that a user defines a charset in his
.emacs before .emacs.desktop is loaded.

By the way, emacs-unicode won't have this problem.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: desktop.el problem [Re: X-Symbol 4.0e; Emacs port (fwd)]

[Eli Zaretskii]

On Thu, 25 Jul 2002, Kenichi Handa wrote:

> Another workaround is not to save such strings that contains
> a characters of newly defined charsets.
> 
> What do people think?  I prefer the latter method because
> the former method is not robust.  It won't be able to deal
> with the situation that a user defines a charset in his
> .emacs before .emacs.desktop is loaded.
> 
> By the way, emacs-unicode won't have this problem.

If this problem is temporary, until the Unicode Emacs is released, 
perhaps we just need to have an entry in PROBLEMS explaining the 
limitation.  It might also be a good idea to have desktop.el display a 
warning when it detects such characters in some string it's about to 
save. 

Re: desktop.el problem [Re: X-Symbol 4.0e; Emacs port (fwd)]

[Richard Stallman]

    Then, it's a general problem of desktop.  If a user define a
    new charset in a session, and there's a string containing
    that charset in kill-ring, he always fails in the next
    session while recovering the previous session.

Could you explain why this fails?  What does the printed representation
of such a string look like, and how does it depend on having the character
set loaded?

Perhaps we should change the printed representation of such strings so
that they can be read back in all circumstances.  If characters in
user-defined character are written as \-sequences, would that do it?

    It seems that the only way to solve it is to save also those
    charset definitions.  But, saving it in .emacs.desktop is
    useless.  We must save it in a file that is loaded before
    .emacs.desktop is loaded.

Could you explain the reason for that?
Are these characters being output literally by prin1,
and then encoded when .emacs.desktop is saved?
If that is so, there are many points in that sequence that we could change.

Re: desktop.el problem [Re: X-Symbol 4.0e; Emacs port (fwd)]

[Kenichi Handa]

In article <200207251807.g6PI7A007627@aztec.santafe.edu>, Richard Stallman <rms@gnu.org> writes:
>     Then, it's a general problem of desktop.  If a user define a
>     new charset in a session, and there's a string containing
>     that charset in kill-ring, he always fails in the next
>     session while recovering the previous session.

> Could you explain why this fails?  What does the printed representation
> of such a string look like, and how does it depend on having the character
> set loaded?

The printed representation is just a multibyte sequence
starting by a new leading code assigned at the time of
defining the charset.

This new leading code can't be treated as valid in the next
session until the charset is defined in the same way as the
previous session.

> Perhaps we should change the printed representation of such strings so
> that they can be read back in all circumstances.  If characters in
> user-defined character are written as \-sequences, would that do it?

>     It seems that the only way to solve it is to save also those
>     charset definitions.  But, saving it in .emacs.desktop is
>     useless.  We must save it in a file that is loaded before
>     .emacs.desktop is loaded.

> Could you explain the reason for that?
> Are these characters being output literally by prin1,
> and then encoded when .emacs.desktop is saved?

Yes.

> If that is so, there are many points in that sequence that we could change.

For instance?

---
Ken'ichi HANDA
handa@etl.go.jp

Re: desktop.el problem [Re: X-Symbol 4.0e; Emacs port (fwd)]

[Richard Stallman]

    The printed representation is just a multibyte sequence
    starting by a new leading code assigned at the time of
    defining the charset.

    This new leading code can't be treated as valid in the next
    session until the charset is defined in the same way as the
    previous session.

This is a serious problem.  It ought to be fixed.  One possible fix is
to change print.c to use a hex escape for these characters.

I will write the code if you tell me how to test for a character that
is in a nonstandard character set.

Re: desktop.el problem [Re: X-Symbol 4.0e; Emacs port (fwd)]

[Kenichi Handa]

In article <200207271852.g6RIqNk10666@aztec.santafe.edu>, Richard Stallman <rms@gnu.org> writes:
>     The printed representation is just a multibyte sequence
>     starting by a new leading code assigned at the time of
>     defining the charset.

>     This new leading code can't be treated as valid in the next
>     session until the charset is defined in the same way as the
>     previous session.

> This is a serious problem.  It ought to be fixed.  One possible fix is
> to change print.c to use a hex escape for these characters.

It can't be a fix.  At the time of loading, such a hex
escape will be decoded into an integer number, but as the
number is invalid as a character code (before the
corresponding charset is defined), the loader signals an
error.

> I will write the code if you tell me how to test for a character that
> is in a nonstandard character set.

Currently we don't have a mechanism to distinguish builtin
charsets from user's charsets.  I'll implement such a
mechanism (not difficult) if it is really useful.

---
Ken'ichi HANDA
handa@etl.go.jp