GNU bug report logs - #6915
Please consider making left-margin-width etc buffer local instead of major mode local

Previous Next

Full log

Message #17 received at 6915 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: MON KEY <monkey <at> sandpframing.com>, 6915 <at> debbugs.gnu.org
Subject: Re: bug#6915: Please consider making left-margin-width etc buffer
	local instead of major mode local
Date: Thu, 26 Aug 2010 14:40:05 +0200

On Thu, Aug 26, 2010 at 2:16 PM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Thu, Aug 26, 2010 at 11:19, Lennart Borgman
> <lennart.borgman <at> gmail.com> wrote:
>
>> If you do not have any serious answer then please stay out of this discussion.
>
> Why is that not a serious answer (other than the tone)?

I found no logic in it.

> Making variables permanent buffer-local has consequences, and frankly,
> margins seem something more likely to depend on the major mode than
> the buffer.

If there is only one major mode in the buffer this is perhaps the case, yes.

> If no one ever has asked for certain variables to be permanent
> buffer-local, other than mumamo, why cannot mumamo handle them?
> (Honest question, I don't know the answer.)

Emacs was not very good prepared for several major modes in a buffer.
I suppose this will change in the future, but we are not there yet.

There are, as I see it several cases to take care of:

- Major mode local variable.
- Buffer local variables.
  - Emulator mode buffer local variable.
  - Modified state buffer local variables.
  ...

I try to move this a bit forward by pointing to cases where a major
mode local variable probably is seen by users more like something
belonging to the buffer contents.

Yes, of course mumamo can take care of these cases, but it comes at a
cost. (And it definitively can not be taken care of the way that was
suggested in the answer you are commenting on.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.