[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Subject: 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 <address@hidden> wrote:
> On Thu, Aug 26, 2010 at 14:40, Lennart Borgman
> <address@hidden> 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.)


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


Stem the tide.

>     Juanma


reply via email to

[Prev in Thread] Current Thread [Next in Thread]