From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Org-mode version 6.32trans and 6.21b; Strange interaction between whitespace-mode and cust. org-ellipsis Date: Fri, 1 Jan 2010 14:34:27 +0100 Message-ID: References: <4B16B9B5.5030508@os.inf.tu-dresden.de> <50ED3D70-FE6A-4903-BACC-9EC7D021EC22@gmail.com> <4B182EDB.3070209@os.inf.tu-dresden.de> <6A083B8A-17A3-40C1-9503-CE07FF660F7D@gmail.com> <4B192DB9.6070407@os.inf.tu-dresden.de> <05105BC1-7F54-4439-BAAA-5065ACFC44C3@gmail.com> <4B269749.5030507@os.inf.tu-dresden.de> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQheG-0000I0-Sm for emacs-orgmode@gnu.org; Fri, 01 Jan 2010 08:34:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQheC-0000Ed-5g for emacs-orgmode@gnu.org; Fri, 01 Jan 2010 08:34:36 -0500 Received: from [199.232.76.173] (port=57518 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQheB-0000EO-Vb for emacs-orgmode@gnu.org; Fri, 01 Jan 2010 08:34:32 -0500 Received: from ey-out-1920.google.com ([74.125.78.145]:61692) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQheB-00073o-OL for emacs-orgmode@gnu.org; Fri, 01 Jan 2010 08:34:31 -0500 Received: by ey-out-1920.google.com with SMTP id 4so1478528eyg.34 for ; Fri, 01 Jan 2010 05:34:29 -0800 (PST) In-Reply-To: <4B269749.5030507@os.inf.tu-dresden.de> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Martin Pohlack Cc: Vinicius Jose Latorre , emacs-orgmode@gnu.org On Dec 14, 2009, at 8:51 PM, Martin Pohlack wrote: > Hi Carsten, > > On 14.12.2009 17:27, Carsten Dominik wrote: >> i can follow your arguments and would like to improve this. >> >> What I do not understand yet is this: >> >> I was under the impression that normally, there is only a single >> display table in Emacs, and that is the global one and every buffer >> will use it. > > Interesting, I had the opposite impression. I'm not exactly sure why > though. Maybe from the documentation and name of the variable > buffer-display-table? > > Maybe you had standard-display-table in mind? > > "Variable: Display table to use for buffers that specify none. > See `buffer-display-table' for more information." > > I have, however, never seen a spelled out convention regarding deep > sharing of display tables. > >> So it would seem to me that whitespace-mode would normally >> *make* a local table in order to put its changes in there. However, >> that does not seem to be the case here. Can you see why? > > I think whitespace-mode usually assumes that the local display tables > is, well, local. Therefore, no action would be required. > > I forwarded my original bug-report to Vinicius Jose Latorre > (whitespace-mode's maintainer) after you mentioned it would be a > whitespace-mode bug. > > He replied: > >> Well, the problem was due to the way whitespace deal with >> buffer-display-table variable. >> >> I've just fixed this problem in Emacs CVS and EmacsWiki. > > Here is the patch: > > http://lists.gnu.org/archive/html/emacs-diffs/2009-12/msg00184.html > > He basically creates a deep copy (the copy-sequence line) of the local > display table and installs it. This should solve the problem. > > > I still have this nagging feeling that the sharing of the display > table > is not the right thing to do and would regard the fix in whitespace- > mode > as a kind of emergence case backup. But this is probably purely a > style > thing. And I do not agree here. Emacs has a global display tables that is normally shared across all buffers! So I would think it is perfectly OK to one that all buffers of a certain mode share. If whitespace.el intends to temporarily modify the display table of a particular buffer without affecting other, it must make sure that it does this correctly. In fact it did it already by making a local display table in order to avoid the global one. So the fix Vinicius implemented seems to be the correct solution. > > Thanks for getting back to me on this matter, Thank *you* for pursuing this! - Carsten