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\