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

Previous Next

Package: emacs;

Reported by: Lennart Borgman <lennart.borgman <at> gmail.com>

Date: Wed, 25 Aug 2010 22:59:02 UTC

Severity: wishlist

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6915 in the body.
You can then email your comments to 6915 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Wed, 25 Aug 2010 22:59:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lennart Borgman <lennart.borgman <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 25 Aug 2010 22:59:02 GMT) Full text and rfc822 format available.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Emacs Bugs <bug-gnu-emacs <at> gnu.org>
Subject: Please consider making left-margin-width etc buffer local instead of
	major mode local
Date: Thu, 26 Aug 2010 00:59:01 +0200
I just got a bug report for nXhtml
(https://bugs.launchpad.net/nxhtml/+bug/619587) that seems to be
caused by that left-margin-width is major mode local. I can protect
this from getting changed in mumamo.el, but I wonder whether this
variable and some other variables at the same place in buffer.c should
be made buffer local instead of major mode local. (I.e. I wonder
whether they should be have the property permanent-local set to t.)

To me it looks like it is more likely that it is used as a buffer
local variable (cf linum-mode for example) than a major mode local
variable. And when it is a major mode local variable (as it is today)
it has to be overriden by multi major modes (since the margin width is
per buffer and you do not want it to change while moving in the
buffer).

So I suggest that those variables should be made buffer local.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Thu, 26 Aug 2010 03:58:02 GMT) Full text and rfc822 format available.

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

From: MON KEY <monkey <at> sandpframing.com>
To: 6915 <at> debbugs.gnu.org
Subject: bug#6915: Please consider making left-margin-width etc buffer local
	instead of major mode local
Date: Wed, 25 Aug 2010 23:58:52 -0400
> but I wonder whether this variable and some other variables at the
> same place in buffer.c should be made buffer local instead of major
> mode local. (I.e. I wonder whether they should be have the property
> permanent-local set to t.

I have a better solution.

Please, consider adding a mumamo-hook that makes all mumamo related
vars permanent-local by default..

> And when it is a major mode local variable (as it is today)
> it has to be overriden by multi major modes

Well, there you go.

> (since the margin width is per buffer and you do not want it to
>  change while moving in the buffer).

Says who?

> So I suggest that those variables should be made buffer local.

You've only mentioned _one_ variable `left-margin-width' in this report.
The remainder are (I assume) made implicit with your &rest etc. e.g.:

(defun lennart-needs-pl (variable-isnt-local &rest etc\.)
  (when (or affects-mumamo-p causes-lennart-grief-p)
    (file-bug-report variable-isnt-local)
    (when (and etc\. (listp etc\.)
               (mapc #'file-bug-report etc\.)))))

(lennart-needs-pl 'left-margin-width
                  'some 'more 'unamed 'variables 'from 'buffer\.c)

Run with it.

--
/s_P\




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Thu, 26 Aug 2010 09:19:02 GMT) Full text and rfc822 format available.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 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 11:19:24 +0200
On Thu, Aug 26, 2010 at 5:58 AM, MON KEY <monkey <at> sandpframing.com> wrote:
>> but I wonder whether this variable and some other variables at the
>> same place in buffer.c should be made buffer local instead of major
>> mode local. (I.e. I wonder whether they should be have the property
>> permanent-local set to t.
>
> I have a better solution.
>
> Please, consider adding a mumamo-hook that makes all mumamo related
> vars permanent-local by default..

If you do not have any serious answer then please stay out of this discussion.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Thu, 26 Aug 2010 12:16:02 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Lennart Borgman <lennart.borgman <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:16:38 +0200
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)?

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

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.)

    Juanma




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Thu, 26 Aug 2010 12:40:03 GMT) Full text and rfc822 format available.

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.)




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Thu, 26 Aug 2010 13:05:01 GMT) Full text and rfc822 format available.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Lennart Borgman <lennart.borgman <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 15:05:16 +0200
On Thu, Aug 26, 2010 at 14:40, Lennart Borgman
<lennart.borgman <at> gmail.com> wrote:

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

This is what happens now, and in the foreseeable future, in the vast
majority of buffers. Or do you anticipate the need to use mumamo in
all kinds of buffers?

> Emacs was not very good prepared for several major modes in a buffer.

Agreed.

> I suppose this will change in the future, but we are not there yet.

Why?

>  - Emulator mode buffer local variable.
>  - Modified state buffer local variables.

I lack context (or knowledge) to understand what you mean here.

> 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, I understand, but I think here is where I disagree. A priori, I
don't know why margins would be related more to buffer contents than
to buffer mode.

> Yes, of course mumamo can take care of these cases, but it comes at a cost.

Making variables permanent buffer-local also has a cost. Surprise and
bugs, if the user or other modes weren't expecting it, for example.

> (And it definitively can not be taken care of the way that was
> suggested in the answer you are commenting on.)

I trust you on this. But perhaps what is lacking is something at the
Emacs API level.

What I mean is that making permanent buffer-local every variable that
mumamo needs so isn't necessarily the best answer.

    Juanma




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Thu, 26 Aug 2010 20:01:02 GMT) Full text and rfc822 format available.

