Re: list-print-separator

[Ted Zlatanov]

On Mon, 25 Apr 2011 12:37:07 -0300 Stefan Monnier <address@hidden> wrote: 

>>>> With my list-print-separator patch you get fast and OK-looking.
>>>> Are you concerned it's only useful sometimes?  The speed penalty is
>>>> minor if it's not used.
SM> I'd rather make `pp' faster, or if it's too difficult split it into
SM> a "print-really-pretty" and "print-quickly-and-not-too-ugly".
>> The users most likely to benefit, at least for Gnus where I have
>> experience supporting them, are those who can't read ELisp well.  They
>> are also less likely to complain or roll their own solution.

SM> I'm not sure how that relates: what I propose is for Gnus to call
SM> print-quickly-and-not-too-ugly and that would be done by people who know
SM> Elisp fairly well.  The users who don't know Elisp well would not need
SM> to know that the file was printed via this function rather than via
SM> `print'.

Assuming Gnus is the only package to need this, you're right.  But the
reason for my proposal is that I think other packages can use it too.
EIOIO serialization, for instance, could use it.

>> So I hope you see that this is not a "print pretty" request but a real
>> need for any package that uses ELisp's build-in serialization.
>> I'm concerned that your "good enough" solution will not be adopted
>> because it will be much slower than the native `print' serialization,
>> and optimizing it is much more work than my proposed patch of 4 lines.

SM> I'm not convinced it's difficult to write
SM> a print-quickly-and-not-too-ugly that's reasonably fast.  Admittedly,
SM> reasonably fast may still be too slow, but in that case I'd rather just
SM> use an ugly print out than try to make `print's output prettier or
SM> more customizable.

OK.  I'll look at `pp' in my spare time :)

SM> PS: you could also add a -*- mode: ugly-sexp -*- cookie in the
SM> newsrc.eld file so that when a user opens it for reading it can easily
SM> (automatically?) be prettified.

That's a great idea, but I'm concerned that users may need to open the
file outside Emacs if it's causing startup problems or if the data is
triggering a bug (e.g. encoding cookie is wrong).  I've run into that.

Ted