Re: Org-mode version 6.32trans and 6.21b; Strange interaction between whitespace-mode and cust. org-ellipsis

[Martin Pohlack <mp26@os.inf.tu-dresden.de>]

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.

Thanks for getting back to me on this matter,
Martin