From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Why buffer_shared is a mistake Date: Mon, 10 Dec 2012 10:18:23 +0200 Message-ID: <83vccab9rk.fsf@gnu.org> References: <50C0C196.2020400@yandex.ru> <83ip8clk7f.fsf@gnu.org> <50C58F6A.2010005@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1355127522 15998 80.91.229.3 (10 Dec 2012 08:18:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Dec 2012 08:18:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 10 09:18:54 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 1ThyZh-0000TX-Bv for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2012 09:18:53 +0100 Original-Received: from localhost ([::1]:49429 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThyZU-0002VW-J0 for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2012 03:18:40 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThyZR-0002VQ-5A for emacs-devel@gnu.org; Mon, 10 Dec 2012 03:18:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ThyZP-0000dF-G9 for emacs-devel@gnu.org; Mon, 10 Dec 2012 03:18:37 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:47970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThyZP-0000d1-7r for emacs-devel@gnu.org; Mon, 10 Dec 2012 03:18:35 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MET00200300EF00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 10 Dec 2012 10:18:33 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MET001OR32WCUD0@a-mtaout20.012.net.il>; Mon, 10 Dec 2012 10:18:33 +0200 (IST) In-reply-to: <50C58F6A.2010005@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:155417 Archived-At: > Date: Mon, 10 Dec 2012 11:29:46 +0400 > From: Dmitry Antipov > CC: emacs-devel@gnu.org > > But now I'm thinking about maintaining per-buffer window counter, > which value is independent from the redisplay actions. This opens > the way to a different optimizations (e.g. if we're modifying a buffer > which isn't shown in a window, we can avoid redisplay at all). The idea is fine with me. Just keep in mind the TTY display, where windows are not necessarily independent as far as redisplay is concerned. > (My view of the whole thing is: Emacs global state is huge, and > redisplay is controlled by too much amount of global variables. > This is error-prone and makes some valuable things like threading > too complicated or even impossible. So it's desirable to deduce > redisplay actions from per-buffer/window/frame variables rather > than from the global ones.) Perhaps a good starting point would be to find all those global variables that control the display engine, and document, or at least list them in one place. Then those of them that become buffer- or window- or frame-local could be removed from that list.