From: Lennart Borgman <lennart.borgman@gmail.com>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: MON KEY <monkey@sandpframing.com>, 6915@debbugs.gnu.org
Subject: 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 [thread overview]
Message-ID: <AANLkTi=Cbxjkw9qCPDQi=yZMLOQRGfohRJN9BVn5qudw@mail.gmail.com> (raw)
In-Reply-To: <AANLkTinQHc7pbZ8Z0YZt0eWMEBXu+BmgU7eDv92ahRAh@mail.gmail.com>
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.)
next prev parent reply other threads:[~2010-08-26 12:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-25 22:59 bug#6915: Please consider making left-margin-width etc buffer local instead of major mode local Lennart Borgman
2010-08-26 3:58 ` MON KEY
2010-08-26 9:19 ` Lennart Borgman
2010-08-26 12:16 ` Juanma Barranquero
2010-08-26 12:40 ` Lennart Borgman [this message]
2010-08-26 13:05 ` Juanma Barranquero
2010-08-26 20:01 ` Lennart Borgman
2010-08-26 22:20 ` MON KEY
2010-08-26 23:30 ` Lennart Borgman
2010-08-27 2:59 ` MON KEY
2010-08-27 8:39 ` Lennart Borgman
2010-08-28 3:49 ` MON KEY
2010-08-28 6:26 ` Lennart Borgman
2010-08-30 0:45 ` Ken Hori
2010-08-30 0:55 ` Lennart Borgman
2010-08-26 22:51 ` Stefan Monnier
2010-08-27 3:47 ` bug#6915: Please consider making left-margin-width etc buffer local inst MON KEY
2022-04-17 13:55 ` bug#6915: Please consider making left-margin-width etc buffer local instead of major mode local Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTi=Cbxjkw9qCPDQi=yZMLOQRGfohRJN9BVn5qudw@mail.gmail.com' \
--to=lennart.borgman@gmail.com \
--cc=6915@debbugs.gnu.org \
--cc=lekktu@gmail.com \
--cc=monkey@sandpframing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).