Thanks for fixing the bug! As soon as I realised that there was a problem with binding `standard-output' to a function, I rewrote the code to use a buffer instead. Also, thanks for pointing out the excessive memory usage when accumulating a string -- one can learn something new every day (even after 20 years)... -- Anders Ps. I just released the package I've been working in for a couple of weeks, it's an interactive debugger for font-lock keywords. If you want to try it you can get it from https://github.com/Lindydancer/font-lock-studio On Wed, Jan 29, 2014 at 7:01 PM, Eli Zaretskii wrote: > > Date: Tue, 28 Jan 2014 23:00:32 +0100 > > From: Anders Lindgren > > Cc: 16576@debbugs.gnu.org > > > > Well, the main issue here is if this is a real bug or not. You originally > > thought this was simply a mistake in the example I provided -- do you > still > > think so? > > There was indeed a bug, now fixed on the trunk, which caused the > problem. It was a very old bug, it went unnoticed until now because, > I guess, no one conses a string one character at a time -- this is a > terrible idea in Emacs Lisp. Use a temporary buffer instead. > > There was nothing wrong with prin1 per se, btw, it's just that its > subroutine which prints a string wasn't safe when GC hit in the middle > of a prin1 call. The code protected the string from GC, but that > doesn't preclude relocation of string data, so holding to C 'char *' > pointers is not safe in these situations. And printing a > 800-character string like you did triggers GC every time, because it > creates 800 string objects for a grand total of about 320000 bytes. > > Anyway, problem solved, and I'm closing the bug. Thanks. >