Re: Loading an output from prin1 (savehist bug).

Re: Loading an output from prin1 (savehist bug).

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1228 bytes --]

Richard Stallman <rms@gnu.org> writes:

>     >   If some code output command-history with prin1 then try to load it
>     >   back, the # things will cause parse errors.
>
> We can't alter that.  I see a few possible solutions:
>
> 1. Don't put markers into arguments to interactive commands,
> except thru the specific functions (point), (mark), etc.,
> which go into command-history as calls to those functions.
>
> 2. Fix programs such as bbdb-create and savehist to find
> such markers and replace them with nil.
>
> 3. Create a more general mechanism for commands to specify
> how to record calls to them in command-history.
>
> Solution #1 seems simplest; is there any reason why you need to put
> these markers in args to commands?

I don't have one ; that was just because bbdb seems to do.

Does this restriction have to be put in the coding style section of
the manual?

-- 
 |      Michaël `Micha' Cadilhac   |   Pour les 35-40 ans, l'humour         |
 |         Epita/LRDE Promo 2007   |        c'est une plus-value.           |
 | http://www.lrde.org/~cadilh_m   |           -- Guillaume L.              |
 `--  -   JID: micha@amessage.be --'                                   -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Loading an output from prin1 (savehist bug).

[Stefan Monnier]

>> >   If some code output command-history with prin1 then try to load it
>> >   back, the # things will cause parse errors.
>> We can't alter that.  I see a few possible solutions:
>> 
>> 1. Don't put markers into arguments to interactive commands,
>> except thru the specific functions (point), (mark), etc.,
>> which go into command-history as calls to those functions.
>> 
>> 2. Fix programs such as bbdb-create and savehist to find
>> such markers and replace them with nil.
>> 
>> 3. Create a more general mechanism for commands to specify
>> how to record calls to them in command-history.
>> 
>> Solution #1 seems simplest; is there any reason why you need to put
>> these markers in args to commands?

I think those uses of prin1 really call for some way to reliably print data
in a lisp-readable form.  I.e. a variant of prin1 (or a way to tell prin1)
that ignores print-depth and friends and which signals an error when it
encounters an element that it can't print readably (e.g. a marker, a hash
table, ...).


        Stefan

Re: Loading an output from prin1 (savehist bug).

[Richard Stallman]

    >> Solution #1 seems simplest; is there any reason why you need to put
    >> these markers in args to commands?

    I think those uses of prin1 really call for some way to reliably print data
    in a lisp-readable form.  I.e. a variant of prin1 (or a way to tell prin1)
    that ignores print-depth and friends and which signals an error when it
    encounters an element that it can't print readably (e.g. a marker, a hash
    table, ...).

This is a very complicated project, and I think that with
the added complexity it would be a change for the worse.

Re: Loading an output from prin1 (savehist bug).

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think those uses of prin1 really call for some way to reliably
> print data in a lisp-readable form. I.e. a variant of prin1 (or a
> way to tell prin1) that ignores print-depth and friends and which
> signals an error when it encounters an element that it can't print
> readably (e.g. a marker, a hash table, ...).

How about a `print-readably' variable? XEmacs has one, Common Lisp has
*print-readably*.

Hmm...

In fact savehist already binds `print-readably'.

-- 
Johan Bockgård

Re: Loading an output from prin1 (savehist bug).

[Richard Stallman]

    Does this restriction have to be put in the coding style section of
    the manual?

I think it should go in the place where `interactive' is documented.

Re: Loading an output from prin1 (savehist bug).

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 1115 bytes --]

Richard Stallman <rms@gnu.org> writes:

>     Does this restriction have to be put in the coding style section of
>     the manual?
>
> I think it should go in the place where `interactive' is documented.

Is this done?

I couldn't do it since I wasn't aware of the other restrictions
(regarding those interactive arguments) that have to be made.

We pointed  out that the  use of a  marker is harmful, but  what about
(this is a grep) the following:

#<process 
#<subr 
#<window 
#<hash-table
#<killed buffer>
#<buffer 
#<window-configuration>
#<frame 
#<dead frame 
#<marker 
#<overlay 
#<misc free cell>
#<intfwd to %ld>
#<boolfwd to %s>
#<objfwd to 
#<buffer_objfwd to 
#<kboard_objfwd to 
#<buffer_local_value 
#<some_buffer_local_value 
#<save_value 

-- 
 |      Michaël `Micha' Cadilhac   |    Le copillage-collage                |
 |         Epita/LRDE Promo 2007   |       tue le programmeur.              |
 | http://www.lrde.org/~cadilh_m   |           -- Dictons LRDE              |
 `--  -   JID: micha@amessage.be --'                                   -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Loading an output from prin1 (savehist bug).

[Richard Stallman]

    > I think it should go in the place where `interactive' is documented.

    Is this done?

No, but I wrote it just now.  Thanks.