From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sam Steingold Newsgroups: gmane.emacs.devel Subject: Re: with-standard-io-syntax Date: Wed, 22 Aug 2012 14:30:23 -0400 Organization: disorganization Message-ID: <87y5l6ixts.fsf@gnu.org> References: <87sjbgqply.fsf@gnu.org> Reply-To: sds@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1345660239 6080 80.91.229.3 (22 Aug 2012 18:30:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Aug 2012 18:30:39 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 22 20:30:40 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T4FhP-00074x-GP for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2012 20:30:39 +0200 Original-Received: from localhost ([::1]:51994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4FhN-0001Jg-Vs for ged-emacs-devel@m.gmane.org; Wed, 22 Aug 2012 14:30:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4FhM-0001J6-11 for emacs-devel@gnu.org; Wed, 22 Aug 2012 14:30:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4FhK-0000Ma-Lo for emacs-devel@gnu.org; Wed, 22 Aug 2012 14:30:35 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:39588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4FhK-0000MP-Ev for emacs-devel@gnu.org; Wed, 22 Aug 2012 14:30:34 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T4FhI-0006vd-QI for emacs-devel@gnu.org; Wed, 22 Aug 2012 20:30:32 +0200 Original-Received: from cl-pat-tr.clearspring.com ([8.18.54.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Aug 2012 20:30:32 +0200 Original-Received: from sds by cl-pat-tr.clearspring.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Aug 2012 20:30:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 34 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cl-pat-tr.clearspring.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-Attribution: Sam X-Disclaimer: You should not expect anyone to agree with me. Cancel-Lock: sha1:WgnckduukKd6PeM0CsAbZuwGP6g= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:152755 Archived-At: > * Stefan Monnier [2012-08-22 13:48:43 -0400]: > >> The introduction of print-length and print-level requires the CL-like >> macro with-standard-io-syntax which would bind these (and all the future >> variables which break read-back consistency) to nil. >> Right now, (rgrep "print-length nil" "*.el" "~/src/emacs/trunk/" nil) >> produces two dozen places where print-length is bound to nil and a quick >> examination shows that the set of variable which need to be bound to nil >> for print-read consistency is not uniformly understood. >> I already have been bitten by this, and I think others will be sooner >> rather than later. > > We could/should probably ignore print-length when print-circle is > non-nil. This is orthogonal (we can also introduce an all-encompassing print-readably, but the issue will remain). There are many variables affecting printing (and more might be added in the future), and we need a macro which binds them in a way which ensures read/write consistency, so that package developers do not have to update their code every time a new variable is introduced. (http://www.lispworks.com/documentation/HyperSpec/Body/m_w_std_.htm) The mantra "don't touch these variables and you will be fine" does not work because some packages (e.g., gnus) bind these vars temporarily and then the callbacks from them (e.g., bbdb) are screwed wrt read/write consistency. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000 http://www.childpsy.net/ http://ffii.org http://truepeace.org http://www.memritv.org http://palestinefacts.org http://jihadwatch.org Our business is run on trust. We trust you will pay in advance.