Message #23 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 22:01:14 +0200
On Thu, Aug 26, 2010 at 3:05 PM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Thu, Aug 26, 2010 at 14:40, Lennart Borgman
> <lennart.borgman <at> gmail.com> wrote:
>
>> If there is only one major mode in the buffer this is perhaps the case, yes.
>
> This is what happens now, and in the foreseeable future, in the vast
> majority of buffers. Or do you anticipate the need to use mumamo in
> all kinds of buffers?

No, just for multi major mode buffers. (But for web programming these
are common, of course.)

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

I just mean that Emacs hopefully will adopt some multi major mode
framework (and some changes needed for that).

>>  - Emulator mode buffer local variable.

Viper, cua-mode, etc. In some cases there are state variables per buffer.

>>  - Modified state buffer local variables.

Just an example, maybe a bad one though... - I meant any variable
describing changes of the buffer content.

> I lack context (or knowledge) to understand what you mean here.

The examples was only a try to evoke some thoughts about variable
position locallity.


>> 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, I understand, but I think here is where I disagree. A priori, I
> don't know why margins would be related more to buffer contents than
> to buffer mode.

I am a bit hesitating about this (that is why I was expressing this
wish less strongly). I know quite little about margin use in Emacs.
The only uses I know of are:

- linum-mode.
- mumamo-margin-info-mode (alt display chunk start-end inf margin)
- wrap-to-fill-column-mode (display text dark room style in the middle
of the buffer)

The last two are mine, so I do not know much at all about this. What
other uses are there in Emacs of the margin widths?

However for all of these a buffer local value of the margin width
makes perfect sense. Also in multi major mode it would be very
disturbing to change the margin width when moving from one major mode
chunk to another.

What arguments are there for having the margin width as a major mode
local value?


>> Yes, of course mumamo can take care of these cases, but it comes at a cost.
>
> Making variables permanent buffer-local also has a cost. Surprise and
> bugs, if the user or other modes weren't expecting it, for example.

You mean other major modes? As I have explained earlier those examples
are better to catch. (Stefan was hesitating about this.)

>> (And it definitively can not be taken care of the way that was
>> suggested in the answer you are commenting on.)
>
> I trust you on this. But perhaps what is lacking is something at the
> Emacs API level.

Yes. of course. I expect that to happen later on (see my examples
above for possible needs). But please remember that the current "api"
is adding the property permanent-local.

> What I mean is that making permanent buffer-local every variable that
> mumamo needs so isn't necessarily the best answer.
>
>     Juanma




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Thu, 26 Aug 2010 22:20:02 GMT) Full text and rfc822 format available.

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

From: MON KEY <monkey <at> sandpframing.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 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 18:20:26 -0400
On Thu, Aug 26, 2010 at 9:05 AM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Thu, Aug 26, 2010 at 14:40, Lennart Borgman
> <lennart.borgman <at> gmail.com> wrote:
>
>> If there is only one major mode in the buffer this is perhaps the case, yes.
>
> This is what happens now, and in the foreseeable future, in the vast
> majority of buffers. Or do you anticipate the need to use mumamo in
> all kinds of buffers?

