From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Enhancement suggestion: prin1 extension mechanism Date: Sun, 14 Sep 2008 15:35:34 -0400 Message-ID: References: <200809110325.m8B3PYFE031034@projectile.siege-engine.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1221421037 1222 80.91.229.12 (14 Sep 2008 19:37:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Sep 2008 19:37:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 14 21:38:13 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KexQD-0001R7-7f for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2008 21:38:13 +0200 Original-Received: from localhost ([127.0.0.1]:33113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KexPC-0002R0-Iw for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2008 15:37:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KexOT-0002An-QK for emacs-devel@gnu.org; Sun, 14 Sep 2008 15:36:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KexOQ-00029r-Ii for emacs-devel@gnu.org; Sun, 14 Sep 2008 15:36:23 -0400 Original-Received: from [199.232.76.173] (port=39293 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KexOQ-00029m-BB for emacs-devel@gnu.org; Sun, 14 Sep 2008 15:36:22 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:39953 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KexOQ-0001KT-0j for emacs-devel@gnu.org; Sun, 14 Sep 2008 15:36:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJQEzUhMCrQ4/2dsb2JhbACBY7ESgWSBBg X-IronPort-AV: E=Sophos;i="4.32,398,1217822400"; d="scan'208";a="26814267" Original-Received: from 76-10-180-56.dsl.teksavvy.com (HELO ceviche.home) ([76.10.180.56]) by ironport2-out.teksavvy.com with ESMTP; 14 Sep 2008 15:36:20 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 55517B40CD; Sun, 14 Sep 2008 15:35:34 -0400 (EDT) In-Reply-To: (Helmut Eller's message of "Sat, 13 Sep 2008 23:13:03 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103882 Archived-At: >> I fear it'd be difficult to make it work without incurring a significant >> performance overhead. > If the table is nil you could use the default hardcoded printer without > lookups. In many important cases (e.g. CL has been loaded), the table wouldn't be nil, and performance should still be good. > If the entries in the table can be accessed from Lisp code, we could > remember the default print function for a type before installing a > custom printer. E.g. if a vector doesn't have the special symbol in the > first entry, we could call the previously remembered default printer > instead of iterating manually over the vector. Recursive calls to print > would again use the custom print function. I don't know what you're talking about. I'd probably understand better with a piece of code. > It seems to me that, compared to testing for circularity, those table > lookups would only introduce a minor slowdown. Testing for circularity is indeed too slow right now. That should be fixed as well. > And if someone produces so much output the that it takes to long to > print, he probably doesn't want to read it anyway :-) But it's difficult for Emacs to find ou before it's too late. Stefan