From: Lennart Borgman <lennart.borgman@gmail.com>
To: MON KEY <monkey@sandpframing.com>
Cc: 6871@debbugs.gnu.org
Subject: bug#6871: Please make linum-mode per buffer, not per major mode
Date: Wed, 18 Aug 2010 02:14:47 +0200 [thread overview]
Message-ID: <AANLkTimrhaUz3ZkGt6-jn65M1ZnyhU2t7aZq8=dbiqgr@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimsv+e8S8tFj-y4njsWSQYPBVvv22v=9dAu-323@mail.gmail.com>
On Wed, Aug 18, 2010 at 1:47 AM, MON KEY <monkey@sandpframing.com> wrote:
>> I think such a change is acceptable (although the motivation of
>> multi-major-mode buffers might not be that compelling, since it
>> tends to lead to the idea that most/all minor-modes should be made
>> permanent-local), but we need a proper patch for it.
>
> Thats potentially a lot of overlays to persist in buffers which:
>
> - may not always be visible
> - may be visible but don't need the linum minor-mode behaviour
> automatically persisted
>
> Will such a change negatively impact redisplay elsewhere?
> I ask because of this comment here from linum.el:
>
> ,----
> |
> | (add-hook 'window-configuration-change-hook
> | ;; FIXME: If the buffer is shown in N windows, this
> | ;; will be called N times rather than once. We should use
> | ;; something like linum-update-window instead.
> | 'linum-update-current nil t)
> |
> `----
>
> Also, linum-mode activation already sets timers when linum-eager is
> non-nil... will these timers now persist as well on major-mode
> changes? If so how will they impact redisplay?
>
> More concretely, how many (more) permanent-locals does Lennart need in
> order to attain mumamo.el bliss?
Those things are not related.
next prev parent reply other threads:[~2010-08-18 0:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-17 2:06 bug#6871: Please make linum-mode per buffer, not per major mode Lennart Borgman
2010-08-17 8:59 ` Stefan Monnier
2010-08-17 11:23 ` Lennart Borgman
2010-08-17 12:11 ` Stefan Monnier
2010-08-17 12:35 ` Lennart Borgman
2010-08-18 7:19 ` Stefan Monnier
2010-08-19 4:29 ` Lennart Borgman
2010-08-19 12:13 ` Juanma Barranquero
2010-08-19 13:25 ` Lennart Borgman
2010-08-19 13:38 ` Juanma Barranquero
2010-08-19 14:00 ` Lennart Borgman
2010-08-19 14:40 ` Juanma Barranquero
2010-08-19 21:23 ` Lennart Borgman
2010-08-19 21:57 ` Juanma Barranquero
2010-08-19 22:21 ` Lennart Borgman
2010-08-20 9:05 ` Eli Zaretskii
2010-08-19 22:43 ` Stefan Monnier
2010-08-20 1:11 ` Lennart Borgman
2010-08-20 12:59 ` Stefan Monnier
2010-08-19 14:45 ` Stefan Monnier
2010-08-19 21:19 ` Lennart Borgman
2010-08-17 23:47 ` MON KEY
2010-08-18 0:14 ` Lennart Borgman [this message]
2010-08-18 7:20 ` Stefan Monnier
2010-08-19 17:49 ` MON KEY
2010-08-19 21:18 ` Lennart Borgman
2020-09-19 15:52 ` 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='AANLkTimrhaUz3ZkGt6-jn65M1ZnyhU2t7aZq8=dbiqgr@mail.gmail.com' \
--to=lennart.borgman@gmail.com \
--cc=6871@debbugs.gnu.org \
--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).