What utility is there in that?

Supporting the extension of the existing featues mumamo offers would
be extremely wrong-headed without extending a lexical-scoping feature
to Emacs lisp first b/c it would only further obviate an (over)
reliance on variables being buffer-local and permanent local.

And, _if_ true lexical-scoping were an Emacs lisp feature most of the
concepts embodied by "mumamo" would no longer be relevant b/c closures
and capturing environments could take care of state.

This is the cruxt of my beef w/ Lennarts increasingly incessant clamor
for more permanet buffer-locals to satisfy the (oft hypothetical)
needs of mumamo type features.  Where his solution might work to solve
_one_ problem it glosses over the bigger ones. IOW Lennart should be
advocationg for inclusion of Miles Bader lexical scoping for Emacs
rather than privelging only the variables he wants/needs according to
some arbitrary determination of whether a variable is primarily an
aspect of buffer-content vs. major-mode functionality...

>
>> Emacs was not very good prepared for several major modes in a buffer.
>
> Agreed.
>

It wasn't prepared for it because they were called "Major Modes" not:
"Modes which affect Modes which affect Modes w/ turtles all the way down"

Note, the latter _is_ the ideal (mine anyways).

Unfortunately, implemention of such a system within Emacs was rejected
long ago (it basically requires Common Lisp's CLOS/MOP). Attempting to
retrofit "turtles all the way down" isn't possible without access to
lots of turtles. Regardless, unrestrained permanent-localism isn't the
correct means with which to acquire those turtles.

>> I suppose this will change in the future, but we are not there yet.
>
> Why?
>

Because Stefan is practically giving away permanent-locals.
Or haven't you heard?

>>  - Emulator mode buffer local variable.
>>  - Modified state buffer local variables.
>
> I lack context (or knowledge) to understand what you mean here.

Don't be coy, he doesn't mean anything... Its vacuous.

>
>> 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.
>

No you don't/didn't, you discuss your view of what the "user" wants as it
relates to a relatively small realm of Emacs usage.

> Yes, I understand, but I think here is where I disagree. A priori, I
> don't know why margins would be related more to buffer contents than
> to buffer mode.
>
>> Yes, of course mumamo can take care of these cases, but it comes at a cost.

The fact is that it can't "take care of these cases".
If it could you wouldn't persist in requesting ever more permanent-locals.

The cost is essentially the rest of Emacs and Emacs users should yield to your
perspective on Emacs functionality w/re to how well it can function with
multiple major modes in a single buffer despite that most Emacs buffers _are
not_ of this type.

>
> Making variables permanent buffer-local also has a cost. Surprise and
> bugs, if the user or other modes weren't expecting it, for example.
>
This isn't a problem... just add more permanent-locals!!!

>> (And it definitively can not be taken care of the way that was
>> suggested in the answer you are commenting on.)

Indeed.

>
> I trust you on this.

I wouldn't. He has mis-interpreted the problem-space as being somehow
constrained to the interaction of multiple major modes and a select set of
buffer local variables. The reality is that the "problem" pervades all of Emacs.
Though, when it is presented as such he punts.


> But perhaps what is lacking is something at the Emacs API level.
>

Yes, real lexical-scoping.
Also, symbol level namespacing would be nice :)

>
> What I mean is that making permanent buffer-local every variable that
> mumamo needs so isn't necessarily the best answer.
>

It _is_ the best answer so long as no one objects to permanent local bloat.
And Lennart has demonstrated that his readily able to
employ Maslows hammer in this regards.

http://en.wikipedia.org/wiki/Law_of_the_instrument

Stem the tide.

>     Juanma
>

--
/s_P\




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Thu, 26 Aug 2010 22:50:03 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 6915 <at> debbugs.gnu.org
Subject: Re: bug#6915: Please consider making left-margin-width etc buffer
	local instead of major mode local
Date: Fri, 27 Aug 2010 00:51:16 +0200
> To me it looks like it is more likely that it is used as a buffer
> local variable (cf linum-mode for example) than a major mode local
> variable.

You might be right: it affects the whole buffer in a uniform way, so
clearly for a multi-major mode buffer, it's not specific to a particular
major mode.

