From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Roland Winkler Newsgroups: gmane.emacs.devel Subject: Re: Propagating local variables? Date: Tue, 15 May 2018 22:42:04 -0500 Message-ID: <87fu2se06r.fsf@gnu.org> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1526442056 12516 195.159.176.226 (16 May 2018 03:40:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 16 May 2018 03:40:56 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 16 05:40:52 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fInJ5-0003AR-8i for ged-emacs-devel@m.gmane.org; Wed, 16 May 2018 05:40:51 +0200 Original-Received: from localhost ([::1]:50676 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fInLA-0005em-B7 for ged-emacs-devel@m.gmane.org; Tue, 15 May 2018 23:43:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fInKU-0005eG-EI for emacs-devel@gnu.org; Tue, 15 May 2018 23:42:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fInKR-0001zf-6v for emacs-devel@gnu.org; Tue, 15 May 2018 23:42:18 -0400 Original-Received: from [195.159.176.226] (port=48094 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fInKR-0001zG-03 for emacs-devel@gnu.org; Tue, 15 May 2018 23:42:15 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fInIH-0002N4-Cs for emacs-devel@gnu.org; Wed, 16 May 2018 05:40:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 30 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:mMxjPSByeo95OuoPqAQKiBSZSX0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:225325 Archived-At: On Tue, May 15 2018, John Wiegley wrote: > I'd like to create a module, propagate.el, which defines a new class > of buffer local variables: buffer local variables that propagate to > any buffers or processes (in the case of exec-path and > process-environment) created on behalf of the parent. This is an interesting idea. I am not sure whether the following is related to your thoughts. I'll mention it anyway: In GNU Elpa is djvu.el for editing djvu documents. These documents come with multiple layers for text, annotations, bookmarks, etc. (kind of similar to pdf documents). So when you visit such a document with djvu.el it creates a buffer for each of these layers (plus a few extra ones for "viewing these layers"). Conventional buffer-local variables do not work in this case because the buffer-local variables need to be shared across the buffers that refer to the same document, but buffers for different documents should peacefully coexist. Hence to make this work djvu.el uses a conventional buffer-local variable whose value is a vector which is the same object for all buffers belonging to one djvu document (one vector for each djvu document). The elements of this vector are then the "document-local" variables where setting such an element in one buffer is seen in all other buffers for the same document, while buffers for different djvu documents do not interfere with each other. Another advantage is that temp buffers can easily inherit these document-local variables. I have always considered this a hack. But I could not think of a better solution. Suggestions are welcome. Roland