From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames. Date: Wed, 08 Aug 2012 11:39:09 +0800 Message-ID: <87r4rigihu.fsf@gnu.org> References: <50191B54.2070705@yandex.ru> <5019FE2D.2060005@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1344397164 1111 80.91.229.3 (8 Aug 2012 03:39:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Aug 2012 03:39:24 +0000 (UTC) Cc: Dmitry Antipov , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 08 05:39:22 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 1Syx7A-0001mz-I8 for ged-emacs-devel@m.gmane.org; Wed, 08 Aug 2012 05:39:20 +0200 Original-Received: from localhost ([::1]:44234 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Syx79-0007Sk-GK for ged-emacs-devel@m.gmane.org; Tue, 07 Aug 2012 23:39:19 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Syx77-0007Sf-Gb for emacs-devel@gnu.org; Tue, 07 Aug 2012 23:39:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Syx76-0005IU-F0 for emacs-devel@gnu.org; Tue, 07 Aug 2012 23:39:17 -0400 Original-Received: from mail-pb0-f41.google.com ([209.85.160.41]:60387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Syx76-0005IP-84 for emacs-devel@gnu.org; Tue, 07 Aug 2012 23:39:16 -0400 Original-Received: by pbbjt11 with SMTP id jt11so790925pbb.0 for ; Tue, 07 Aug 2012 20:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=pk9rox1ZyYwyeBOhFDHgWWaf2PjA+uzIRLvCk4G9nAI=; b=TYc9A0WSRvBKP0zBWorlJpAYnRBg/esqRn/zlsHiHTz4S+x6A9FMBORN4SMtHajD3M MsJu2YztXWmRNYzkzr3eSgaDT0tYEFfZPDsqbFi9uTHQCfD3a9Gs1s8+Cz+bo72Wwx2I AEinJAYNRtyMMcAszIpqPk5T3FB1A9fz2ObgD86WfFwUFXPxgr67mOdoIGPbs1b2Ai/4 58GHfK19X1bIgcVhl/FXpwV29o5geHlUHz8p2y9/jdfyyJKU1s2ub2hpt6ZTS0K690tU hh9fhoaKbOx1NxW2CgDRkztIuO/JB3/2wgBVBrcV1RiXmg/5kJxX1ddEeiRFMehaJ4Us oQ9w== Original-Received: by 10.68.195.197 with SMTP id ig5mr32674642pbc.137.1344397155361; Tue, 07 Aug 2012 20:39:15 -0700 (PDT) Original-Received: from ulysses ([155.69.16.255]) by mx.google.com with ESMTPS id wf7sm9021627pbc.34.2012.08.07.20.39.12 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 20:39:14 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 03 Aug 2012 03:42:45 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.160.41 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:152313 Archived-At: Stefan Monnier writes: > You can use coccinelle to automatically turn the x->y into an rvalue > FVAR (x,y) while debugging. And such a script should be kept around and > run every once in a while to check that new code follows the > SETFVAR convention. > > But I don't want the trunk's code obfuscated just for some temporary > debugging needs. Another problem, which I haven't seen mentioned in this thread, is that when you see C code which does FVAR (x, y) the natural assumption is that x and y are C variables. So these macros hurt code readability. The introduction of BVAR also violated this principle, and I'm not eager to see the problem compounded. I think FSET/WSET/PSET/PGET/etc should be removed from the trunk, at least for now. I recommend moving the generational GC work to a branch.