Seeing how it's a little-used variable, and how it's easier to ignore the
permanent-local property on a case-by-case basis than to add it on
a case-by-case basis (which means that most vars should be
permanent-local until it's shown they shouldn't be, rather than the
current reverse situation), I'm in favor of such a change.


        Stefan





Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Thu, 26 Aug 2010 23:30:02 GMT) Full text and rfc822 format available.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: MON KEY <monkey <at> sandpframing.com>
Cc: Juanma Barranquero <lekktu <at> gmail.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: Fri, 27 Aug 2010 01:30:47 +0200
On Fri, Aug 27, 2010 at 12:20 AM, MON KEY <monkey <at> sandpframing.com> wrote:
> On Thu, Aug 26, 2010 at 9:05 AM, Juanma Barranquero <lekktu <at> gmail.com> wrote:
>> On Thu, Aug 26, 2010 at 14:40, Lennart Borgman
>> <lennart.borgman <at> gmail.com> wrote:
>>
>>> If there is only one major mode in the buffer this is perhaps the case, yes.
>>
>> This is what happens now, and in the foreseeable future, in the vast
>> majority of buffers. Or do you anticipate the need to use mumamo in
>> all kinds of buffers?
>
> What utility is there in that?

Could you please put this in a place where it belongs? It is not here.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Fri, 27 Aug 2010 02:59:01 GMT) Full text and rfc822 format available.

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

From: MON KEY <monkey <at> sandpframing.com>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: Juanma Barranquero <lekktu <at> gmail.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 22:59:30 -0400
On Thu, Aug 26, 2010 at 7:30 PM, Lennart Borgman
<lennart.borgman <at> gmail.com> wrote:
>> What utility is there in that?
>
> Could you please put this in a place where it belongs?
>

emacs -Q

(locate-library "mumamo.el")

;=> nil

> It is not here.

Indeed.

--
/s_P\




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Fri, 27 Aug 2010 03:46:02 GMT) Full text and rfc822 format available.

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

From: MON KEY <monkey <at> sandpframing.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 6915 <at> debbugs.gnu.org,
	Lennart Borgman <lennart.borgman <at> gmail.com>
Subject: bug#6915: Please consider making left-margin-width etc buffer local
	inst
Date: Thu, 26 Aug 2010 23:47:19 -0400
> (which means that most vars should be permanent-local until it's shown
> they shouldn't be, rather than the current reverse situation)

Interesting.

So you are intent on provisioning that all variables be made permanent
local by default?

Doesn't this imply that there isn't a need to explicitly set the
permanent local property?

--
/s_P\




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Fri, 27 Aug 2010 08:39:02 GMT) Full text and rfc822 format available.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: MON KEY <monkey <at> sandpframing.com>
Cc: Juanma Barranquero <lekktu <at> gmail.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: Fri, 27 Aug 2010 10:39:27 +0200
On Fri, Aug 27, 2010 at 4:59 AM, MON KEY <monkey <at> sandpframing.com> wrote:
> On Thu, Aug 26, 2010 at 7:30 PM, Lennart Borgman
> <lennart.borgman <at> gmail.com> wrote:
>>> What utility is there in that?
>>
>> Could you please put this in a place where it belongs?
>>
>
> emacs -Q
>
> (locate-library "mumamo.el")
>
> ;=> nil
>
>> It is not here.
>
> Indeed.

To whom is this written? Who is in your public?




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Sat, 28 Aug 2010 03:48:01 GMT) Full text and rfc822 format available.

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

From: MON KEY <monkey <at> sandpframing.com>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 6915 <at> debbugs.gnu.org
Subject: Re: bug#6915: Please consider making left-margin-width etc buffer
	local instead of major mode local
Date: Fri, 27 Aug 2010 23:49:02 -0400
On Fri, Aug 27, 2010 at 4:39 AM, Lennart Borgman
<lennart.borgman <at> gmail.com> wrote:
>
> To whom is this written?
>
She who will read it....

> Who is in your public?

Posterity of course.

--
/s_P\




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Sat, 28 Aug 2010 06:26:01 GMT) Full text and rfc822 format available.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 6915 <at> debbugs.gnu.org
Subject: Re: bug#6915: Please consider making left-margin-width etc buffer
	local instead of major mode local
