From: Juanma Barranquero <lekktu@gmail.com>
To: Lennart Borgman <lennart.borgman@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 15:05:16 +0200 [thread overview]
Message-ID: <AANLkTin8WvrGGZmpADGm5=usNdZkq6wHC5evwZ1KHmps@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=Cbxjkw9qCPDQi=yZMLOQRGfohRJN9BVn5qudw@mail.gmail.com>
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
next prev parent reply other threads:[~2010-08-26 13:05 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
2010-08-26 13:05 ` Juanma Barranquero [this message]
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='AANLkTin8WvrGGZmpADGm5=usNdZkq6wHC5evwZ1KHmps@mail.gmail.com' \
--to=lekktu@gmail.com \
--cc=6915@debbugs.gnu.org \
--cc=lennart.borgman@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).