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

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

[Lennart Borgman]

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.

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

[MON KEY]

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

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

[Lennart Borgman]

On Thu, Aug 26, 2010 at 5:58 AM, MON KEY <monkey@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.

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

[Juanma Barranquero]

On Thu, Aug 26, 2010 at 11:19, Lennart Borgman
<lennart.borgman@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

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

[Lennart Borgman]

On Thu, Aug 26, 2010 at 2:16 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Aug 26, 2010 at 11:19, Lennart Borgman
> <lennart.borgman@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.)

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

[Juanma Barranquero]

On Thu, Aug 26, 2010 at 14:40, Lennart Borgman
<lennart.borgman@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

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

[Lennart Borgman]

On Thu, Aug 26, 2010 at 3:05 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Aug 26, 2010 at 14:40, Lennart Borgman
> <lennart.borgman@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

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

[MON KEY]

On Thu, Aug 26, 2010 at 9:05 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Aug 26, 2010 at 14:40, Lennart Borgman
> <lennart.borgman@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\

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

[Lennart Borgman]

On Fri, Aug 27, 2010 at 12:20 AM, MON KEY <monkey@sandpframing.com> wrote:
> On Thu, Aug 26, 2010 at 9:05 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> On Thu, Aug 26, 2010 at 14:40, Lennart Borgman
>> <lennart.borgman@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.

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

[MON KEY]

On Thu, Aug 26, 2010 at 7:30 PM, Lennart Borgman
<lennart.borgman@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\

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

[Lennart Borgman]

On Fri, Aug 27, 2010 at 4:59 AM, MON KEY <monkey@sandpframing.com> wrote:
> On Thu, Aug 26, 2010 at 7:30 PM, Lennart Borgman
> <lennart.borgman@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?

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

[MON KEY]

On Fri, Aug 27, 2010 at 4:39 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> To whom is this written?
>
She who will read it....

> Who is in your public?

Posterity of course.

--
/s_P\

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

[Lennart Borgman]

On Sat, Aug 28, 2010 at 5:49 AM, MON KEY <monkey@sandpframing.com> wrote:
> On Fri, Aug 27, 2010 at 4:39 AM, Lennart Borgman
> <lennart.borgman@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?

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

[Ken Hori]

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@gmail.com> wrote:
> On Sat, Aug 28, 2010 at 5:49 AM, MON KEY <monkey@sandpframing.com> wrote:
>> On Fri, Aug 27, 2010 at 4:39 AM, Lennart Borgman
>> <lennart.borgman@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?
>
>
>
>

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

[Lennart Borgman]

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@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@gmail.com> wrote:
>> On Sat, Aug 28, 2010 at 5:49 AM, MON KEY <monkey@sandpframing.com> wrote:
>>> On Fri, Aug 27, 2010 at 4:39 AM, Lennart Borgman
>>> <lennart.borgman@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?
>>
>>
>>
>>
>

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

[Stefan Monnier]

> 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

bug#6915: Please consider making left-margin-width etc buffer local inst

[MON KEY]

> (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\

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

[Lars Ingebrigtsen]

Lennart Borgman <lennart.borgman@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