Date: Sat, 28 Aug 2010 08:26:36 +0200
On Sat, Aug 28, 2010 at 5:49 AM, MON KEY <monkey <at> sandpframing.com> wrote:
> On Fri, Aug 27, 2010 at 4:39 AM, Lennart Borgman
> <lennart.borgman <at> gmail.com> wrote:
>>
>> To whom is this written?
>>
> She who will read it....
>
>> Who is in your public?
>
> Posterity of course.

This sounds very general, a logic generalization. Are you there?




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Mon, 30 Aug 2010 00:44:01 GMT) Full text and rfc822 format available.

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

From: Ken Hori <fplemma <at> gmail.com>
To: Lennart Borgman <lennart.borgman <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: Sun, 29 Aug 2010 17:45:05 -0700
Lennart, please be civil to one another. It is not the place to bring
your personal incentives. (Plus, MON's comments are indeed
substantive.)

On Fri, Aug 27, 2010 at 11:26 PM, Lennart Borgman
<lennart.borgman <at> gmail.com> wrote:
> On Sat, Aug 28, 2010 at 5:49 AM, MON KEY <monkey <at> sandpframing.com> wrote:
>> On Fri, Aug 27, 2010 at 4:39 AM, Lennart Borgman
>> <lennart.borgman <at> gmail.com> wrote:
>>>
>>> To whom is this written?
>>>
>> She who will read it....
>>
>>> Who is in your public?
>>
>> Posterity of course.
>
> This sounds very general, a logic generalization. Are you there?
>
>
>
>




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Mon, 30 Aug 2010 00:55:01 GMT) Full text and rfc822 format available.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Ken Hori <fplemma <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: Mon, 30 Aug 2010 02:55:55 +0200
Ken, I have not been able to understand what it substantial in MON
KEY's comments, but that may be just me. (Except of course the worries
that making variables buffer local may create problems, but I believe
I have answered to that.)

So please explain me what I have been missing. You might be better
able to do that since MK and I then are clearly mis-communicating.


On Mon, Aug 30, 2010 at 2:45 AM, Ken Hori <fplemma <at> gmail.com> wrote:
> Lennart, please be civil to one another. It is not the place to bring
> your personal incentives. (Plus, MON's comments are indeed
> substantive.)
>
> On Fri, Aug 27, 2010 at 11:26 PM, Lennart Borgman
> <lennart.borgman <at> gmail.com> wrote:
>> On Sat, Aug 28, 2010 at 5:49 AM, MON KEY <monkey <at> sandpframing.com> wrote:
>>> On Fri, Aug 27, 2010 at 4:39 AM, Lennart Borgman
>>> <lennart.borgman <at> gmail.com> wrote:
>>>>
>>>> To whom is this written?
>>>>
>>> She who will read it....
>>>
>>>> Who is in your public?
>>>
>>> Posterity of course.
>>
>> This sounds very general, a logic generalization. Are you there?
>>
>>
>>
>>
>




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#6915; Package emacs. (Sun, 17 Apr 2022 13:56:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 6915 <at> debbugs.gnu.org
Subject: Re: bug#6915: Please consider making left-margin-width etc buffer
 local instead of major mode local
Date: Sun, 17 Apr 2022 15:55:00 +0200
Lennart Borgman <lennart.borgman <at> gmail.com> writes:

> I just got a bug report for nXhtml
> (https://bugs.launchpad.net/nxhtml/+bug/619587) that seems to be
> caused by that left-margin-width is major mode local. I can protect
> this from getting changed in mumamo.el, but I wonder whether this
> variable and some other variables at the same place in buffer.c should
> be made buffer local instead of major mode local. (I.e. I wonder
> whether they should be have the property permanent-local set to t.)

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Changing these variables to permanently buffer-local would break
people's set-ups, so it's not feasible to do that at this point.  (It
would have to have been done when the variables were introduced.)

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 6915 <at> debbugs.gnu.org and Lennart Borgman <lennart.borgman <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 17 Apr 2022 13:56:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 16 May 2022 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 317 days ago.

Previous Next


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