From: MON KEY <monkey@sandpframing.com>
To: 6871@debbugs.gnu.org
Subject: bug#6871: Please make linum-mode per buffer, not per major mode
Date: Tue, 17 Aug 2010 19:47:22 -0400 [thread overview]
Message-ID: <AANLkTimsv+e8S8tFj-y4njsWSQYPBVvv22v=9dAu-323@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimfv=GYEcA45+ogw=mgB3bQSD3hrEgzt-5osS-2@mail.gmail.com>
> 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?
And, while your giving permanent-locals away so freely can maybe you
spare a few for the slime guys? Or the geiser/quack/scheme guys I'm
sure they could use some too... :-P
--
/s_P\
next prev parent reply other threads:[~2010-08-17 23:47 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 [this message]
2010-08-18 0:14 ` Lennart Borgman
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='AANLkTimsv+e8S8tFj-y4njsWSQYPBVvv22v=9dAu-323@mail.gmail.com' \
--to=monkey@sandpframing.com \
--cc=6871@debbugs.gnu.org \
/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).